MSI WIND PC, has anybody tried this yet??

[totallymaxed]

Andrew - did uplink have a chance to look at my last question? I'm still a bit stumped on which is the actual chip, and so what to compile for it...

EDIT:

OK, I plunged in anyway and tried following the wiki instructions you indicated. (although I'm not sure I'm even building the right driver!) It created the r8169.ko file successfully and I moved that into the running kernel's drivers/net directory (although I realise it isn't the core I'm having problems with its an MD).

Then modified the initramfs-tools-interactor/module file to include "r8169" on the line after the only existing extry "sky2" and ran the Diskless_BuildDefaultImage.sh script.

I'm assuming that this just creates the boot code that gets tftp'd to the MD on start up, and so should now include a driver for r8169....

But now when it boots, it doesn't seem to say eth0 down any more (and there is some other change in the text of the boot sequence that goes by too fast for me to read!) - instead, immediately after saying that it has registered protocol 17 (that's TCP isn't it?) it says:

ipconfig: no devices to configure
/init: .: 1: Can't open /tmp/net-eth0.conf
Kernel panic - not syncing: Attempting to kill init!

Not sure, but I seem to have gone backwards....

Hi Colin,

Well as far as I can see having researched this the RealTek 8111C is definitely the NIC chip used in the Wind and this chip needs the r8169 driver. Uplink is traveling today but will be in the Office Monday lunchtime GMT and I will have a chat with him again then about how we get this working.

All the best

Andrew

[colinjones]

Thanks so much, Andrew!

[colinjones]

Andrew - did uplink have any ideas that might help? Are there any other steps I could take?? So close but so far!!

[niz23]

colinjones.

Andrew - did uplink have a chance to look at my last question? I'm still a bit stumped on which is the actual chip, and so what to compile for it...

EDIT:

OK, I plunged in anyway and tried following the wiki instructions you indicated. (although I'm not sure I'm even building the right driver!) It created the r8169.ko file successfully and I moved that into the running kernel's drivers/net directory (although I realise it isn't the core I'm having problems with its an MD).

Then modified the initramfs-tools-interactor/module file to include "r8169" on the line after the only existing extry "sky2" and ran the Diskless_BuildDefaultImage.sh script.

I'm assuming that this just creates the boot code that gets tftp'd to the MD on start up, and so should now include a driver for r8169....

But now when it boots, it doesn't seem to say eth0 down any more (and there is some other change in the text of the boot sequence that goes by too fast for me to read!) - instead, immediately after saying that it has registered protocol 17 (that's TCP isn't it?) it says:

ipconfig: no devices to configure
/init: .: 1: Can't open /tmp/net-eth0.conf
Kernel panic - not syncing: Attempting to kill init!

Not sure, but I seem to have gone backwards....

As Andrew indicated above your machine seem to have a different ethernet card onboard than the EEE boxes.
The message you posted indicate that there is no driver loaded or at least none that can identifiy and activate your card since ifconfig complain that it cannot find an eth device to configure.

Sorry, I cannot be of more help.

[totallymaxed]

Andrew - did uplink have any ideas that might help? Are there any other steps I could take?? So close but so far!!

Hi Colin,

I tend to agree with Niz23... it looks like you still do not have the correct driver loaded for the 8111C NIC.

I guess there are two obvious possibilities... one you made a simple mistake when adding the R8169 driver or this driver is still not the correct one. So I would suggest going back over the steps to add the driver to check for simple mistakes. If that does not work you could try the R8168 driver instead and see if that fixes the problem. If neither of these works then my guess is that the driver needed is not either of these and you will need to do more research I'm afraid.

Sorry I cant be more directly helpful!

All the best

Andrew

[nosebreaker]

I see that lots of people have had this problem with Linux in general for this board, I'd try to get the system to work as a plain Kubuntu box first and get the NIC working.

[colinjones]

Guys - thanks for the help!

OK, I put Damn Small Linux on a 64MB USB key and booted the Wind PC from it so that I could run lspci and got:

RTL8111/8168B (rev 02)    using -n the ids for this are

10ec:8168

Given the instructions on the page Andrew linked to, doesn't that mean that we commented out the 8168 id? Is this perhaps the issue - that it is reporting 8168 as the product id but that isn't mentioned in the driver? Does this help you understand what is wrong at all??

Also, noticed this thread http://ubuntuforums.org/showthread.php?t=723569 (the last post) I don't understand enough about how linux selects and uses drivers to be able to pull this info (the thread and the lspci info) into a solution, so I'm crossing my fingers that you guys can make sense of it!! I get the gut feeling that the info is there....

[colinjones]

Update:

OK, seems I was getting confused between r8168 and r8169, and which we were trying to fool the other to be! I went through the http://wiki.linuxmce.org/index.php/Unrecognized_NIC article again and edited the intial ramdisk image modules file to say r8168 instead of r8169 and now it boots. Strangely, the DHCP process takes MUCH longer than before. And the eth0 goes up and down repeatedly many times during the boot sequence, but eventually settles down. Finally the image build kicks off then I went in and changed the diskless image modules file. But when trying to chroot so that I can rebuild the initramdisk image again I get

chroot: exec format error which is indicative that for some reason the image built as AMD64 rather than i386. Just changed that, and will try again.... more later

[colinjones]

Completely lost now!

I followed the instructions to add r8168 to the modules file for initramfs-tools-interactor and remade that image.

Initially, this seemed to work, as I said - it indicated in the boot sequence that r8168 was being loaded and the link was up. Now, it is saying r8169 again....

I am suspecting that because it chose the wrong architecture (AMD64 instead of i386) and I used the webadmin to rebuild the image, it has somehow put the old vmlinuz image back in with the r8169 driver. Does that sound right? BuildDefaultImage.sh only updates the default vmlinuz image, so that would imply that the webadmin is rebuilding the image from another source rather than the default image in tftp....

Getting tied in knots now! Tried copying the /boot/vmlinuz to /usr/pluto/diskless/54/boot and still the same result....


Can someone please help untie me and explain how this works, and how I have managed to get back to 8169? If it is the webadmin, I don't know how to get around that because it selects the wrong architecture so I have to correct that and rebuild from the web admin....

[totallymaxed]

Completely lost now!

I followed the instructions to add r8168 to the modules file for initramfs-tools-interactor and remade that image.

Initially, this seemed to work, as I said - it indicated in the boot sequence that r8168 was being loaded and the link was up. Now, it is saying r8169 again....

I am suspecting that because it chose the wrong architecture (AMD64 instead of i386) and I used the webadmin to rebuild the image, it has somehow put the old vmlinuz image back in with the r8169 driver. Does that sound right? BuildDefaultImage.sh only updates the default vmlinuz image, so that would imply that the webadmin is rebuilding the image from another source rather than the default image in tftp....

Getting tied in knots now! Tried copying the /boot/vmlinuz to /usr/pluto/diskless/54/boot and still the same result....


Can someone please help untie me and explain how this works, and how I have managed to get back to 8169? If it is the webadmin, I don't know how to get around that because it selects the wrong architecture so I have to correct that and rebuild from the web admin....

Hmmm... you may have cross architectures. Is your Core i386? What does Web Admin say the MD's architecture is? Also remember that if you Regenerate the MD from Web Admin then you must rebuild the initial RAM disk.

Andrew

[colinjones]

Both are i386 - I have no idea why it chose amd64 but when I got the error trying to do chroot I checked the architecture in the web admin and it said amd64! So I changed it and rebuilt the image. I'm thinking that this has put back the original initial ramdisk so it was using the 8169 driver even though the modules file still lists 8168. I ran BuildDefaultImage script but that didn't fix it up - I believe that only effects new MDs, so I tried copying the vmlinuz file from the default image folder into the MDs folder and that didn't seem to fix it either....

[colinjones]

Update:

I have deleted the MD completely. Using http://wiki.linuxmce.org/index.php/Realtek_8168 I had already built the new 8168 driver and hacked the existing 8169 driver. I thought through what we are doing, Andrew can you confirm if my understanding is correct?

It seems that the 8169 driver is trying to provide for the 8168 chip (as well as the 8169 and others) but apparently this doesn't work. So the editing and recompiling done for the 8169 driver is to remove the 8168's PCI product ID from it so that the kernel doesn't consider the 8169 driver appropriate for the 8168 chip. We then compile and insert the real 8168 driver module so that the kernel picks that one instead. True?

So I made the initial changes http://wiki.linuxmce.org/index.php/Unrecognized_NIC to include the correct driver in the default initramfs and that works fine to get the MD booted first time and start building its diskless image. Once that was complete, I went into the web admin and changed it to i386 and rebuilt again.

Then I copied both the r8168.ko and r8169.ko modules into the diskless image in the same location, added r8168 to the diskless /etc/modules and /etc/initramfs-tools/modules files, and finally ran the mkinitramfs command to create a new initramfs that presumably would then include the new/updated driver modules and the modules files telling it which driver to use.

But I still get a kernel panic! It doesn't seem to be finding any ethernet hardware now. Message:

ipconfig: eth0: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
/init: .: 1: Can't open /tmp/net-eth0.conf
Kernel panic - not syncing: Attempting to kill init!

I feel like I am SO close, but I really need a hand in getting past this point.... Andrew/Niz/anyone??

[philippefs35]

I'm also looking at the MSI Wind PC. Do you know if it has TV-out capabilities through the VGA port (with a simple VGA to s-video cable)?

Thanks,
Philippe

[colinjones]

Anybody at all?? I'm completely stuck!

[colinjones]

OK no idea what fixed it because I changed 3 things at once!

1) I noticed that the permissions on the r8168.ko file were -rwxrw-rw- instead of -rw-rw-rw ... very unlikely, but changed it anyway
2) Version 8.009 was the current one on the Realtek website but the instructions were for 8.008 so I found an older version, recompiled and used that
3) Not sure exactly how depmod works, but noticed that the instructions are for you to run it on the core, which isn't really relevant when the NIC is on the MD. But there is no equivalent step for the MD instructions. So I inserted a depmod after the chroot.

The PXE boot still takes 60 seconds to get an IP, when initially it was getting one instantly - seemed related to when I insert the 8168 module for the default initramfs but I can't see why that would effect it..

And whereas after getting the 8168 driver working initially, the boot sequence just indicates that the 8168 eth0 is up. On several tries since, and now that the full MD is working, the eth0 goes up/down/up about 5 or 6 times before finally settling on up. Each about 2-3 seconds apart and repeatable across reboots. Guess I have to live with these issues.

And yes, the Intel 945 chipset is still causing crashes with PSS so I had to disable that device.