|
| Greg's diary |
| February 2007 |
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Thursday, 1 February 2007 | Echunga | |
| Top of page | ||
| next day | ||
| last day |
How I hate working on multimedia code! Somewhere there's something wrong with the navigation information that I'm outputting, but how do I find out where? The obvious thing to do would be to use gdb to look at the structures as they're output. But what structures? DVDs are full of them, but most of the code doesn't use any structure declarations; instead you end up with things like:
result = (buf [0] & 0x18) << (24 + 3); result |= (buf [0] & 0x03) << (24 + 4); result |= (buf [1] & 0xFF) << (16 + 4);
What does that mean? Good code has comments, but that doesn't help gdb much. When I look at this kind of code, I'm torn between “fixing” it to use proper structure declarations and just testing it. Today did a bit of both, very half-heartedly, and as a result had no results by the evening.
On Saturday I'm leaving for a trip to Gippsland to visit my father. I won't have normal computer access, so decided to set up my laptop for PPP connections; but it seems that FreeBSD hardly supports any laptop modems any more, and my Dell Inspiron 5100 doesn't seem to have any support. One of the down sides of free software, I suppose.
| Friday, 2 February 2007 | Echunga | Images for 2 February 2007 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Into town today to talk with Geoff Richmond, my tax advisor. Suddenly it seems that getting older is an advantage: starting on 1 July I'll end up with a surprising number of tax breaks.
Then to pick up Yana, taking a look at her computer on the way. It's an Apple, running MacOS X, and it has no trouble with modem support, once the phone line is connected.
In the afternoon, Yvonne reported a strange mail bounce:
<ers@mubo.de>: host mail.mubo.de[192.109.53.125] said: 553 5.1.8
<ers@mubo.de>... Domain of sender address yvonne@lemis.com does not exist
(in reply to RCPT TO command)
Nonsense! But I checked with whois and discovered that my domain registration had expired yesterday. Why didn't I get a reminder? In the past I've had reminders 60, 30 and 15 days in advance, but this time there was nothing. Managed to renew the domain—for one year only: I'm very dissatisfied with that service, and I'll need an explanation about why I wasn't informed.
Quiet evening. Yana had thought that she could find a comet, so outside in the dark on the verandah. No comet, but it was calm and warm, unusual here.
| Saturday, 3 February 2007 | Echunga –> Melbourne | Images for 3 February 2007 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Off on the first leg to Maffra early enough today, without any particular problem—until my mobile phone reported low battery. I had planned for that, of course, and plugged it in to the car charger. Nothing happened. Stopped in Tailem Bend and confirmed that the fuse for the cigarette lighter had blown. Put in a new one, connected up and—it blew again! Damn. And because it “didn't make any sense”, I hadn't brought the mains charger, so now we're dependent on Yana's phone.
Decided to take the long way to Melbourne, via Mount Gambier and Warrnambool, like we did in October 1985. On that occasion we had left Adelaide at midday and were in Melbourne for a dinner invitation at 20:00, admittedly a bit of a stretch. Today we had left at 10:00, so decided to go via the Great Ocean Road and see the 12 Apostles.
Just outside Kingston SE, hit road works: 2 km of 25 km/h limit with nothing happening. At the other end, found a grader and a woman holding a “STOP” sign. Got out, asked her why they had to put the 25 km/h limit so far in advance. She told me that they were allowed to do it—apparently that was enough justification. Got back in the car and waited for her to turn the sign; instead, she started shouting obscenities at me. It gradually became clear that she wanted me to drive on, but she was still holding the “STOP” sign. Pointed that out to her—more obscenities—and just before I could get a photo of the whole stupid scene, she turned it around.
At the other end, they had people waiting for me wanting to know why I had been so abusive. Explained the situation, and they calmed down (and explained the length of the limit: the grader moves pretty quickly). But why do they have humans to hold signs? Traffic lights must be a lot cheaper.
Stopped off in Mount Gambier for lunch (“Red Rooster”—an experience, not to be repeated) and another view of the Blue Lake, this time living up to its name:
On to Warrnambool, where it became clear that our timing was out: left there at 17:45. We had told Audrey we would be in Melbourne at 17:00, and that was still 2½ to 3 hours away. Decided that we would have to give the Ocean Road a miss, and headed straight into Melbourne, getting caught up in traffic works on the way, so we finally arrived at Audrey's place just before 21:00. How did we manage it 3 hours faster in 1985?
| Sunday, 4 February 2007 | Melbourne –> Maffra –> Briagolong | Images for 4 February 2007 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Up long after Audrey and Yana, and was rewarded with bacon and eggs—just what we needed before an early lunch in town. Off then to central Melbourne, which Yana had never seen, and ended up in the Victoria Market, for me the first time since I was a kid. Not the way I remembered it: most of the stalls were junk, and my recollection is that it used to be foodstuffs. I suppose it's different during the week.
Then walked around town a bit—another recollection of bygone days was the public library, which I used to frequent nearly 50 years ago. Again, I didn't recognize much, in this time I suspect because they had completely rebuilt the interior, taking over the old museum in the process.
Then to the West Lake restaurant in Little Bourke St. for some Yum Cha. Not bad, but not cheap either.
Finding our way out of town was not as easy as I thought; they had blocked off Victoria Parade, and the resulting traffic down Punt Road was terrible. Took us half an hour to find our way to the freeway entrance.
Uneventful trip down to Maffra, where we found my father—he has aged a lot since I last saw him nearly 2 years ago: he is less mobile, his eyes are worse, and he has other problems as well. In general, not a pleasant development.
Freda came in only shortly later, and we set off to Briagolong in two cars. Had a pleasant afternoon and early evening, spent on the verandah, something that we can't do too often at home because of the wind. Freda tells me that she does it almost all year round. Enough reason to consider moving here.
Took Dad back to Maffra, then back to Gill and Kline's house (next to Freda's) and spent some time talking before going to bed. My father's condition is giving everybody cause for concern.
| Monday, 5 February 2007 | Briagolong, and around | Images for 5 February 2007 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Anther load of bacon and eggs this morning, this time cooked by Yana and myself. Freda has a thermostatically controlled electric frying pan, which on the face of it should be a great advantage over a flame, but in practice the thermostats in such devices have too much hysteresis. With a good, fast reacting system it might be a completely different matter.
Then with Freda to Maffra to talk to Dr. Baker, my father's GP, who gave us the results of a recent CAT scan and much to ponder. Then picked up my father for lunch—his walking is improving, anyway—after which Freda returned home and I set off round central Gippsland looking at the landscape. Maybe it was the high temperatures which started today, but it wasn't that impressive. Did a circle via Heywood, Traralgon, Rosedale, Longford and Sale back to Briagolong. Stopped off at the information office in Traralgon, where a very helpful person (Gerry? Glen?) gave me much more information that we got in Ballarat. In Rosedale saw an estate agent who actually had properties that might more or less fit our requirements, and there's also a big forest (Holey Plains state park) that looks like it would be suitable for riding. The area is also well irrigated—even now there are a number of relatively large rivers coming down from the High Country.
Dinner with Gill and Jasper in the evening—Kline was busy at a rehearsal and didn't return until later.
| Tuesday, 6 February 2007 | Briagolong –> Echunga | Images for 6 February 2007 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Off home this morning, stopping first in Maffra to say goodbye to my father, then to look at the area round Lake Glenmaggie, of which I had seen a nice photo on an estate agent's prospectus yesterday. The reality looks a bit different:
|
|||||||||||||||||||||||
Then on home through Melbourne, noting the times from leaving the South-Eastern Freeway:
| Time | Km | Location | Distance from last | Speed |
| 12:12 | 433.76 | Toorak Road Exit | ||
| 12:24 | 439.24 | Bridge Road | 5.48 | 27 km/h |
| 12:32 | 441.50 | Punt Road | 2.26 | 17 km/h |
| 12:44 | 445.74 | Grattan St house | 4.24 | 18 km/h |
| 12:46 | 446.49 | Flemington Road | 0.75 | |
| 12:57 | 452.03 | Western Highway | 5.54 | 29 km/h |
| 13:04 | Stop to refuel, leave at 13:12 | |||
| 13:20 | 462.13 | Hume Freeway | 40 km/h | |
| 13:31 | 475.63 | Western Freeway | 74 km/h | |
| Total | 41.87 | 35 km/h | ||
The real nuisance is that there's a freeway connection from the South-Eastern Freeway to the Hume and Western Freeways. It's a toll road, which would probably still be worthwhile (I'd expect to save 45 minutes); but it doesn't have toll booths. You need to buy day passes in advance. What a crock!
This is a seriously suboptimal way, maybe. Six months later I found a much more direct way: not all the freeways are tollways, and in fact only about 6 km of the road needs to be off the freeway. Unfortunately, it was no faster. My guess is that the tollway would have saved a maximum of 15 minutes.
In Ballarat, decided to take an alternative route home, this time via Hamilton, which wasn't much longer. It also wasn't very interesting. Back home at 20:35 after doing about 1050 km for the day.
| Wednesday, 7 February 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Spent most of the day documenting the trip and trying to catch up with my 3000 odd mail messages. One of them was the Bureau of Meteorology's monthly rainfall observations for January. I've already commented on their inaccuracy, but this takes the cake:
MOUNT LOFTY RANGES (23C)
Rain (mm) Rain Days Decile
Obs | Avg Obs | Avg
Echunga 4.4 35.1 2 6 1
Meadows 25.4 38.4 6 7 4
To the best of my knowledge, the BoM—incorrectly—reported no rainfall at all for Meadows in January. So this means that they have, at very least, corrected the situation, though I suspect 25.4 mm (exactly 1 inch) is too low. But they reported at least 39 mm in Echunga, above average, and the Mount Barker Courier reported 46 mm, apparently based on information from the Bureau of Meteorology; where did that go on this report?
| Thursday, 8 February 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Spent a lot of time today researching my father's conditions. He has severe visual impairment, but he sees hallucinations, and people were concerned about his state of mind. Some years back I had read a book by V.S. Ramachandran called “Phantoms of the mind”, about how neurologists learn about the brain by observing people with brain damage. One chapter was dedicated to the Charles Bonnet Syndrome (pronounced the French way), which affects people with severe visual impairment, with or without damage to the visual cortex. It seems it's an attempt by the brain to fill in the lack of visual stimulus, and it's harmless once you recognize what it is.
Years later I reconsidered this assessment and came to the conclusion that there were significant differences. In particular, the hallucinations seemed realistic to him and persisted beyond the visual effects.
More playing around copying MPEG-2 streams to DVD. One of the disappointing discoveries last week was that DVDs are not compatible with HDTV: the highest (PAL) resolution is 720x576. Looks like the best way to archive things is by simply splitting the MPEG stream into 1 GB chunks and burning a file system to DVD. Even so, most films won't fit onto a single layer DVD, but since they need to be copied back to disk to be played, I don't suppose it makes much difference. Started writing a chapter for a potential future book on how to burn multimedia data to DVD.
| Friday, 9 February 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Yet another quiet day doing little. It's good to relax a bit. Burnt some DVDs—I still don't know how to change the resolution, but I'm sure there's something in my bag of junk.
Diane Saunders hasn't been feeling well lately, and today Yvonne went over and found her in very poor condition. Yvonne suspected a stroke and took her off to the Mount Barker Hospital, who couldn't diagnose the problem—which I suppose excludes a stroke—and carted her off to the Royal Adelaide Hospital. She was back home by the evening, but we still don't know what she had.
| Saturday, 10 February 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Spent the morning finally reviewing papers for BSDCan 2007. There seem to be a surprising number of interesting talks; pity I won't be there. Apart from that, didn't do much. I have a lot of reading to catch up on, so started on that, but didn't finish.
| Sunday, 11 February 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
I've been contacted by Pierre Jammes, who has set up a web site DS in Asia about, well, Citroën DS (really D series) cars in Asia, and of course he was interested in my description of the Asia Trip. Spent some time updating my diary and otherwise documenting things, including my answers to his questions.
There's a new port out there, SipX, annoyingly called net/sipxpbx in the Ports Collection (to keep you on your toes, there's also sipxcalllib sipxcommserverlib, sipxconfig, sipxmediaadapterlib, sipxmedialib, sipxportlib, sipxproxy, sipxpublisher, sipxregistry, sipxtacklib and sipxvxml, all of which I think are dependencies. Why can't the main port just be called net/sipx? Decided to install it today, but didn't get far:
===== Sun Feb 11 12:55:52 CST 2007 on echunga.lemis.com: Make install ===> sipxpbx-3.6.0 : Error from bsd.apache.mk. apache13 is installed (or APACHE_PORT is defined) and port requires 2.0+. *** Error code 1
OK, it was probably time to upgrade from Apache 1.3 to Apache 2.2. Here's what I went through:
Apache now installs in a new directory, /usr/local/etc/apache22. The old one was /usr/local/etc/apache, which made more sense. I wish people wouldn't attach version numbers to directory names.
I keep my configuration files in RCS with a directory which is a symlink to a repository. In this case, I decided to link to same RCS control directory:
=== root@echunga (/dev/ttyp1) ~ 326 -> ln -s /home/Sysconfig/MasterRCS/usr/local/etc/apache/RCS=== root@echunga (/dev/ttyp1) ~ 327 -> ls -ltotal 1 drwxr-xr-x 2 root wheel 512 Feb 11 13:08 Includes lrwxr-xr-x 1 root wheel 50 Feb 11 13:13 RCS -> \ /home/Sysconfig/MasterRCS/usr/local/etc/apache/RCS drwxr-xr-x 2 root wheel 512 Feb 11 13:08 envvars.d drwxr-xr-x 2 root wheel 512 Feb 11 13:08 extra -rw-r--r-- 1 root wheel 16448 Feb 11 13:08 httpd.conf -rw-r--r-- 1 root wheel 12958 Feb 11 13:08 magic -rw-r--r-- 1 root wheel 15020 Feb 11 13:08 mime.types
Checked out the password files from the RCS directory.
Next was the question of modules. I was running PHP version 4, which also needed updating. pkg_info told me I had the following ports installed:
=== root@echunga (/dev/ttyp1) ~ 337 -> pkg_info | grep php
mod_php4-4.3.10_2,1 PHP Apache Module
php4-4.4.4 PHP Scripting Language (Apache Module and CLI)
php4-bz2-4.4.0 The bz2 shared extension for php
php4-curl-4.4.4_1 The curl shared extension for php
php4-gd-4.4.0 The gd shared extension for php
php4-iconv-4.4.4_1 The iconv shared extension for php
php4-mbstring-4.4.4_1 The mbstring shared extension for php
php4-mysql-4.4.0 The mysql shared extension for php
php4-pcre-4.4.0 The pcre shared extension for php
php4-readline-4.4.4_1 The readline shared extension for php
php4-session-4.4.4_1 The session shared extension for php
php4-xml-4.4.4_1 The xml shared extension for php
php4-zlib-4.4.4_1 The zlib shared extension for php
I had no idea what these ports all are, or why they're installed, but it seemed to be a good idea to reinstall the PHP5 versions. First I had to delete PHP 4 modules:
=== root@echunga (/dev/ttyp1) ~ 338 -> pkg_delete php4-4.4.4
pkg_delete: package 'php4-4.4.4' is required by these other packages
and may not be deinstalled:
php4-curl-4.4.4_1
...
mediawiki-1.6.8
mywwwatcher-3.0
What's mywwwatcher? No idea. Delete it. Also delete mediawiki, which is an old version installed because it was the last to have PHP 4 support.
Deleting the PHP4 modules is not straightforward:
=== root@echunga (/dev/ttyp1) ~ 361 -> pkg_delete mod_php4-4.3.10_2,1
pkg_delete: package 'mod_php4-4.3.10_2,1' is required by these other packages
and may not be deinstalled:
php4-bz2-4.4.0
php4-gd-4.4.0
...
I decided to remove the MySQL glue first:
=== root@echunga (/dev/ttyp1) ~ 343 -> pkg_info | grep mysql
mysql-client-5.0.15 Multithreaded SQL database (client)
mysql-server-5.0.3_1 Multithreaded SQL database (server)
php4-mysql-4.4.0 The mysql shared extension for php
The first two are the MySQL client and server, which don't need replacing.
=== root@echunga (/dev/ttyp1) ~ 344 -> pkg_delete php4-mysql-4.4.0
=== root@echunga (/dev/ttyp1) ~ 345 -> pkg_delete php4-4.4.4
pkg_delete: package 'php4-4.4.4' is required by these other packages
and may not be deinstalled:
...
I still have most of the dependencies. What now?. I suspect that the order these ports are listed is the chronological order of installation, so the best way to remove these ports is in reverse order. At any rate, that worked, though I ended up with a couple of:
=== root@echunga (/dev/ttyp1) ~ 353 -> pkg_delete php4-4.4.4
pkg_delete: unable to completely remove directory '/usr/local/include/php/main'
pkg_delete: couldn't entirely delete package (perhaps the packing list is
incorrectly specified?)
Check and find:
=== root@echunga (/dev/ttyp1) ~ 354 -> l /usr/local/include/php/main/
total 1
-rw-r--r-- 1 root wheel 7351 Mar 11 2005 config.nw.h
Ports options? Again the directory names make a nuisance of themselves, though clearly these options were created by a different port:
=== root@echunga (/dev/ttyp1) ~ 342 -> cat /var/db/ports/mod_php4/options
# This file is auto-generated by 'make config'.
# No user-servicable parts inside!
# Options for mod_php4-4.3.10_2,1
_OPTIONS_READ=mod_php4-4.3.10_2,1
WITHOUT_APACHE2=true
WITHOUT_DEBUG=true
WITH_IPV6=true
Still, these options just look wrong. Leave that until later.
Install:
/usr/ports/lang/php-mode.el /usr/ports/databases/php5-mysql
This one installs PHP 5.2.1 as a dependency, and also a whole lot of PHP4 stuff.
=== root@echunga (/dev/ttyp1) ~ 359 -> l -rt /var/db/pkg
...
drwxr-xr-x 2 root wheel 512 Feb 11 13:08 apache-2.2.4
drwxr-xr-x 2 root wheel 512 Feb 11 13:21 php4-pcre-4.4.0
drwxr-xr-x 2 root wheel 512 Feb 11 13:24 perl-5.8.6_2
drwxr-xr-x 2 root wheel 512 Feb 11 13:24 mysql-client-5.0.15
drwxr-xr-x 2 root wheel 512 Feb 11 13:25 expat-2.0.0_1
drwxr-xr-x 2 root wheel 512 Feb 11 13:25 expat-1.95.8
drwxr-xr-x 2 root wheel 512 Feb 11 13:26 libiconv-1.9.2_1
drwxr-xr-x 2 root wheel 512 Feb 11 13:26 mod_php4-4.3.10_2,1
drwxr-xr-x 2 root wheel 512 Feb 11 13:26 curl-7.15.5_1
drwxr-xr-x 2 root wheel 512 Feb 11 13:29 php-mode.el-1.2.0
drwxr-xr-x 2 root wheel 512 Feb 11 13:34 php5-mysql-5.2.1
drwxr-xr-x 2 root wheel 512 Feb 11 13:34 php5-5.2.1
It's not clear what I needed php4-gd for, but I might as well install the PHP5 version. Find it first:
=== root@echunga (/dev/ttyp1) ~ 369 -> locate php | grep gd
/src/CVS/FreeBSD/ncvs/ports/graphics/php4-gd
/src/CVS/FreeBSD/ncvs/ports/graphics/php4-gd/Makefile,v
...
/src/CVS/FreeBSD/ncvs/ports/graphics/php5-gd
/src/CVS/FreeBSD/ncvs/ports/graphics/php5-gd/Makefile,v
/src/CVS/FreeBSD/ncvs/ports/graphics/php5-gd/files
...
That's the CVS repository, but it matches /usr/ports, so use my installport
wrapper to install it:
=== root@echunga (/dev/ttyp1) ~ 368 -> installport /usr/ports/graphics/php5-gd
===> Cleaning for php5-5.2.1
===> Cleaning for autoconf-2.59_2
...
cc -I/src/FreeBSD/ports/graphics/php5-gd/work/php-5.2.1/ext/gd/libgd -DHAVE_LIBPNG ...
In file included from /usr/local/include/php/main/php.h:81,
from /src/FreeBSD/ports/graphics/php5-gd/work/php-5.2.1/ext/gd/gd.c:37:
/usr/local/include/php/main/php_regex.h:32:31: regex/regex_extra.h: No such file or directory
/usr/local/include/php/main/php_regex.h:33:25: regex/regex.h: No such file or directory
Looks like a broken dependency. Where are these files?
=== root@echunga (/dev/ttyp1) ~ 370 -> locate regex/regex_extra.h
/usr/local/include/php/regex/regex_extra.h
That's what was there before I cleaned up. What's there now?
=== root@echunga (/dev/ttyp1) ~ 371 -> l /usr/local/include/php/
total 1
drwxr-xr-x 2 root wheel 512 Feb 11 13:40 TSRM
drwxr-xr-x 2 root wheel 1536 Feb 11 13:34 Zend
drwxr-xr-x 6 root wheel 512 Feb 11 13:40 ext
drwxr-xr-x 3 root wheel 1024 Feb 11 13:40 main
OK, I didn't know what I needed php4-gd for, so let's skip it. But php4-bz2 looks like it's needed.
... /usr/local/include/php/main/php_regex.h:32:31: regex/regex_extra.h: No such file or directory ...Still no cigar.
Looking at the sequence of the original installation above, php4-bz2-4.4.0 appears to have depended only on mod_php4-4.3.10_2,1 and php4-4.4.4. What we currently have installed is:
=== root@echunga (/dev/ttyp1) ~ 379 -> pkg_info | grep php
php-mode.el-1.2.0 Emacs lisp module for the PHP language
php5-5.2.1 PHP Scripting Language (Apache Module and CLI)
php5-mysql-5.2.1 The mysql shared extension for php
No mod-php. Install it:
=== root@echunga (/dev/ttyp1) ~ 383 -> installport /usr/ports/www/mod_php5su: cd: /usr/ports/www/mod_php5: No such file or directory=== root@echunga (/dev/ttyp1) ~ 384 -> locate mod_php5 | less/src/CVS/FreeBSD/ncvs/ports/lang/php5/files/Attic/patch-sapi::apache::mod_php5.c,v /src/CVS/FreeBSD/ncvs/ports/www/mod_php5 /src/CVS/FreeBSD/ncvs/ports/www/mod_php5/Attic /src/CVS/FreeBSD/ncvs/ports/www/mod_php5/Attic/Makefile,v
So it's been deleted. What do we use now? That must be in /usr/ports/MOVED:
www/mod_php5|lang/php5|2006-05-06|Unification of php slave ports
What does that mean? That it's already in the PHP5 port? Where's the option file? It should be in /var/db/ports, but nothing there has been changed since August last year. Forcibly remove the port, ignoring its dependencies, and start again:
Try again with graphics/php5-gd. This time it works. Why didn't it when I installed it as a dependency to MySQL?
PHP still doesn't work. While looking for the port names, I had found a www/php5-extensions port, so I install that, which installs a lot of the names I had seen before. PHP still doesn't work.
Discover that I have BATCH=yes in my environment. Remove the lang/php5 port once again, and this time run make config. This gives me the file I had been expecting:
=== root@echunga (/dev/ttyp1) ~ 421 -> cat /var/db/ports/php5/options
# This file is auto-generated by 'make config'.
# No user-servicable parts inside!
# Options for php5-5.2.1
_OPTIONS_READ=php5-5.2.1
WITH_CLI=true
WITH_CGI=true
WITH_APACHE=true
WITHOUT_DEBUG=true
WITH_SUHOSIN=true
WITH_MULTIBYTE=true
WITH_IPV6=true
WITH_MAILHEAD=true
WITH_REDIRECT=true
WITH_DISCARD=true
WITH_FASTCGI=true
WITH_PATHINFO=true
Reinstall the port. This time I get a file /usr/local/libexec/apache22/libphp5.so. Add the line to httpd.conf:
LoadModule php5_module libexec/apache22/libphp5.soPHP still doesn't work.
Finally add the lines to httpd.conf:
AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps
Finally it works!
After that, try to install net/sipxpbx. The build fails with what looks like a valid error:
SIPXAuthHandler.cpp: In constructor `SIPXAuthHandler::SIPXAuthHandler()': SIPXAuthHandler.cpp:172: error: no matching function for call to `ApacheHandler::ApacheHan dler()' /usr/local/include/apache22/apache_handler.h:50: note: candidates are: ApacheHandler::Apac heHandler(const ApacheHandler&) /usr/local/include/apache22/apache_handler.h:55: note: ApacheHandler::Apac heHandler(ApacheServerRec*) SIPXAuthHandler.cpp: At global scope: SIPXAuthHandler.cpp:640: error: invalid conversion from `ApacheHandler*(*)()' to `ApacheHa ndler*(*)(ApacheServerRec*)'
At this point, I gave up. This stuff should be easier.
| Monday, 12 February 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Continued my work on the SipX port today; Martin Wilke sent me a patch which enabled me to build and install the port using Apache 2.2, and subsequently committed it. On the positive side, the install ended with a two page description of what to do to configure it. Here's the reality:
Set up a mail user sipx in /etc/aliases:
# Error messages from sipx sipx: root
newaliases gives an unexpected error:
=== root@echunga (/dev/ttyp8) /etc 47 -> newaliases
postalias: fatal: open /usr/local/majordomo/aliases.majordomo: No such file or directory
I haven't used majordomo for years, and it's not obvious where this is coming from. Run ktrace and discover that it's in /usr/local/etc/postfix/main.cf:
alias_database = hash:/etc/aliases,hash:/usr/local/majordomo/aliases.majordomo
This has nothing to do with SipX, of course.
Create an SSL certificate. The instructions at that link say:
mkdir $HOME/sslkeys cd $HOME/sslkeys /usr/bin/ssl-cert/gen-ssl-keys.sh gen-ssl-keys.sh will prompt for you for input including: 1. CA Common Name (DNS name for CA): Enter anything but NOT the DNS name of your server 2. SIP domain name: The domain name of your installation 3. Full DNS name for the server: Enter fully qualified hostname of your sipX server /usr/bin/ssl-cert/install-cert.sh
The instructions aren't tailored to FreeBSD, of course. There is no directory /usr/bin/ssl-cert/; it's /usr/local/bin/ssl-cert/, which still looks wrong to me: should be /usr/local/ssl-cert/bin/. Once you find the script, it fills in most things for you; the only issue was the CA Common Name; the recommendations above prove to be confusing. What I got was:
Identifying information for your private Certificate Authority (CA) CA Common Name (DNS name for CA) [ca.lemis.com] :Well, that's not my server DNS name, so I suppose it will do.
=== root@echunga (/dev/ttyp8) ~/sslkeys 44 -> /usr/local/bin/ssl-cert/install-cert.sh
Checking the echunga.lemis.com certificate
Installing ca.lemis.com.crt certificate as a trusted CA
ca.lemis.com.crt -> /usr/local/etc/sipxpbx/ssl/authorities/ca.lemis.com.crt
hashing /usr/local/etc/sipxpbx/ssl/authorities
ca.lemis.com.crt => ed9cf9c3.0
Installing the echunga.lemis.com certificate
echunga.lemis.com.crt -> /usr/local/etc/sipxpbx/ssl/ssl.crt
Installing the echunga.lemis.com private key
echunga.lemis.com.key -> /usr/local/etc/sipxpbx/ssl/ssl.key
Checking the installed certificate
Your sipX SSL security is now configured.
Your server certificate will expire Feb 11 01:50:52 2010 GMT.
Next was DNS configuration, which on the Wiki is located in the middle of the build instructions. The good news is that the information is there; it caused me a lot of pain in my attempts to set up Asterisk.
Setting up the web access (one of the great drawcards for SipX) was a surprise. From the instructions at the end of the install:
You will also need to adjust your %%APACHEETCDIR%%/httpd.conf file.
Ensure httpd runs as user sipx and group sipx. Ala:
User sipx
Group sipx
Change the document root to
DocumentRoot /usr/local/www/sipX/doc
The <Directory > instance should match
<Directory "/usr/local/www/sipX/doc">
That's impossible, of course. This is a real live web server. Instead, I did:
=== root@echunga (/dev/ttyp8) /usr/local/www/data 109 -> ln -s /usr/local/www/sipX/doc sipx
There are also some changes to httpd.conf, including:
Include /usr/local/etc/sipxpbx/httpd-sipxchange-common-ssl.conf Include /usr/local/etc/sipxpbx/httpd-sipxchange-common.conf Include /usr/local/etc/sipxpbx/httpd-sipxchange-configserver.conf
That doesn't work too well:
httpd: Syntax error on line 463 of /usr/local/etc/apache22/httpd.conf: Could not open conf iguration file /usr/local/etc/sipxpbx/httpd-sipxchange-common-ssl.conf: No such file or di rectory
That's a semantic error at best, of course, not a syntax error. But the real problem is that the files don't exist; there are only vanilla versions with the suffix .in.
Copy the .in files to the base name, and then re-start apache:
=== root@echunga (/dev/ttyp8) /usr/local/etc/sipxpbx 121 -> apachectl graceful
Syntax error on line 30 of /usr/local/etc/sipxpbx/httpd-sipxchange-common-ssl.conf:
Invalid command 'nokeepalive', perhaps misspelled or defined by a module not included in
the server configuration
Reading the file, I discover:
# mod_ssl has problems with HTTP 1.1
# Force browsers to use HTTP 1.0
SetEnvIf User-Agent ".*MSIE.*" \\
nokeepalive ssl-unclean-shutdown \\
downgrade-1.0 force-response-1.0
My web server is down because of these configuration issues.
It's not clear how to fix them.
This release is obviously out of date with respect to Apache.
A mod_ssl that doesn't support HTTP 1.1 sounds very dubious, and I most certainly don't want to downgrade my server to HTTP 1.0.
Reading ahead in the instructions, I discover I still have a PostgreSQL database to set up, and many other things.
This is most certainly not an “out of the box” installation.
| Tuesday, 13 February 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Somehow I couldn't face the prospect of looking at Asterisk today, so turned my attention towards some issues I have with mplayer:
The time display doesn't work well with the DVB-T MPEG streams that I capture from free-to-air TV. I had already done some work to address this issue, but it didn't work too well.
Because of the way LIRC works, I can really only ever have one running at a time. But I frequently watch part of a film and then postpone; so I need a way to restart where I left off. mplayer offers two ways to do this: start at a specific time, or a specific location in the file. But that breaks my current time kludges by setting the time to 0 at the start location.
Did a bit of work on a more general on-screen display routine and tried to compile it. There's been a new release of mplayer since the last time I worked on it, and it no longer compiles at all out of the box: it seems that something has changed in the FreeBSD Ports Collection, and mplayer no longer compiles under releases as recent as 6.2-PRERELEASE. Frustration.
Chris Yeardley showed up in the evening for a couple of days.
| Wednesday, 14 February 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Chris Yeardley is here, so we had to go out for a ride, despite the relatively high temperatures forecast. In fact, the temperature was only about 25°, and things weren't too bad, but Yvonne and Chris were both riding very young horses, so we went slowly and not very long.
It would have to be that I got a load of work (MySQL problems) to work on while Chris is here. Spent the rest of the day on them, but only got half way.
Di Saunders over for dinner; she's feeling better now after her problems last weekend.
| Thursday, 15 February 2007 | Echunga | Images for 15 February 2007 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
More work on MySQL today, mainly things like tuning and performance, things I've never looked at before. Fortunately there's a lot of documentation out there; most of it appears to be a matter of correlating the various suggestions.
The weather forecasts are as accurate as ever: no rain predicted for at least a week, and temperatures up to 40°. That didn't stop us getting rain, apparently out of a clear sky; the clouds developed later. The result was glistening rain:
|
|||||||||||||||||||||||
| Friday, 16 February 2007 | Echunga | Images for 16 February 2007 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Chris left early this morning, taking La Tigre and Luna with her:
|
|||||||||||||||||||||||
Now we're down to four horses, the fewest we've had in years.
Spent most of the day working on my system installation procedure, something I've been working on for nearly 3 years. The work on the Black Box has helped focus the effort, and now I have a make-based installation procedure that looks like it could work relatively well. The work was not helped by the failure of several ports to compile—and that on a virgin system.
| Saturday, 17 February 2007 | Echunga | Images for 17 February 2007 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
One of the surprisingly popular pages on my web site is my quick and easy beer page. I wrote it some time ago, and only recently—due to lack of time to do it right—tried it out. Of course there were lots of things I needed to change, including the fact that, for a first step, it was probably too difficult. Today split the page into two; the version on the original page is now about the absolute minimum needed to make a reasonable beer from the ingredients supplied in kits (notably, not fermenting at the positively idiotic temperatures—25° to 35°—that all kit manufacturers seem to recommend), and putting suggestions for improvement in a separate page.
After putting the web site up, monitored the hits. The hits on the base page continued at their usual rate, of course; the hits on the suggestions for improvement ran at less than 5%. That's sad, but it confirms that I was correct in going back to basics.
Apart from that, a little work on the system upgrade stuff. Still running into strange problems with the checkout. Left that for another day and watched TV.
| Sunday, 18 February 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Finally had time to look at my mplayer mods today.. It took me all day:
It tried to re-install lirc, something I really didn't want to do. On investigation, discovered:
.if defined(WITH_LIRC)
LIB_DEPENDS+= lirc_client.1:${PORTSDIR}/comms/lirc
CONFIGURE_ARGS+= --enable-lirc
Is this really a man page? I was later told that it was a dependency on liblirc_client.so.1, but that's really a strange way to spell it.
Building the new release of mplayer was non-trivial. It failed with library conflicts in the nVidia driver.
After removing the nVidia driver from the config, the program didn't work first time (of course). Fixing that was the easy bit.
Finally it worked, at least on wantadilla. Satisfied, went to the lounge room to watch some TV and—it didn't work! It seems that the nVidia driver was needed for the xvmc driver, so I had to go back and compile it in again. Somehow, this time it worked.
Back again in the lounge room, discovered that I had still managed to compile the thing without lirc support—something I must have done by accident.
What a pain! After all that, I didn't have any desire to continue. But I'm close.
So what do the changes do?
Added a new option -calctime to calculate the elapsed time from the current file position, rather than relying on the information in the file, which in MPEG streams from digital TV is completely random.
They give more control over the format of the on-screen display. The current version of mplayer gives only two variants; mine has 6, and they're format strings like "0:%h:%m:%s/%H:%M:%S (%p%%) %N", which shows elapsed time, total time, percentage and file name. Currently they're hard-coded, but it should be easy enough to add a startup parameter.
When the process stops before the end of the film, it prints a message stating the current time and file position (for the -ss and -sb options respectively) and also writes them to a file with a name derived from the file name of the input file with .time and .fpos appended. This should be dependent on an option, but currently is again hard-coded.
| Monday, 19 February 2007 | Echunga | Images for 19 February 2007 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
More work on the mplayer mods today. The problems with lirc proved to be due to the fact that they seem to have made some far-reaching changes in the new version of lirc, so clients that talked to the old version can no longer talk to the new one. They haven't fixed any of the problems I have seen, however; my patches applied with no problems.
Yana along this afternoon with her boyfriend Sundance. Spent most of the evening cooking:
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
| Tuesday, 20 February 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Finally got as far as to build the mythtv port again; I've had a number of updates to make, but I first wanted a repeatable platform to do it on. At least I now have that for the software; to get it running properly, I need to put in a tuner as well. I have plenty of these—at the moment a total of 5, of which 2 run under FreeBSD. But they don't fit in the low-profile machine I have, so I'll have to do some hardware rearrangement first.
The weather forecast is its usual accurate self. For today, it was:
Monday 16:05: A dry, warm to hot and mostly sunny day. Light to moderate southeast to east winds and moderate to fresh afternoon and early evening sea breezes.
Tuesday 3:30: Early thundery shower or two, clearing by around 8 am, then dry apart from a possible thundery shower near the northern ranges in the afternoon and early evening.
Tuesday 11:30: A possible thundery shower or two, mainly in the northern suburbs, clearing tonight.
What happened was in fact a dry morning, then a thundery shower round here, to the south-east, in the mid-afternoon. Of course it caused multiple power failures in the process of which I discovered that yet another UPS has died. This is getting very frustrating, and this time took up enough time that I had to miss yet another board meeting of the ICT Council for South Australia.
| Wednesday, 21 February 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Strangely, I now have five TV tuner cards available: two el-cheapo analogue ones, the Hauppauge PVR-250 from the Black box, and two DVICO DVB-T cards. Of these, I can currently only use one, one of the DVICO cards. For reasons already documented, the second identical DVICO card doesn't work properly. And FreeBSD doesn't have support for them, nor for one of the analogue cards. Decided to kill two birds with one stone and put the Hauppauge and the other “functional” analogue card, a BT 878 based card apparently called “TV Excel” which I thought I had got to work, after a fashion, about 2 years ago. FreeBSD's bt878 driver has improved over the years. Last time I tried, I had to find the tuner type manually; now the probe finds it.
That's about all that worked, though. Try as I might, I wasn't able to find any TV stations, no matter what card type I tried. It's not clear from my logs whether I was able to do so at the time, though I had thought so. In any case, I also have a project to move the pvr250 driver into the kernel, so tried installing that from the Ports Collection. That didn't work either: in the meantime, module builds have become more pedantic, and the code contains some const variables that get passed as parameters to system functions defined without const. Spent far too much time trying to find how the Makefiles decide to issue a -Werror flag to the compiler, but finally gave up and appended a -W-no-cast-qual flag to the Makefile. Then it built, and I just needed a new kernel, with the result that I didn't make any further progress today. Pedanticism makes for good code, but it can also certainly waste a lot of time.
| Thursday, 22 February 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Some years ago I had a subscription to “The Economist” which included an email service. Due to complete brokenness on the part of their mail and DNS, I never got any of the service for which I had paid for, and they ignored my complaints. I didn't renew the subscription, and was left considerably disappointed with the company.
But it's not over! Today I got spam addressed to gregecon@lemis.com, an address that I only ever divulged to The Economist. Sent a message to their abuse department, but I doubt I'll get a response:
This spam has nothing to do with me, except for the fact that it claims:> X-Postfix-Sender: rfc822; gregecon@lemis.com
This is a mail address that I have only ever used in connection with my subscription to "The Economist" in 2002-2003. The fact that the name has now surfaced suggests that you have somehow divulged this information to third parties. Please explain.
I have now disabled this address, though this doesn't stop third parties from abusing it. Please reply to the address above.
See http://www.lemis.com/grog/diary-feb2007.html#22 for a public discussion of this issue. I will also report whether you reply to this message or not. If you reply, please indicate if you do not want the reply to be published, and in this case why.
More playing around with the analogue tuners. Loaded the cxm driver for the Hauppauge card and ran scantv against it; again nothing was found. Tried various alternatives and got nothing, until I tried:
=== grog@tv2 (/dev/ttyp1) ~ 4 -> pvr250-setchannel -m 8 7=== grog@tv2 (/dev/ttyp1) ~ 5 -> cat /dev/cxm0 > foo^C=== grog@tv2 (/dev/ttyp1) ~ 6 -> l foo-rw-r--r-- 1 grog wheel 65638336 Feb 23 10:05 foo=== grog@tv2 (/dev/ttyp1) ~ 7 -> file foofoo: MPEG sequence, v2, program multiplex
mplayer confirmed that the content was a broadcast TV stream. So it seems that scantv doesn't understand the cxm driver, and in true multimedia tradition ignores any problems.
Moved on to trying to set up MythTV with the PVR 250. I never cease to be amazed. In the course of testing, discovered:
On the 1800 MHz P4 machine I was using, mythtv-setup takes 60 seconds of CPU time to start up, during which time the process grows to 335 MB in size.
When I finally got to the card configuration, it produced an error message
Could not open '/dev/cxm0' to probe its inputs.What error? Who cares, we're multimedia.
Running ktrace, found:
4233 mythtv-setup NAMI "/dev/cxm0" 4233 mythtv-setup RET open -1 errno 13 Permission denied
That's particularly strange, because I was able to open it as a normal user with cat. Looking at the node, it looked OK:
=== grog@tv2 (/dev/ttyp1) ~ 8 -> ls -l /dev/cxm0
cr--r--r-- 1 root wheel 0, 105 Feb 23 09:20 /dev/cxm0
Decided to look for the call top open to see what was going on; but for reasons I still don't understand, after setting a breakpoint on open, it called open without hitting the breakpoint. It seems that somehow more than one system call stub for open must have been included in the executable, probably as the result of dynamic library loads. Finally used find and grep to look for the text of the message (Could not open '). There the lack of consistency in the program came to my help: there's exactly one hit, in mythtv-0.20/libs/libmythtv/cardutil.cpp round line 565:
QStringList CardUtil::probeV4LInputs(QString device)
{
bool ok;
QStringList ret;
int videofd = open(device.ascii(), O_RDWR);
if (videofd < 0)
{
ret += QObject::tr("Could not open '%1' "
"to probe its inputs.").arg(device);
return ret;
}
There are so many things wrong here:
It's trying to open the card O_RDWR. This is an input device, and its permissions are set accordingly. Of course the open must fail.
When it fails, it doesn't report the cause of the error. We've seen this already, of course.
The value returned by probeV4LInputs is some obscure QObject. Looking at the code, it looks as if it might only take one parameter. Certainly I wouldn't be sure to know how to add the text of the error (apart, I suppose, from a sprintf to a local buffer to return). C++ may have some advantages, though I'm seeing fewer and fewer as time goes on, but this kind of code is unnecessarily obfuscatory.
I wonder if there are cases where the card needs to be opened for writing. This code seems to be intended only for probing, so I suspect that it's not the case.
So I set the permissions on /dev/cx0 to rw-rw-rw- and tried again. Same message. Well, almost:
Could not open '/dev/cxm0' to pr
But then, truncation, both vertical and horizontal, seems to be another hallmark of multimedia software.
Back to ktrace, which confirmed that the open now succeeded, but a subsequent ioctl failed:
4233 mythtv-setup NAMI "/dev/cxm0" 4233 mythtv-setup RET open 9 4233 mythtv-setup CALL ioctl(0x9,0x40685600 ,0xbfbfc890) 4233 mythtv-setup RET ioctl -1 errno 25 Inappropriate ioctl for device
In fact, during the probe the device was opened no less than 13 times. Came to the conclusion that mythtv was too lame to report the failed ioctl call, and it had failed before, so it had an error message to return, after first mutilating it.
But why was the ioctl failing? Possibly because the cxm driver doesn't conform to the standard ioctls. That's something for me to check out; first, though, tried recompiling without optimization to make using the debugger easier. That alone took an hour—why does C++ compile so slowly?—by which time the day was over.
Discussed the matter on IRC; we're all agreed that most multimedia software is a complete pain. It's so tempting to write your own; but there's a lot of good stuff in mythtv, so it's difficult to know which way to go. As the Germans say, außen hui, innen pfui.
| Friday, 23 February 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Did a bit of investigating the ioctl calls in the cxm driver, and quickly came to the recognition that they were, indeed, incompatible with MythTV. Investigated the possibility of adding them, and found the list (without comments, of course) in libs/libmythtv/videodev2_myth.h—all 57 of them, many referencing a struct v4l2_foo. Decided that that was too hard and moved on to confirm the installability of the package, in the process running portlint, which is supposed to check the correctness of a port. Some of the things it does are just plain stupid. It's clear that the sequence of declarations in a Makefile can have an influence on variables, especially when using constructs like ?=, but portlint considers the following to be a fatal error:
COMMENT= MythTV is a homebrew PVR project
BUILD_DEPENDS= qmake:${PORTSDIR}/devel/qmake \
${SITE_PERL}/${PERL_ARCH}/XML/Parser/Expat.pm:${PORTSDIR}/textproc/p5-XML-SAX-Expat
LIB_DEPENDS= mp3lame.0:${PORTSDIR}/audio/lame \
freetype.9:${PORTSDIR}/print/freetype2
There must be an empty line after the COMMENT definition. It also complains here that LIB_DEPENDS must come earlier in the Makefile (before BUILD_DEPENDS). But if you do that, it complains that BUILD_DEPENDS must come earlier. There doesn't seem to be any way to make it happy.
Later in the day heard from Stacey Son, the original author of the MythTV port. He confirmed that the cxm driver in its current form doesn't work with MythTV, and sent some patches. More work to do.
My mail to The Economist bounced: they don't have an abuse@ address. Searching the web page brought no useful contacts, so ended up spamming every address that wasn't obviously completely wrong, getting an automatic reply saying “your letter will be considered for publication”, and another one from the Asia-Pacific office apologizing for the inconvenience and promising follow-up. That's more promising, anyway.
| Saturday, 24 February 2007 | Echunga | Images for 24 February 2007 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Spent some time today working on Stacey Sun's patch to the cxm driver. It's a couple of years old, and although it applied cleanly, it seems that one of the structures has changed. It contains the following line:
const struct cxm_codec_profile *cpp;
...
codec->audio_bitmask = cpp->audio;
Unfortunately, there is no longer a member audio in struct cxm_codec_profile. Compiled anyway, but didn't get much tested.
It's been three months since our local BiLo supermarket was taken over by Coles. At the time I wasn't happy, but I thought I'd give them the benefit of the doubt. They've had that now, and have used up what good will I had left. Yesterday Yvonne bought some sausages labelled as “French Toulouse-style”. We should have been on our guard that they were sold for the barbecue—Toulouse sausages are typically used in cassoulet. It was clear the moment we opened the package that something was wrong, but it wasn't until I had grilled them that we found out how thoroughly disgusting the things are, a tasteless composition of gristle, cartilage and undefinable other meat parts with added “smoke” flavouring completely unrelated to the suacisses de Toulouse. You'd think they wanted to make the French look bad. A good justification for the actions in many European countries to protect place names from abuse elsewhere.
That's only one of the things we've had recently. On Monday Yvonne will return not only the sausages, but also some Feta cheese that tastes like polystyrene foam and rotten grapefruit:
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
We'll keep the coconut cream; although it's not marked as “lite”, it contains 50% more water than the cream I bought at Woolworths 3 months ago.
Coles clearly has the advantage of location, but is that enough? I'm really surprised how bad their products have turned out to be. In general foodstuffs have got much better in the last few decades.
| Sunday, 25 February 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Had intended to take it easy today, but somehow that didn't happen. Instead, finally got hold of a new version of the Hauppauge driver and tried to install it on tv2, my current test box. It installed without too much trouble, but then paniced out of msleep with the message sleeping without a mutex. Strange message! We used to have the opposite problem. Tried to get a dump, but the system hung. How long has it been since I've been able to get a processor dump reliably? Once upon a time the command panic out of ddb would do it for you, then we had to issue a call doadump, but today the dump hung in each case.
Decided to set up a firewire debugging session, but that doesn't work either any more unless you have firewire compiled into the kernel. Another afternoon's work bringing the system up to date and building a kernel.
In the meantime, looked at a couple of other issues: on VOB files copied from DVDs, my version of mplayer always showed the elapsed time as being equal to the total time. Tried recompiling it, again running into strange issues with asm directives that took me some time to fix, and also issues with debugging symbols. Somehow things used to be easier. Once I got that done, the problem was obvious: a simple cut-and-paste-o.
Also looked at my record program, which I had written specifically for the Linux DVB interface. Now I can use the Hauppauge card, I needed to get it to work for that as well. That took surprisingly little time and worked—almost correctly—first time.
| Monday, 26 February 2007 | Echunga | Images for 26 February 2007 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
More work on the cxm driver today, and came up with a patch that worked around this strange feature in msleep. This is almost close enough for me to be able to put it into the source tree.
Back to play around with mythtv-setup, which frequently displays in incorrect colours on remote systems. It now recognizes the tuner and can set it up; but the setup is so non-intuitive that I didn't make it. Yet another day's work.
Also tried a couple of approaches to video editing. I had tried LiVES earlier, and it didn't compile. Now I got it to compile, but on starting and trying to edit an 8 GB MPEG of a TV programme, was presented with a warning that it's not optiimized for large files. That's an understatement: it calls mplayer to convert every frame to a JPEG. I don't have enough disk for that, let alone enough time.
Then tried Jahshaka, which ran a lot faster:
=== grog@tv2 (/dev/ttyp0) /spool/Images 3 -> jahshaka bridget-jones
preferences are ok...
QLayout: Adding QLabel/unnamed (child of QFrame/unnamed) to layout for QFrame/unnamed
QLayout: Adding QProgressBar/unnamed (child of QFrame/unnamed) to layout for QFrame/unnamed
QLayout "maindesktopLayout" added to QHBox "desktop", which already has a layout
QLayout "Form1Layout" added to QHBox "unnamed", which already has a layout
(many repeats)
It ignored the file name on the command line, of course, and when I selected “Load” it was clear that it also ignored the current directory, giving me /usr/X11R6/lib/jahshaka/media, in which it apparently really intends to store media data. I couldn't change the path name, though: when I moved the mouse cursor to the window, I got:
Segmentation fault: 11 (core dumped)
A gdb session shows a 43 frame back trace through the Qt libraries, starting with:
#0 0x29e6325b in parse_fontdata () from /usr/X11R6/lib/X11/locale/lib/common/xomGeneric.so.2 #1 0x29e634be in parse_vw () from /usr/X11R6/lib/X11/locale/lib/common/xomGeneric.so.2 #2 0x29e64062 in create_oc () from /usr/X11R6/lib/X11/locale/lib/common/xomGeneric.so.2 #3 0x28c1e914 in XCreateOC () from /usr/X11R6/lib/libX11.so.6 #4 0x28c1dd5c in XCreateFontSet () from /usr/X11R6/lib/libX11.so.6 #5 0x285d49f8 in getFontSet () from /usr/X11R6/lib/libqt-mt.so.3 #6 0x285d4cb5 in QInputContext::setXFontSet () from /usr/X11R6/lib/libqt-mt.so.3
Probably a configuration error, but somehow I just can't be bothered with this kind of mess.
On the trip to Victoria I had been concerned by some strange noises from the suspension of the Commodore. Today I finally jacked it up and took a look:
|
|||||||||||||||||||||||
What's that? A shock absorber? The rod obviously fits into the slot to the right, and it has come loose. Strange that we first noticed it after picking it up from the last service.
| Tuesday, 27 February 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Mail from John Baldwin about the panic out of msleep today. He got me thinking. As dmr confirmed, the basic process synchronization primitives for UNIX have been sleep and wakeup since the PDP-7 days. A process initiates something and then calls sleep; the interrupt handler calls wakeup when it's done. The problem is that the interrupt handler might be so fast that it calls wakeup before the initiating process calls sleep, a classic race condition.
Traditional UNIX handles this situation by locking out interrupts until sleep is called. Here some code showing the paths traversed by the Third Edition vt driver (dmr/vt.c) dated 20 January 1973:
vtwrite()
{
int c;
int register count;
while (cpass(&c) >= 0) {
retry:
for (count=0; count<10; count++)
if ((VTADDR->csr&RQINT)==0) {
VTADDR->buf = c&0377;
VTADDR->csr =| RQINT;
goto contin;
}
spl5();
if (VTADDR->csr&RQINT) {
vtflag++;
sleep(VTADDR, VTPRI);
}
spl0();
goto retry;
contin:;
}
}
Here the call to spl5 locks out interrupts of a priority lower than 5, presumably including the vt interrupt handler. The priority is dropped before the process is completely suspended. From ken/slp.c:
sleep(chan, pri)
{
int s;
register *rp;
s = PS->integ;
if(pri >= 0) {
if(issig())
goto psig;
rp = u.u_procp;
rp->p_wchan = chan;
rp->p_stat = SWAIT;
rp->p_pri = pri;
spl0();
if(runin != 0) {
runin = 0;
wakeup(&runin);
}
swtch();
...
In view of the topic of synchronization, it's amusing to note that these two snippets were written by two different programmers (dmr is Dennis Ritchie, ken is Ken Thompson).
The problem in FreeBSD is that we no longer use the spl method of interrupt lockout. Instead, we use mutexes. It looks as if it should be pretty easy to use the same method with mutexes, but it's not as simple as that: the spl approach required work only in the “top half” of a driver, since it ensured that the bottom half couldn't run during that time. With mutexes you need to hold them on both sides. I need to find where and how to document this effectively; certainly it shows that yesterday's “fix” for the cxm driver was no such thing, just a workaround for the assertion.
More work on getting MythTV set up today. Tried to revive the MythTV HOWTO page that I started on for Linux nearly a year ago and then gave up because it was so much pain. That page is very much Linux-related, so decided to make a separate FreeBSD HOWTO page. The good news is that it's much easier. Got as far as the mythfilldatabase step, which produced much output and ended with:
===============================================================
| Attempting to contact the master backend for rescheduling. |
| If the master is not running, rescheduling will happen when |
| the master backend is restarted. |
===============================================================
2007-02-27 14:24:06.099 Connecting to backend server: 192.109.197.177:6543 (try 1 of 5)
2007-02-27 14:24:06.101 Connection timed out.
You probably should modify the Master Server
settings in the setup program and set the
proper IP address.
Further investigation showed that, though my port installs permissions for user mythtv on the local host, it doesn't (and shouldn't) install them for remote access, which for MySQL includes TCP access from the same machine. For security reasons you need to set that up manually. But as usual, the error message was completely wrong.
The next step was to get tuner data. The MythTV port depends on XMLTV, but for some reason that port doesn't include tv_grab_au port. Spent the rest of the afternoon making a port for that.
| Wednesday, 28 February 2007 | Echunga | |
| Top of page | ||
| previous day |
Still more work on MythTV today, mainly documenting what I did. I still don't really understand the internal connections; probably a diagram would help. Got as far as configuring a tuner input and confirming that it knew the correct channels, but on leaving mythtv-setup, I got a message saying “Your tuner is set to start on channel 3, which doesn't exist. Fix?“. I replied “Yes”, and it went away and did nothing for a while, but didn't fix it. I stopped mythtv-setup, restarted it and manually set the tuner to start on channel 28, which does exist. On exit, I got the same message about channel 3, and when I ran mythfrontend it also tried to set channel 3. Head-scratching time. I suspect that it's trying to use a different input.
Also had a couple of problems with the new driver:
For some reason, from time to time it fails to tune, conveniently not letting you know until you try to access the channel:
Mar 1 10:26:25 tv2 kernel: cxm0: SAA7115 rev 1 video decoder Mar 1 10:26:25 tv2 kernel: cxm0: MSP4418G-B3 audio decoder Mar 1 10:26:25 tv2 kernel: cxm0: IR Remote Mar 1 10:26:25 tv2 kernel: cxm0: [FAST] Mar 1 10:26:27 tv2 kernel: cxm0: encoder firmware version 0x2060039 Mar 1 10:26:27 tv2 kernel: cxm0: decoder firmware version 0x2020023 Mar 1 10:27:06 tv2 kernel: cxm0: video decoder isn't locked ... Mar 1 10:27:06 tv2 kernel: Could not detect FPS Mar 1 10:27:06 tv2 kernel: could not config dec Mar 1 10:27:06 tv2 kernel: could not start encoder
I decided to load the cxm driver at boot time. Bad idea! The system trapped out of fork_trampoline, conveniently just after starting the keyboard driver, with memory corruption. It was nevertheless related to the cxm driver, since it was consistent as long as I tried to load it like that. I'll leave further investigation until I've fixed the more obvious problems.
While thinking about the traditional sleep/wakeup synchronization model, it occurred to me that there's an issue with the newer function wakeup_one, which was introduced to deal with the thundering herd syndrome.
The problem with wakeup is that it wakes up all processes (or threads) sleeping on a particular address. In the past, few processes slept on a specific address, but Internet servers such as web and mail servers have changed that. The problem we have now is that we could have hundreds or even thousands of threads sleeping on a particular address. When the event occurs, wakeup wakes them all, though only one thread can handle the event. The first thread to be woken grabs the event and processes it; the remaining ones are scheduled long enough to discover that there's nothing to be done, and go back to sleep. The overhead for hundreds of threads going through this cycle for every connection to a web server can be crippling, and has given rise to the term “thundering herd”.
There's quite a simple solution to this problem: if only one thread can handle the event, only wake one thread. That's exactly the purpose of the function wakeup_one, and it works well. Clearly there are situations where all threads need to be woken, but when multiple processes are waiting on a read on the same socket, for example, you don't need to do so.
There is an issue with wakeup_one, however: threads call sleep or msleep with an address of their choice. Typically this should be the address of a structure that they control, but the system places no restrictions on this. With wakeup, an address collision causes no problems beyond (usually slight) performance degradation: if a thread is woken and finds that the condition on which it is waiting hasn't been fulfilled, it goes back to sleep again. When the thread for which the condition is fulfilled is woken, it runs. This works even for bogus conditions where no thread is waiting.
With wakeup_one, things are different. It's first come, only served. In the same situation, if the chosen thread is not the one that is waiting for the condition, it ignores it as before. But the one that is waiting doesn't get scheduled: it hangs. Clearly the choice of wait address is much more critical for wakeup_one than it is for wakeup.
Currently the FreeBSD 6-STABLE kernel has 458 calls to wakeup and only 30 to wakeup_one. At some point, people will migrate more calls to wakeup_one, and there's a danger of hangs as a result. So I added the following text to the kernel man page sleep(9):
The wakeup_one function does not work reliably if unrelated threads are sleeping on the same address. In this case, if a wakeup for one group of threads is delivered to a member of another group, that thread will ignore the wakeup, and the correct thread will never be woken up. It is the programmer's responsibility to choose a unique chan value. In case of doubt, do not use wakeup_one.
So far so good, right? But there's been a surprising amount of disagreement in the FreeBSD project. It seems that I'm being alarmist, or pointing at theoretical cases which could never really happen. I suppose that would change if somebody were to write a rogue device driver that causes a denial of service in this manner.
Do you have a comment about something I have written? This is a diary, not a “blog”, and there is deliberately no provision for directly adding comments. It's also not a vehicle for third-party content. But I welcome feedback and try to reply to all messages I receive. See the diary overview for more details. If you do send me a message relating to something I have written, please indicate whether you'd prefer me not to mention your name. Otherwise I'll assume that it's OK to do so.
| Top of page | Previous month | Greg's home page | Today's diary entry | Next month | Greg's photos | Copyright information |