NFS server unreachable in 0.21.0-62b5 (long)

[tsarath]

Hello,
I'm attempting to get 0.21.0-62b5 booting via NFS. I've had minimyth booting via NFS on another frontend before, so somewhat familiar with the setup process.

The PXE process goes fine, initial dhcp works, kernel loads but during the second DHCP process something goes wrong with messages as below;

INIT: version 2.86 booting
usbcore: registered blah...
usbcore: registered blah...
nfs: server 192.168.5.12 not responding, still trying
nfs: server 192.168.5.12 not responding, still trying

And it stops there. The NFS/BOOTP/DHCP server is on the 192.168.5.0/24 subnet and the client is on the 192.168.1.0/24 subnet. I've got the router forwarding DHCP request from the .1 to the .5 network correctly. Here is what I know and have tried;

- PXE works fine, I've got another LTSP client booting off the same sever from the .1 network;
- NFS server/exports are correct as I can mount the /export/minimyth-0.21.0-62b5 roofs correctly from another linux machine on the .1 network;
- I can change pxelinux.cfg/default file to load the ramdisk image version with 0.21.0-62b5 and this boots correctly (but takes a much longer time, hence nfs preference);
- I can get minimyth-0.21.0-58 nfs booting correctly with exactly two changes to the current config with the same setup, the pxelinux.cfg/default preference and the DHCP "root disk path" to point to /export/minimyth-0.21.0-58 instead;
- with 0.21.0-62b5 nfs, the client is pingable from the .1 network once its stuck but not from the .5 network(hence why it can't reach the nfs server to contonue), which leads me to believe the default gw/netmask is not being set correctly during the second DHCP, but I have no way to verify this on the client once it's stuck (can't telnet etc), but DHCP logs don't indicate anything unusual.

So why am I doing all this if -58 works properly? The client is using a brand new ASUS M3N78-VM motherboards with built in Nvidia GeForce 8200, which needs the latest beta Nvidia drivers. -58 boots but but does not load X11 due to the driver issue. Plus I want to leverage VDPAU once I get past this point with the 186.xx drivers.

The fact -58 nfs boots correctly leads me to suspect an issue with 62b5 and the interaction with the dhcp relay on my router (Cisco 7500) perhaps. Had the same issue with 62b3 build as well btw.

Any ideas?

Thanks

Tony

[Pablo]

In the NFS image, there is a file '/rootfs-ro/etc/udhcpc.conf'. Under the 'deconfig)' section of this script there are

Code: Select all

        IP_ADDRESS=`/sbin/ifconfig ${interface} | /bin/grep '^ *inet addr:' | /bin/sed 's%^ *inet addr:\([^ ]*\) .*%\1%'`
        if /usr/bin/test -z "${IP_ADDRESS}" ; then
            /sbin/ifconfig ${interface} 0.0.0.0 broadcast 255.255.255.255 up
        fi

and

Code: Select all

        while /sbin/route del default gw 0.0.0.0 dev ${interface} 2> /dev/null ; do
            :
        done

If you comment out these sections, does it work?
If so, if you comment out only the second section, does it work?
If not, if you comment out only the first section, does it work?

Without commenting out any sections in /rootfs-ro/etc/udhcpc.conf, does adding MM_INIT_TYPE=sh to your boot line make it work?

[tsarath]

In the NFS image, there is a file '/rootfs-ro/etc/udhcpc.conf'. Under the 'deconfig)' section of this script there are

Code: Select all

        IP_ADDRESS=`/sbin/ifconfig ${interface} | /bin/grep '^ *inet addr:' | /bin/sed 's%^ *inet addr:\([^ ]*\) .*%\1%'`
        if /usr/bin/test -z "${IP_ADDRESS}" ; then
            /sbin/ifconfig ${interface} 0.0.0.0 broadcast 255.255.255.255 up
        fi

and

Code: Select all

        while /sbin/route del default gw 0.0.0.0 dev ${interface} 2> /dev/null ; do
            :
        done

If you comment out these sections, does it work?
If so, if you comment out only the second section, does it work?
If not, if you comment out only the first section, does it work?

Without commenting out any sections in /rootfs-ro/etc/udhcpc.conf, does adding MM_INIT_TYPE=sh to your boot line make it work?

Pablo, you're a saviour! I commented out the whole section as there is no need for it to re-DHCP as it's going to get the same address anyhow from the server and viola! it worked. I've spent two days trying to diagnose this problem, I'm glad I posted here.

X11 doesn't quite load but I can alt least get a console/telnet login to fiddle around with the minimyth.conf further now. Here's the X11 log btw, guess this is why.

root@mythtv:/var/log # tail Xorg.0.0.log
(II) NVIDIA(0): Setting mode "1024x768"
(II) NVIDIA(0): First mode initialized

Backtrace:
0: /usr/bin/X(xf86SigHandler+0x9e) [0x80a22ae]
1: [0xb7f19400]

Fatal server error:
Caught signal 8. Server aborting

Open to ideas here too, X11 on the ram image for 62b5 works as I mentioned.

I'm happy to test for you btw, the mobo is a ASUS M3N78-VM (GeForce 8200) with a AMD Athlon X2 4850e which I bought specifically to get VDPAU support for MPEG2/4 acceleration as a diskless frontend. The backend is running on a Dell PE2500SC with dual PIII. The M3N78-VM uses a RTL8211CL Ethernet controller btw, not sure if it's related to the DHCP problem, unlikely I think as I tried nfs boot on my Thinkpad X61s last night and had the exact same issue.

Thanks

Tony

[tsarath]

Here's the full X11 log btw, quite long. I'll go through it, try a few things and post some further details later today.

http://thinkspace.ath.cx/stuff/Xorg_log.txt

Thanks

Tony

[Pablo]

Does it work when you comment out just the second section, or is commenting out both section required?

Based on the log file, it appears that MiniMyth has decided that you want a resolution of 640x480, which seems odd.

[tsarath]

Does it work when you comment out just the second section, or is commenting out both section required?

Based on the log file, it appears that MiniMyth has decided that you want a resolution of 640x480, which seems odd.

Pablo, I'll try commenting each section out individually later today to see which works. I'm not near my system right now.

On the X11 issue, I've set MM_X_MODE='640x480' in minimyth.conf as it was failing also at 800x600 with the nfs boot image to see if it would work, any recommendations? With the 63b5 ram image I'm able to get X11 to fire up (with MM_X_MODE='800x600'), connect to my backend and watch live tv (albeit with no sound and frequent pauses, but let's leave mythtv specific issues till later). So one approach would be to see how X11 behaves there and compare it with the nfs image behavior.

Looking through the X11 log more I noticed the following;

(II) NVIDIA dlloader X Driver 169.12 Thu Feb 14 17:55:38 PST 2008
(II) NVIDIA Unified Driver for all Supported NVIDIA GPUs

Shouldn't X11 be using the latest 180.11 drivers that you've included? Perhaps I'm misreading this...

Thanks

Tony

[tsarath]

In the NFS image, there is a file '/rootfs-ro/etc/udhcpc.conf'. Under the 'deconfig)' section of this script there are

Code: Select all

        IP_ADDRESS=`/sbin/ifconfig ${interface} | /bin/grep '^ *inet addr:' | /bin/sed 's%^ *inet addr:\([^ ]*\) .*%\1%'`
        if /usr/bin/test -z "${IP_ADDRESS}" ; then
            /sbin/ifconfig ${interface} 0.0.0.0 broadcast 255.255.255.255 up
        fi

and

Code: Select all

        while /sbin/route del default gw 0.0.0.0 dev ${interface} 2> /dev/null ; do
            :
        done

If you comment out these sections, does it work?
If so, if you comment out only the second section, does it work?
If not, if you comment out only the first section, does it work?

Without commenting out any sections in /rootfs-ro/etc/udhcpc.conf, does adding MM_INIT_TYPE=sh to your boot line make it work?

So I did some more testing as I promised. The offending line is the second section, i.e. deleting the default route makes my NFS server unreachable as one would expect if the server is outside of the current subnet. Commenting out just the first section alone did not work, commenting out both sections worked also as per my original post. Adding MM_INIT_TYPE=sh in the boot line did not work with the original script unchanged also.

I also made progress on the X11 issue. I was mistaken in my original comments perhaps as the ram image where X11 worked was the 62b3 and not 62b5. In 62b5 X11 did not start with both images. So I went back to the 62b3 nfs image, changed the script and viola! both nfs and X11 now works.

So the question is what changed between 62b3 and 62b5 for the X11 to not work with my graphics hardware?

Thanks

Tony

[Pablo]

So I did some more testing as I promised. The offending line is the second section, i.e. deleting the default route makes my NFS server unreachable as one would expect if the server is outside of the current subnet. Commenting out just the first section alone did not work, commenting out both sections worked also as per my original post. Adding MM_INIT_TYPE=sh in the boot line did not work with the original script unchanged also.

Thank you. I suspected as much. I will change the script so that it does not reset the routing table when the client has an IP address.

I also made progress on the X11 issue. I was mistaken in my original comments perhaps as the ram image where X11 worked was the 62b3 and not 62b5. In 62b5 X11 did not start with both images. So I went back to the 62b3 nfs image, changed the script and viola! both nfs and X11 now works.

So the question is what changed between 62b3 and 62b5 for the X11 to not work with my graphics hardware?

I suspect that the 62b3 version was downloaded from test/latest-62b3-nvidia.180.x.x directory, which is why it had the 180.x driver. On the other hand, I suspect that the 62b5 version was downloaded from test/latest, which is why it has the 169.12 driver. I still build the normal version with the 169.12 driver.

[tsarath]

I suspect that the 62b3 version was downloaded from test/latest-62b3-nvidia.180.x.x directory, which is why it had the 180.x driver. On the other hand, I suspect that the 62b5 version was downloaded from test/latest, which is why it has the 169.12 driver. I still build the normal version with the 169.12 driver.

Hi Pablo, I'm not sure as I can't find 62b3 on the site anymore. But 62b5 is the latest test and the Changelog says the following

Added packages
Added nvidia/nvidia-180.11.
Updated xorg-7.3/xf86-input-evdev.
Updated xorg-7.4/xf86-input-evdev.

So I'm a bit confused about the whole release numbering thing. Anyhow I hope you continue to pick up the latest Nvidia 180.xx driver changes in future releases for others like myself using more recent graphics acceleration hardware for Linux.

I know you said these drivers had problems with DPMS, but I was able to suspend and restart the system as a whole via the remote without any major issues. I haven't tried putting the monitor into sleep by itself though, this is not going to help much once I get this system connected to my TV anyhow.

I also managed to to get the Futaba dm-140gink VFD display on my Hiper HMC-2K53A case working well by substituting LCDproc 0.5.2 with the Henler patched version. It would be good have this in the base build in a future version perhaps.

BTW, do you know how I can check if Minimyth is using VDPAU based acceleration? Currently one SDTV MPEG2 stream from my backend running 12-14Mbps takes ~10% CPU on this frontend, seems a bit high compared to VDPAU HDTV benchmarks by others, so I was wondering...

Thanks

Tony

[tsarath]

BTW, do you know how I can check if Minimyth is using VDPAU based acceleration? Currently one SDTV MPEG2 stream from my backend running 12-14Mbps takes ~10% CPU on this frontend, seems a bit high compared to VDPAU HDTV benchmarks by others, so I was wondering...

Pablo, never mind on this question, I just read your earlier post on the same topic here.

http://minimyth.org/forum/viewtopic.php?t=2026

I don't really want to mess around with the backend upgrading to trunk either. However if you can make the VDPAU mplayer changes available together with 180.11 drivers that would be great, this build has disappeared from the link you had posted earlier and I couldn't find it elsewhere.

Thanks again for your great support,

Tony

[Pablo]

I suspect that the 62b3 version was downloaded from test/latest-62b3-nvidia.180.x.x directory, which is why it had the 180.x driver. On the other hand, I suspect that the 62b5 version was downloaded from test/latest, which is why it has the 169.12 driver. I still build the normal version with the 169.12 driver.

Hi Pablo, I'm not sure as I can't find 62b3 on the site anymore. But 62b5 is the latest test and the Changelog says the following

Added packages
Added nvidia/nvidia-180.11.
Updated xorg-7.3/xf86-input-evdev.
Updated xorg-7.4/xf86-input-evdev.

So I'm a bit confused about the whole release numbering thing. Anyhow I hope you continue to pick up the latest Nvidia 180.xx driver changes in future releases for others like myself using more recent graphics acceleration hardware for Linux.

The build system includes the multiple NVIDIA drivers, including legacy (96.43.07 and beta drivers (e.g. 180.11). However, a given binary image can only include one NVIDIA driver. At this time, the 169.12 driver as it appears to be the best tradeoff between supported hardware and lack of bugs.

I know you said these drivers had problems with DPMS, but I was able to suspend and restart the system as a whole via the remote without any major issues. I haven't tried putting the monitor into sleep by itself though, this is not going to help much once I get this system connected to my TV anyhow.

ACPI works, so suspend works. However, DPMS had bugs. While xset can put the monitor into standby, xset cannot bring the monitor out of standby.

I also managed to to get the Futaba dm-140gink VFD display on my Hiper HMC-2K53A case working well by substituting LCDproc 0.5.2 with the Henler patched version. It would be good have this in the base build in a future version perhaps.

I will add it. I have converted the changes into a patch against the vanilla lcdproc 05.2, and added this patch to the MiniMyth package.

For the purpose of auto-detection, I am assuming that this is the USB device coded into the patch (idVendor=0x040b,idProduct=7001). Is this correct?

[Pablo]

Pablo, never mind on this question, I just read your earlier post on the same topic here.

http://minimyth.org/forum/viewtopic.php?t=2026

I don't really want to mess around with the backend upgrading to trunk either. However if you can make the VDPAU mplayer changes available together with 180.11 drivers that would be great, this build has disappeared from the link you had posted earlier and I couldn't find it elsewhere.

I delete test releases rather quickly, maybe too quickly. I will post a new test version with the NVIDIA 180.x.x driver soon.

The mplayer-svn binary in the frontend contains the VDPAU patches. Therefore, as long as your binary contains the NVIDIA 180.x.x driver and you run mplayer-svn, then VDPAU should work on hardware that supports VDPAU.

Thanks again for your great support,

Thank you for testing.

[Pablo]

A new test build with the VDPAU enabled driver is available: 0.21.0-62b6-nvidia.180.x.x. It includes an updated NVIDIA driver and and updated MPlayer VDPAU patch.

[tsarath]

For the purpose of auto-detection, I am assuming that this is the USB device coded into the patch (idVendor=0x040b,idProduct=7001). Is this correct?

Yes, that's correct. dmesg reveals the following;

hiddev96: USB HID v1.10 Device [DM-140GINK Demo DM-140GINK Demo] on usb-0000:00:02.1-4.2
input: DM-140GINK Demo DM-140GINK Demo as /devices/pci0000:00/0000:00:02.1/usb1/1-4/1-4.2/1-4.2:1.1/input/input2
input: USB HID v1.10 Keyboard [DM-140GINK Demo DM-140GINK Demo] on usb-0000:00:02.1-4.2

And relevent output from "cat /proc/bus/usb/devices"

T: Bus=01 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=040b ProdID=7001 Rev= 2.00
S: Manufacturer=DM-140GINK Demo
S: Product=DM-140GINK Demo
C:* #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
E: Ad=02(O) Atr=03(Int.) MxPS= 8 Ivl=4ms
E: Ad=83(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 3 Ivl=3ms

[tsarath]

A new test build with the VDPAU enabled driver is available: 0.21.0-62b6-nvidia.180.x.x. It includes an updated NVIDIA driver and and updated MPlayer VDPAU patch.

Thanks Pablo!! Looks like the Nvidia VDPAU enabled drivers are evolving rapidly. I really think they will solidify their place in the Linux community if they get this right.

Sorry for the belated reply, I see you've included the DM-140 patch in this release as well, but I spend most of yesterday trying to fix my last major hurdle in getting a reasonable MythTV system. I managed to get DVI output working with my Sony KV-34HS510 in 1080i/720p modes, but I am still unable to get any type of sound (2Ch analog) when watching live/recorded TV on my frontend. Picture is more or less okay.

Here's the current situation;
- Sound for other media types except live/recorded TV works fine on the minimyth frontend, guessing this is because mplayer vs the internal mythtv player is used for these cases;
- Sound for live/recorded TV works fine on the backend server if I run the frontend app there. Xawtv also works with sound there correctly;
- I'm currently using an old Bt878 (AverMedia/Philips FI1236 tuner) based card on the backend with sw only mpeg2 compression. Plan to upgrade to a HVR-1600 later;
- I'm feeding the tuner card sound-out to the line-in looped externally on to a Creative SB Live! card correctly on the backend as I know this tuner card does not mux the audio into the mpeg2 video stream by itself;
- Backend is running CentOS 5.2 (2.6.18-92) with ALSA 1.0.14rc3 and MythTV 021-192.

I'm guessing the problem is in the backend as I had the same issue with frontend on a different machine. I'm going to be debugging this issue today and will test your nvidia patches soon after. Appreciate any input you or anyone here may have on this issue as I'm fast running out of ideas.

Thanks

Tony