RESOLVED: Finally! rtl8139 nic pxe/gpxe/grub boot after alpha 2.15

[pigdog]

Hi all,

Prior to alpha 2.15 I was pxe booting a MD with a Realtek 8139 (10ec:8139) in a PCI slot because the Nvidia Boot ROM (forcedeth) was toast.

After my rebuild that system would not pxe boot, I receive a big trace list, 60 second timeout, can't open /tmp/eth0-conf plus a kernel panic message.

The eth0 link says it's up before the trace list and again before the kernel panic.

There is a comment about rtl8139/8139C/8139C+ (rev.10) and chipset incompatible. (Modified - corrected a typo 8138C+ to 8139C+.)

I've tried 8139C & D chipsets.

I've tried pxe, gpxe and grub boot disks and flavours of R8139 and RTL8139 builds.

All with the same results.

Just before 2.15 I was running the .14 generic.  So, I upgraded to the .14 generic from .11 but still have the same thing happening.

This was rock solid prior to 2.15.

Before I spend any more time on this I was wondering if anyone else has experienced the same thing?

I've read a bunch of stuff about Realtek chipsets in other forums but this thing was good to go up to 8.10 alpha 2.15.

Thanks all.

[colinjones]

hmm... perhaps this is a regression due to the Realtek 8168/8169 bug. Are you aware of this? There is a wiki article on resolving it. By first removing the 8168 ID from the 8169 driver, then recompiling a new version of the 8168 driver. Perhaps something has even removed the 8169 ID from the 8169 driver?! If you are not using the 8168 chipset in any way, then perhaps you should try downloading a new copy of the 8169 driver and replacing the old version in the diskless folder for your MD image?

[Zaerc]

hmm... perhaps this is a regression due to the Realtek 8168/8169 bug. Are you aware of this? There is a wiki article on resolving it. By first removing the 8168 ID from the 8169 driver, then recompiling a new version of the 8168 driver. Perhaps something has even removed the 8169 ID from the 8169 driver?! If you are not using the 8168 chipset in any way, then perhaps you should try downloading a new copy of the 8169 driver and replacing the old version in the diskless folder for your MD image?

Just to point out the obvious: 8139 != 8168/8169, the 8139 is a pretty old (and widespread) 10/100 mbit chipset and has been supported by the Linux kernel since like forever and a half.

[colinjones]

oops! misread it! Disregard my comments, thanks Zaerc!

[rafik24]

 Hi Pigdog,

 Check that the dhcp daemon is bound to your core interface using: netstat -anop | grep dhcp

I had the same issue many times were my md would not pxe boot because the dhcp server got reconfigured by lmce
and the dhcp range arg was missing in /etc/dhcp/dhcpd.conf

 Have a look

Regards,

Rafik

[pigdog]

Hey rafik24,

Thanks for the heads up.

I try it tomorrow.  Soccer season started Monday night, one kid one night at 6, the other the next - Mon - Thurs.

Then Sat. morning/afternoon leagues.

They're getting exercise and I'm getting West Nile from the mosquitos!

Thanks.

[pigdog]

Hi rafik24,

This is my output...

dcerouter_112566:/etc/default# netstat -anop | grep dhcp
udp        0      0 0.0.0.0:67              0.0.0.0:*                           5305/dhcpd3      off (0.00/0/0)
raw        0      0 0.0.0.0:1               0.0.0.0:*               7           5305/dhcpd3      off (0.00/0/0)
unix  2      [ ]         DGRAM                    16517    5305/dhcpd3

I've got ranges...

                 allow unknown-clients;
                 range 192.168.80.129 192.168.80.130;
                 range 192.168.80.132 192.168.80.254;

and webadmin shows my pluto device range of 80:2 thru 80:128

If I try to use another model of Realtek chip when I build my pxe boot disk it won't load.

The 8139 pxe .zdsk I created matches the lspci report (10ec-8139)

When I try to pxe boot off the dhcp server it runs the 8139cp.ko file from the server and tells me the 8139c chipset is not compatible.

He then runs the 8139too.ko as secondary driver with no success.

I've checked the .7, .11 and .14 generics but both .ko are the same file size.

I've also tried 1 8139C and 2 8139D NIC's.

Cheers

[pigdog]

Hi,

I thought I'd see what would happened if I forced 8139too to boot first instead of 8139cp.

I went into mkinitramfs as per Unrecognized NIC but still no joy.

Tried 8139cp and 8139too

[pigdog]

HI,

O.K.  So I installed Ubuntu onto a usb memory stick and booted the MD.

I did a lshw and it told me my Realtek was using the 8139too driver version 0.9.28 and I had an IP address of 192.168.80.13.

I browsed the net a bit, looked at the latest BBC news headlines (some monk wrote a book about sex for couples - wtf?).

So my card works.  I'm going on the core and blacklist the 8139cp.ko.

Thanks.

p.s. forget that.  I tried adding it to the blacklist, still ran 8139cp.  Tried creating a local-8139cp blacklist, still ran 8139cp.

I hate to give up, but, I just might have to get another NIC!

[pigdog]

O.K.

When I upgraded to 810 alpha 2.20 my boot up acted a little differently.

8139cp loaded but I didn't get the comment about rtl8139/8139C/8139C+ (rev.10) and chipset incompatiblity.

8139cp was v1.3 Mar 22, 2004.

8139too did not try to load.

Everything else was the same.  Eth0, traceback, 60 second timeout, can't open /tmp/eth0-conf plus a kernel panic message.

So, I re-built from scratch, again, tried to boot the MD again, same result as above.

Now, I will try to force the 8139too to run and see what happens.

Cheers.

[pigdog]

Hi,

I tried to blacklist 8139cp but it didn't stop it from booting.

Since the system reported during boot that the system had 8139cp was v1.3 Mar 22, 2004 I thought I'd try booting with different issues of etherboot.

eb-5.4.4-rtl8139.zdsk
eb-5.4.3-rtl8139.zdsk
eb-5.2.6-rtl8139.zdsk

5.4.4 & 5.4.3 failed to boot while 5.2.6 reported that /tftpboot/prelinux.0 ...error:not a valid image.

I'll scratch my head for a while longer.

[pigdog]

Well,

Since it was booting without the compatibility message I thought I'd try GRUB PXE booting again (wiki).

I made a disk, selected new media director and had the same thing happen.

[Zaerc]

Just a wild stab in the dark, but maybe your /tftpboot/pxelinux.0 is not a valid image.

[pigdog]

Hi Zaerc,

The only time I received /tftpboot/prelinux.0 ...error:not a valid image was doing the old 5.2.6 etherboot.

I've been trying to force the 8139too .ko to run but DHCP keeps running the 8139cp .ko

I've tried blacklisting the 8139cp and I even removed it.

rm /lib/modules/2.6.27-14-generic/kernel/drivers/net/8139cp.ko

Then I ...

depmod -a

... rebuilt the initrd so that the module won't be included anymore ...

mkinitramfs -o /boot/initrd.img-2.6.27-14-generic 2.6.27-14-generic

... rebooted the core and the MD still ran the 8139cp

Unless I did something wrong.  When I check /lib/modules/2.6.27-14-generic/kernel/drivers/net I have no 8139cp.ko listed!

Is it somewhere else because it's a dhcp client or MD?

Thanks.

[pigdog]

Hi,

Since the 8139too was the only guy in /lib/modules/2.6.27-14-generic/kernel/drivers/net/8139too

and I coudn't seem to get anything other than the 8139cp to boot I tried this...

nano /etc/initramfs-tools-interactor/modules

added 8139too

then...

/usr/pluto/bin/Diskless_BuildDefaultImage.sh

and...

mkinitramfs -d /etc/initramfs-tools-interactor/ -o /tftpboot/default/initrd

I ended up with    .No IP address    on boot of the MD.

Removed everthing, rebooted - now something is broken - still get .No IP address om MD.

hmm.

So I did

/usr/pluto/bin/Diskless_BuildDefaultImage.sh

and then

mkinitramfs -o /boot/initrd.img-2.6.27-14-generic 2.6.27-14-generic

Hoping this would run the 8139too.  Nope - .No IP address.

So I copied 8139cp.ko back into /lib/modules/2.6.27-14-generic/kernel/drivers/net

did

/usr/pluto/bin/Diskless_BuildDefaultImage.sh

and then

mkinitramfs -o /boot/initrd.img-2.6.27-14-generic 2.6.27-14-generic

and still .No IP address.   Somethings broke.  Time to reload from scratch - again.