Mark's Braindump

keepalived GARPs vs Windows Server 2008

mark — Fri, 31 Jul 2009 00:40:42 +0000

Windows Server 2008 appears to ignore GARPs entirely. There are some sketchy details here:

http://blogs.technet.com/networking/archive/2009/03/30/tcp-ip-networking-from-the-wire-up.aspx

(Seems like a daft solution to a problem that need not exist if the bizarre “checking for ip already in use” behaviour was simply dropped).

On top of that, if an ARP entry is in continual use it appears to never drop it from its ARP cache — the intention here is sensible, less delay to having to send/wait for ARP responses, however it doesn’t seem to do this via making the odd ARP request and checking for a reply. I’m not sure how it does do it, but I’ve observed that on a router role transition the ARP cache entry just sits there, even though the router no longer answers ARP requests for the old IP, and the behaviour appears to be indefinite (I observed an entry stuck for 10 hours).

My first workaround for this was to dump the ARP cache every so often by a scheduled task on the windows machine, which isn’t very elegant but does at least work. This has quite a long delay on switchover though, or a performance hit if you dump the ARP cache quite frequently, and I wanted to avoid that.

So my second work around involves two bits of software that let the router force the Windows machines to clear their ARP caches. The first part is a Windows service (called ArpFlush) that basically just sits and listens for UDP packets sent to a specific port. When it sees one, it clears the ARP caches for all the interfaces on the machine. The second bit of software is a simple application that sends UDP packets to the ArpFlush service and causes the ARP caches to be cleared. To glue this up to a role transition in keepalived I simply attach a notify_master script that causes an ARP flush request to be sent to a network broadcast address.

As a vague attempt at security, the ARP flush request simply contains a password, and the ArpFlush service only accepts packets that contain a correct password. (These random UDP packets definitely ought to be dropped by the firewall though if from an external source so I’m not too worried about them). In addition, since UDP is unreliable, the client sends (by default) 5 UDP packets at 1 second intervals. To avoid clearing the cache multiple times, the ArpFlush service stops listening for (by default) 10 seconds after it sees a flush request.

If you want to set this up:

Download either the 64-bit or 32-bit version of ArpFlush depending on which version of Windows you are running.
Install the package on the Windows machines. Configure by editing HKLM\Software\NPSL\ArpFlush (particularly probably worth changing the default password of TopSecret!)
Start the service. (The installer doesn’t do this because I couldn’t figure out how to stop it breaking if you didn’t have the CRT installed already)
Download the source for the client. Compile this with something like
gcc -o /usr/local/bin/arpflush arpflush.c
Test the service by running something like arpflush -a 10.0.0.255 -P TopSecret!. Check the application event log on the Windows machine to see if anything happened
Drop your arpflush command in a script and hook it up to keepalived with notify_master

With any luck it should all be funky after that.

Note that the above software is licensed under GPLv2, and you can get a copy of the source code for the Windows service from the svn repository linked on the right. It relies on a set of libraries I use for sockets/services/etc; this is called OW32 and is licensed under LGPLv2. The code for OW32 is in the same place. To build it I used MS VC2005, and Wix for the installer packages.

Goodbye, Microsoft…

mark — Sun, 07 Jan 2007 18:37:03 +0000

ARC-1160 SATA RAID updated

mark — Sun, 07 Jan 2007 18:25:36 +0000

Figured I might as well use this piece of software since I have to maintain it.

Basically to summarise my experiences with SATA RAID controllers (see here for the full details) under a basic stress load:

1. Adaptec 21610SA. Junk, very slow, locks up after about 4 hours.
2. 3ware 9550. Kicks drives out after about 10 minutes.

Then I got an Areca 1160. This works, kind of. It corrupts data, this is directly correlated with a ‘media error count’ that is visible only on the individual, detailed status page for each drive available through the card’s HTTP interface. After getting in touch with Areca they advised me that this was either power (I tried it with a pair of PSUs with the load split roughly evenly, so I don’t think that this is really the case), or it’s an issue with the firmware of the drives (16xWD320RE SATA disks).

However, entirely turning off the write cache makes the thing work OK, and it has done this for about a year. The write speed is absolutely pitiful though (and writes also kill reads). I get ~15Mb/s in moderately seek bound workloads, and ~30Mb/s for sequential writes. Hurrah, slower than some of my really old single IDE disks! Oh well, it’s good enough for a backup/TV server at any rate. Overall SATA RAID is still totally pants though!

SATA RAID is rubbish

mark — Fri, 14 Apr 2006 00:00:58 +0000

For the last 4 months, I’ve had a 4TB storage array (=16x320Gb WD RE SATA hard disks) sitting in my front room.

Doing nothing. Nothing at all.

The reason? SATA RAID cards are _unfeasibly_ bad. Here’s what I’ve tried so far, under linux (various kernel versions and distributions):

- an Adaptec 21610SA. This lasts about 4 hours before it does the classic aacraid: scsi hang? (google for it, lots of references). Adaptec sent me a “heat sync” (sic.) for some reason, in a russian doll style series of packaging.
- a 3ware 9550. This lasts about 10 minutes before it powers down a random drive (physically: you can hear it), then claims that the drive has been reset (well, duh). 3ware deny everything (the last thing they told me was that it was “noise on the PCI bus”. The 3ware card has been tried in a couple of different motherboards, same thing in both of them).

Is this isolated? From friends I know of:

- At least two other machines containing Adaptec AAC series cards with the scsi hang? issue;
- At least two other machines containing 3ware 9xxx cards that pop drives;
- At least one other machine containing a 3ware 9xxx card that pops drives under a different OS

Good news? I got to play with an Areca-1160. Managed 24 hours without an issue, so that’s the best so far. If I can find someone who distributes them in the UK, I’ll get one!

Random technical details:

- I break the cards with dd if=/dev/sdX of=/dev/null (x10); dd if=/dev/zero of=fooX (x10); bonnie++ (x10); and cp -a on a kernel tree (x10). IoW, just a bit of IO.
- The cards were tried in a P8SCi motherboard, 3Ghz xeon, plenty of power supply (including 1100W worth for some experiments)
- The P8SCi is on 3ware’s compatibility list
- 3ware card also tried in an Athlon64+H8SSL motherboard setup with a 760W power supply

I can’t believe these companies get away with peddling such crap. But then I suppose so do Highpoint and Promise to name a few I’ve seen shite (ATA-100/ATA-66) hardware off in the past.

Is SCSI any better?!

ClamAV Windows Port updated to 0.88.1

mark — Thu, 13 Apr 2006 23:47:54 +0000

Updated to latest version (0.88.1). I’ve updated in the interm; will try to post other updates in a timely fashion. Do let me know if you are using this, that will be an incentive to do so.

Other fixes are:

- Updated to build with VC8 (VS2005)
- Fix a number of extraneous close() calls that VC8 doesn’t like
- Fix service stub so that it works with w2k3

You can get the MSI installer & patch here.

Full source code can be downloaded here.

LIRC PVR-150 IR blaster support, version 3

mark — Sun, 15 Jan 2006 21:11:10 +0000

News

Latest: added a version that compiles with 2.6.27 kernels.
Latest: if you are packaging this, see the note at the bottom as to why I don’t provide a simple patch.
Latest: added an updated version that compiles with 2.6.24 kernels, tested against 2.6.23.12
Latest: updated `firmware` to a later revision from hauppauge (743 codesets)

HOWTO

This is not for the MCE version of the PVR-150. This includes a USB unit which does not work the same way as the normal PVR-150, use standard lirc (and lirc_mceusb) for that.
Use a recent kernel (note: the ivtv drivers have been part of the mainline kernel for a good number of revisions so no external drivers are required — sorry, I don’t know off hand which revision they were merged in), or for older kernels install ivtv-0.4.2+ (from this page). Earlier versions of ivtv _are not supported_.
Get the pre-patched lirc 0.8.5-CVS-pvr150 tarball. There are also earlier versions that can be found here, should you want them. The previous revision may be required for kernels < 2.6.27 (as it is untested on lower revisions -- in theory it should work)
You need the dialog package installed to use the lirc configuration GUI, so install that (apt-get install dialog, yum install dialog, whatever is appropriate for your distribution).
Unpack the patched lirc:
cd /usr/src tar xfj lirc-0.8.3-CVS-pvr150-2.tar.bz2 cd lirc-0.8.3-CVS-pvr150-2 ./setup.sh

Choose:
TV card
i – Hauppauge PVR-150 TV card (note: _NOT_ ‘g – Hauppauge TV card’)
Save configuration & run configure

then:

make && make install.
IR blaster only: Now you need the ‘firmware’. This is a set of data blocks that correspond to those generated by the windows software. This goes in /usr/lib/hotplug/firmware on my debian system. Depending on your system this might also be /usr/local/lib/firmware, /lib/firmware or /lib/modules.
Note that the entire firmware is kept in memory (currently 300K) so this makes the driver quite large. (I have no plans to sort this out, memory is cheap).
Check everything is working so far:
modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1

Check the syslog output. This should report something like:

Aug 28 02:09:11 soapbox kernel: lirc_pvr150: chip found with RX and TX
Aug 28 02:09:11 soapbox kernel: ivtv: i2c attach [client=Hauppauge PVR150 IR RX, ok]
Aug 28 02:09:11 soapbox kernel: ivtv: i2c attach [client=Hauppauge PVR150 IR TX, ok]
Aug 28 02:09:11 soapbox kernel: lirc_dev: lirc_register_plugin: sample_rate: 0
Aug 28 02:09:11 soapbox udev[5221]: creating device node ‘/dev/lirc0′
Aug 28 02:09:11 soapbox kernel: lirc_pvr150: firmware of size 302355 loaded
Aug 28 02:09:11 soapbox kernel: lirc_pvr150: 743 codesets loaded
Aug 28 02:09:11 soapbox kernel: lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0

This means that the driver has detected and initialised the IR blaster hardware — if you don’t see that then let me know.
You need to configure lircd, and find out which codeset you are going to be using. The easiest way is to start with this configuration file which contains key definitions for everything in the database. Do not use other lirc configuration files for specific STBs — these simply will not work. The IR chip is only capable of sending those codes which are in the database.
Start lircd. Note: if you are using a static /dev, you may need to make a device for lirc. If unsure, once you have verified that the module has been loaded ok, run ls -l /dev/lirc*. If you don’t see a /dev/lirc0 or similar, then try mknod /dev/lirc0 c 61 0 if the steps below fail.
modprobe lirc_dev && modprobe lirc_pvr150 debug=1 lircd --device=/dev/lirc0
You can now check if the remote is working using irw. Run this, and press buttons on the remote. You should see some output like
0000000000001795 00 Down Hauppauge_350.
Next, for the ir blaster you need to work out which codeset to use, this is the tricky bit. For this I have send_power_new, a script that just sends the power command in every single codeset. You may find your codeset number listed here if you are lucky.
Firstly, check that you are seeing the IR blaster blink. If you don’t have blinking lights at this stage, your cable probably isn’t in the card properly (try wiggling it around), or it may be broken.

Next you need to stick the IR blaster on the IR receiver of box that you intend to control, being quite careful to position it correctly — it has a very short range (a few cm) and took me a couple of goes to get right. The best way to do this is to find the IR demodulator on the box — easiest with a torch. Note that this is _not_ the light that comes on when you press a button on the remote, they tend to look like this.

If you can’t get this to work, please try and check it against the Windows driver if possible. If your device will work with the windows driver but not my driver, then it’s a driver bug that I should be able to fix. If it does not work with the Windows driver either then your only options are to use a different IR blaster or bug hauppauge until they add support for the box you are trying to control. At that point, I can update my
database too.
Once you know which codeset you want you can go and delete all of the rest from lircd.conf. They are named “XXX_key” so should be pretty easy to find. I also gave the keys standard names (0-9).
To get mythtv to work, configure a channel change script for your device. There’s one here that should work out of the box if you
rename the number keys.
If you’re happy, you can always send me beer money. If not, add comments at the bottom

That’s it, good luck!

Packaging

The lirc distribution tarball is generated using `make dist-bzip2` which uses the gnu autotools to generate a configure script, and Makefile.in, etc. The contents of these generated files depends very much on the version of autotools that is installed; this varies from distribution to distribution. I don’t have the same auto* as the lirc maintainers, so producing a patch file against a distribution tarball makes a patch bigger than the original source archive. Hence I don’t bother; I just make a new dist bzip2 and drop it here.

I maintain the code by importing a current lirc CVS into a subversion repository hosted on this server. I tag each lirc import, generate a diff from the previous lirc import and apply it to my source tree, then port any fixes from lirc_i2c.c to lirc_pvr150.c, test, and generate a new .tar.bz2. To get the source tree you can do:

svn co http://svn.blushingpenguin.com/svn/trunk/3rdparty/lirc lirc

and you can get the changes I made to the CVS revision of lirc with:

svn diff http://svn.blushingpenguin.com/svn/vendor/lirc/current http://svn.blushingpenguin.com/svn/trunk/3rdparty/lirc

PVR-150 IR stops responding (fixed!)

mark — Tue, 04 Oct 2005 06:42:12 +0000

Update
This patch, with some fixes, has gone into the 0.4.2 release of ivtv. Please use ivtv 0.4.2+ rather than following the instructions here. You can get this from the ivtv site.

History
This is related to my IR blaster driver, in case that’s what you are looking for. Do read on though, it might be informative! If you are just looking for patch instructions, dive right to the end to skip all this detail.

A while ago I looked around to see if the hauppauge windows driver for the remote control had any issues. I found quite a few people who claimed that it stopped responding, and that they had to reset the hauppauge software, etc and one or two pointers to a new (beta) driver on the hauppauge site. This was fairly intriguing as among the release notes it lists “i2c (IR blaster) fixes”. I managed to find time this weekend to take the driver apart, and see exactly what they did. Basically they rewrote the i2c support.

Some background, in case you aren’t familar: i2c is a low speed (varies, say ~100-400KHz) 2 wire serial bus for interconnecting various random chips. Because it’s so useful, it actually gets used all over the place to ‘glue’ various chips together on a board and then let the OS driver control them. For example, on your typical PVR-150 card you’ll find at least tuner, video encoder, IR chip and eeprom (configuration data). These are all i2c connected, and the driver talks i2c to them to program them (as well as other memory mapped registers, but let’s stick to the issue).

In some cases, the i2c protocol is implemented by special hardware on one of the chips (e.g. the bt878a chip has an i2c controller in it). This is the nice case, since the CPU doesn’t have to do much in the way of work. In the cheap case, you get to control the clock & data lines yourself from the OS (a kind of winmodem approach!). The hauppauge stuff takes the latter approach — indeed so does a bunch of other hardware. It’s so common that there is a module in the linux i2c subsystem specifically for doing this — it’s called i2c-algo-bit, and the approach is known as ‘bit-banging’. As a side issue, bit-banging takes up some constant fraction of CPU, because it has to use busy delays (it’s not possible to get microsecond accurate sleeps in the kernel, so we must run the CPU in a loop). Since these loops are constant _time_ you’ll find that whatever the CPU the IR polling (for example) takes a constant amount of time. For lirc_i2c, this works out at about 1%, and for my lirc_pvr150 module (that sends a ‘poll’ command to the receiver as well to see if it is borked or not), it’s about 2%. This is why I think the hardware approach is better, but whatever, we are stuck with it.

From the looks of the hauppauge driver changes it appears that the classical bit banging algorithm causes problems with the IR chip that the PVR-150 uses. I disassembled both the new and old drivers, and the older driver uses something very similar to the approach of i2c-algo-bit — it uses KeStallExecutionProcessor, or a busy loop, to implement delays. The newer driver dispenses with this, and instead polls the lines to see when they have become high/low and uses memory mapped register reads for stalling. I’m guessing that those reads are (roughly) constant time because they have to go across the PCI bus. I implemented the newer method, and low and behold this seems to solve my problems. I’ve not seen an IR chip reset by my lirc_pvr150 driver in 16 hours now (update: now 28), whereas I was getting them _much_ more frequently beforehand (dozens a day). This stops the remote dropping out if the chip has to reset, which it did do a few times a day for seconds at a time. So I’m happier. Anyway, if anyone else would like to try it, here’s the HOWTO part…

The HOWTO part

This patch is against the latest SVN version of ivtv. Things are changing rapidly with ivtv, and there is currently no really stable release (as you’ve probably realised). It might apply against the 0.3.8 release, if you try that and it fails let me know and I’ll post a patch against that version. It should go into the driver, eventually, if it really does sort out the IR chip issues.

Get the ivtv code from svn (you will need to apt-get install svn or whatever first!). See this page for detailed instructions.

svn co http://ivtvdriver.org/svn/ivtv/trunk ivtv

Download the i2c patch from the trac ticket for this issue (I will keep this up to date), or from from here. Apply the patch:

cd ivtv/driver patch -p0 < i2c.patch make && make install cd ../utils make && make install

Then reboot. Please _do not_ just rmmod ivtv & insmod ivtv — this won’t work. If you don’t want to reboot, rmmod _all_ of the ivtv modules first, especially cx25840. If you don’t do that, you’ll get an oops (then reboot, no biggie).
Note that this patch also covers section #3 of the IR blaster HOWTO, so you don’t need to try and apply both patches (if you do that, it will certainly fail to apply cleanly).

That’s it. You should stop seeing log messages related to resetting the IR chip, and the remote shouldn’t drop out at all. That’s the idea anyway. Any feedback would be appreciated!

HTH,

Mark

Nebula Digi-TV IR driver

mark — Tue, 04 Oct 2005 06:12:43 +0000

I bought one of these a while ago, and discovered that the remote control didn’t work. After lots of looking at the board, and the help of an accomplished friend with a multimeter we were able to discover roughly what it does. In essence, it’s really dumb hardware There’s an IR demodulator on the end of a wire in a nice box that you put somewhere. That goes back eventually to a flip-flop. Curiously, the output from the demodulator is connected to the clock signal of the flip-flop. This causes the output to be passed through back to GPIO pin 5 of the bt878a chip, which then triggers an interrupt. I’m not clear on how it triggers an interrupt from the datasheet (it’s not GPINT, and in fact it doesn’t seem to set any status bits in INT_MASK). You then prod GPIO pin 4 which is connected to the reset line of the flip-flop. That in fact clears the interrupt, and off you go again. So basically the interrupts give you the edges of the IR pulse train.

With that information, you then have a driver time the interrupts. The supplied remote is RC5, and the edge transition bit pattern can be converted directly back to an RC5 code. Actually works quite nicely, and with a bit of tuning I have it feeling nice and smooth. Obviously the driver isn’t limited to just that remote, all you need to do is cook your own keymap. Since, weirdly, the remote seems to have the RC5 address set to TV, it interferes with my TV. So I cooked myself a keymap for another remote that I have (a Hauppauge grey remote, which is RC5 as well), and I use that instead. This nasty interrupt method seems to feel much smoother than polling the on-board IR thing on the PVR cards, although I will be working on fixing that.

I posted a linux driver to the video4linux list (one that uses the input layer, like ir-kbd-gpio or ir-kbd-i2c). You can probably find the patch in list archives (or if you are interested and can’t find it — ask and I’ll send it to you).

Anyway, it was a bit of fun and that’s my second remote control driver. I think I quite like playing with hardware.

LIRC PVR-150 IR blaster support, version 2

mark — Sun, 28 Aug 2005 01:43:17 +0000

Final update
I have forward ported the code to the latest lirc release, fixed some bugs, and the i2c fixes have been merged into the ivtv-0.4.2. Please see this separate post, where I have removed all of the irrelevant history and only describe steps that are currently useful.

All new update
I’ve updated the ‘firmware’ file to include the new codesets recently released by hauppauge. This was a bit of a pain, as I had to disassemble my myth box to do it (bah, closed source). I hope they don’t do this too often in future! If anyone has got a spare PVR-150 or is willing to stick it in a windows machine and run wacky software then that would be nice the next time around Alternatively you can bribe me I guess!

Update
Quick update: I have been working with the ivtv driver to see if I can resolve the root cause of the problem with the IR chip locking up and needing to be reset. I think that I have done so, but I can’t be sure until I get more testing feedback. I’ve updated the howto below to point at this post which contains the details of how to install the patch to ivtv. If you’ve followed all of the steps below and are still experiencing intermittent remote drop-out issues (as a couple of people have noted), you might want to try this out. I realise that this is quite a long and complicated procedure, so I’m working towards getting all fixes into the release versions of ivtv & lirc eventually. Obviously I’ll keep this updated as things progress. Slight update: up to about 28 hours now with no remote issues. Very encouraging. Further update: it works. Has been for months, and for others too. It’s in the 0.4.2 candidate release, so hopefully this issue should just die at some point. It also looks like hauppauge have put this in their mainline driver, which was updated some time in October. I’ve not disassembled it to check yet though

I’ve uploaded a slightly newer patch/package correcting two bugs. The first is not to reset the IR chip if you try and send an invalid code (by messing with lircd.conf!) since this clearly isn’t necessary. The second is a stack overrun bug spotted by Pascal Brisset, which could have had nasty consequences. I guess since I’ve not seen it the way I use lirc it’s only sending one code at a time to the driver. btw, this stuff is in my SVN repository, under trunk/3rdparty/lirc, if you want to do development on it.

The old stuff
OK, I’ve been playing with this off the back of the basic problem that seems to have been encountered by a lot of people, myself included — after a while the IR chip on the PVR-150 locks up, and hence the remote/blaster stop responding. (This happens with release versions of lirc/ivtv, so is definitely not related to what I’ve been doing with the IR blaster). This problem is pretty difficult to reproduce (i.e. I can’t do it on demand), but only seems to happen if you are using the encoder on the card at the time. I tried reproducing it with the Windows software, but I couldn’t manage it. I might not have tried hard enough; google search show that quite a few people have got this to fail, or it might be that hauppauge fixed the problem at some point. I don’t really know anything about this chip (it’s some software running on a fairly general purpose CPU, so it would be hard to without explicit information from hauppauge or some reverse engineering of that code, which is beyond me at this point in time), so I’m not sure why it happens. If anyone from hauppauge wants to step up and provide me with some information I’d be very happy!

There does exist a sort of solution for this: ivtvctl provides an ioctl that resets the IR chip on the card. Some people have this running every minute from a cron script, whilst that’s not a great solution it is a workable one. My issue with that is if you reset the IR chip, you have to send the boot block again to the IR blaster, so if I’d adopted the cron script I wouldn’t be able to change channel any more.

So after all that, I’ve adopted a delightful solution — detecting when the IR chip has locked up (i.e. stopped responding to i2c traffic), and resetting it in the driver. It’s messy, but it works, and as I do it in the driver, I can transparently retry IR blaster sends, which saves me from recording the wrong channel. Anyway, that was a bit long, so here’s a changelog:

- Split the code out into a new lirc driver, lirc_pvr150.
- TX and RX portions are treated as a single device. This makes good sense as you then only have one lirc socket that supports both receiving and sending (if the TX hardware is actually found).
- The RX device is ‘polled’ in the same way that the windows driver appears to. This is a good place to detect whether it has died or not.
- IR device is reset on failure and operations are retried (needs ivtv patch)
- A local copy of the ‘firmware’ data is made and release_firmware() is called. This prevents a hotplug timeout that I used to see (the script expects that firmware is released when loading is finished).
- Merge with lirc-0.72 release (rather than pre2)
- Module is reference counted properly
- Module has parameters disable_rx and disable_tx. You can use, e.g. modprobe lirc_pvr150 disable_tx=1 if you are not interested in setting up the IR blaster device.

Here’s the updated HOWTO for this version:

1. Get the pre-patched lirc 0.7.2 (or just the patch should you prefer).
2. Unpack the patched lirc (or apply the patch)

cd /usr/src tar xfj lirc-0.7.2pvr150.tar.bz2 cd lirc-0.7.2pvr150 ./configure

Choose:
TV card
h – Hauppauge PVR-150 TV card (note: _NOT_ ‘g – Hauppauge TV card’)
Save configuration & run configure

then:

make && make install.

3. Note that this step is no longer necessary with ivtv >= 0.4.0 (the current stable release series), which is recommended — the export symbol patch was included. Skip right on to step 5 if you’ve grabbed the latest stable release, or go to 3a if you are having ‘remote stops responding’ issues (doesn’t seem to affect everyone).
3a As an alternative to the below, see this post. Don’t do both. I’ll update this if that patch proves to solve problems for people. I am hoping it might, it’s working very well for me so far.
3b Patch your ivtv driver and rebuild it. This step is necessary to be able to reset the IR chip. Download the patch here. Note that this patch does not apply to some versions of ivtv. I’m currently using 0.3.7a, so it should apply cleanly to that. If you want to use a later driver, the change is actually pretty trivial, we just need to export an extra symbol. In drivers/ivtv-driver.c, you need to add:

#include “ivtv-gpio.h”

near the top of the file after the rest of the #include lines, and

EXPORT_SYMBOL(ivtv_reset_ir_gpio);

right at the bottom of the file where all the other EXPORT_SYMBOL lines are. All this does is export that symbol for use by other modules, it does not change the functionality of the driver in any way. If you have trouble with this then drop me a line and I will create a patch for the version of ivtv you want to use.

cd /patch-to-ivtv-driver (e.g. cd /usr/src/ivtv-0.3.7a) cd driver patch < ivtv-driver.c.patch cd .. make && make install

4. Unload & reload the new ivtv driver. If lucky, rmmod ivtv && modprobe ivtv, otherwise either
kill everything that might be using the driver/unload all dependent modules or just reboot if you can’t be bothered with that.

5. IR blaster only: Now you need the ‘firmware’. This is
a set of data blocks that correspond to those generated by the windows software. This goes in /usr/lib/hotplug/firmware on my
debian system. Depending on your system this might also be /usr/local/lib/firmware, /lib/firmware or /lib/modules.

Note that the entire firmware is kept in memory (currently 200K) so this makes the driver quite large.
(I have no plans to sort this out, memory is cheap).

6. Check everything is working so far:

modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1

Check the syslog output. This should report something like:

Aug 28 02:09:11 soapbox kernel: lirc_pvr150: chip found with RX and TX
Aug 28 02:09:11 soapbox kernel: ivtv: i2c attach [client=Hauppauge PVR150 IR RX,
ok]
Aug 28 02:09:11 soapbox kernel: ivtv: i2c attach [client=Hauppauge PVR150 IR TX,
ok]
Aug 28 02:09:11 soapbox kernel: lirc_dev: lirc_register_plugin: sample_rate: 0
Aug 28 02:09:11 soapbox udev[5221]: creating device node ‘/dev/lirc0′
Aug 28 02:09:11 soapbox kernel: lirc_pvr150: firmware of size 20927 loaded
Aug 28 02:09:11 soapbox kernel: lirc_pvr150: 575 codesets loaded
Aug 28 02:09:11 soapbox kernel: lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0

This means that the driver has detected and initialised the IR blaster hardware — if you don’t see that then let me know.

7. You need to configure lircd, and find out which codeset you are going to be using. The easiest way is to start
with this configuration file which contains
key definitions for everything in the database.

8. Start lircd. Note: if you are using a static /dev, you may need to make a device for lirc. If unsure, once you have verified that the module has been loaded ok, run ls -l /dev/lirc*.
If you don’t see a /dev/lirc0 or similar, then try mknod /dev/lirc0 c 61 0 if the steps below fail.

modprobe lirc_dev && modprobe lirc_pvr150 debug=1 lircd --device=/dev/lirc0

9. You can now check if the remote is working using irw. Run this, and press buttons on the remote. You should see some output like

0000000000001795 00 Down Hauppauge_350.

10. Next, for the ir blaster you need to work out which codeset to use, this is the tricky bit. For this I have
send_power_new, a script that just sends the power
command in every single codeset (575 at present).

You need to stick the IR blaster on the IR receiver of box that you intend to control, being quite careful to position
it correctly — it has a very short range and took me a couple of goes to get right. Some people have reported needing
to have the device attached back to front.

If you can’t get this to work:

a) My software doesn’t work properly
b) The device you are trying to control is not supported (please check against the Windows stuff if possible)
c) You didn’t get the device in the right place — did I mention it was touchy?

11. Once you know which codeset you want you can go and delete all of the rest from lircd.conf. They are named “XXX_key”
so should be pretty easy to find. I also gave the keys standard names (0-9).

12. To get mythtv to work, configure a channel change script for your device. There’s one
here that should work out of the box if you
rename the number keys.

That’s it, good luck!

LIRC PVR-150 IR blaster support updated

mark — Fri, 19 Aug 2005 01:13:35 +0000

I have updated the patch with the following changes:

- Use schedule_timeout not mdelay as mdelay is a busy loop. This fixes high CPU usage during IR sending.
- Drop out of the polling loop when the chip is ready rather than after 1s (can’t believe I didn’t notice this one!). This greatly speeds sending.

As a consequence of the second point, I recommend that you fiddle with the ‘gap’ parameter in lircd.conf. The gap parameter is in microseconds. For my particular cable box, I’ve found that 1/3s (~333,333us) works well. The minimum time is until the chip is ready to send, this works out roughly at about 50-200ms. The minimum delay is fixed at 50ms (avoids wasting CPU; go hack the code if you want to change this), and the maximum wait is 1s.