I had a lot of trouble with xfs with 2.6.30. I had to migrate everything from xfs to ext3. So I recommend those that use xfs file system not to upgrade to 2.6.30 or plan for migrating the file system.

I got both the MPEG2 and finally the DVB to work now with MythTV. I am now totally happy recording QAM TV signals from cable. The trick to get DVB to work is to change the file under:

./libs/libmythtv/dvbtypes.h

//#if (DVB_API_VERSION != 3)
#if (DVB_API_VERSION != 3 && DVB_API_VERSION != 5)

and the line

//#if (DVB_API_VERSION >= 3 && DVB_API_VERSION_MINOR >= 1)
#if ((DVB_API_VERSION >= 3 && DVB_API_VERSION_MINOR >= 1) || (DVB_API_VERSION > 3))

I found the solution while googling. The 950Q has some problem with the arm port. I did not have time to get it fix since I want a DVR urgently. I am happy that the plugcomputer solution worked out before my vacation. Now I can record video and watch it when I get back. This is all thanks to your work on this subject.

I gave up on the HVR 950Q and got the 1950 you did. I do not see MPEG2 card as you did. I only see MJPEG or MPEG4. Which one is the QAM installed? I am using analong only for now.

I am trying to do the same thing with HVR-950Q USB card. Where exactly do you place the firmware to? I put it under /lib/firmware/dvb-fe-xc5000-1.1.fw and also in /lib/firmware/2.6.30/dvb-fe-xc5000-1.1.fw

Perhaps it is just simply does not work. I need some advice in this.

Try to neutralize the hal script by changing it to something harmless. Hald is really not a necessity. I would basically install everything by download the raw source myself and compile it on Sheeva plug.

Oh, I noticed ion the default kernel config file provided by Sheeva plug computer, the floating point emulation modules was not installed. So I added that in. I am not sure if that was intentional or not. In any case, it is worth to check it out.

I also had problem with key generator in bind for that timed out forever. I suppose there might not be good enough random number generator built into the plug for certain tool to work. So watch out for those problems.

I have the similar card with the same vendor. It was detected right off the bat after I recompiled the kernel and install the modules (note, I did not reinstall the kernel since I kept everything the same.)

The easiest way is copy the default config file from Marvell's documentation. Then export INSTALL_MOD_PATH to a local directory. make;make modules_install.

I bench mark the file transfer performance with ext3. There were no performance differences. I may need to tweak my kernel performance such as kernel priorities and add a few more io scheduler options. In any case, I too wish there was an eSATA output connection on the plug computer.

I forgot to mention this problem seem to only occur on Windows VISTA machine. When I connect the same Windows VISTA machine to a file server using x86 opteron processor, then transfer speed can go up to 40MB/sec to 50MB/sec. In any case, I still believe this may has something to do with how kernel treats the priorities of tasks. I will spend more time tweaking the kerenl and post my results on this fourm.

I only have problem with gnome under tightvnc session. Basically the gnome-terminal complains that the RENDER is not supported. Does any body have a work around for this?

When you say you started to boot from SD, did you use the SDIO or use a USB -> SD converter? If using the SDIO, how did you get the uboot to recognize the location?

I believe the xfs was the wrong choice for the file system when using the drive under USB. What file system did you choose for your USB drive?

The Sheeva plug computer seem to be quite slow with JAVA. An old java program I used ate up around 80% cpu time. I am not sure if that is the fault of JRE or something else. Otherwise, most things seem do reasonably well.

I get the same thing regarding the bad memory block. To tell  you the truth, I rather boot directly from harddisk anyways. In any case, I have not seem this affecting me much. I supposed they may have blocked out the bad memory block when writing to it.

I do not have the long login problem. I recommend checking the following:

1. Check how your samba password is being read. Is it the right command sequence? the set of command you should check are:
passwd * in the smb.conf

2. I always have a usermap. I am not sure if that helps or not.

3. I always create smbpasswd over the unix one. To do so, just do smbpasswd -a username

It basically creates a copy of the samba password. It is great for keeping unix password different than the regular one.

In any case, I have an update on the performance.

1st. I changed from anticiptatory io scheduler to noop. That seem to work quite well until until something starts to slow me down. I believe the low bandwidth of USB is coming to hurt me.

2nd. I messed around with a few classic option of the smb.conf:

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_SNDBUF=16384 SO_RCVBUF=16384

In addition, I strongly believe I picked the wrong file system. The reason is that xfs may be too resource hungry for it to be efficient. Something simple like ext3 may have been a better choice. I won't be able to know for certain until I get chance to migrate. That will won't be for a long time.

I have recently added a samba and USB harddisk to the Sheeva plug computer. When I test the file transfer, I max out around 18Mb/sec when I know the USB hub and USB harddisk could actually go up to 30MB/sec if I do a straight copy. I also notice that some of the VM option typically recommended by Samba is not there. Have any body have experience on optimizing samba performance with the Sheeva plug computer?

I was able to customized a kernel based off the default one they have. I tried it twice before getting it to work. For some reasons, there are a couple things you have to watch out:

1. First make sure the uImage size is same as the default. Otherwise, you will not have enough memory.
2. I deleted the kernel bootcmd and it caused some problem. I suspect that and the RAID driver are fairly important.