CTPCI and Realtek 8139D

[mikro]

I've just copy to this directory, but look at the photo, problem with kernel, It also confirms the correct network work on this compilation pre_pcibios :)

Did you run it with supplied mint060.prg? If I didn't miss anything, both archives should contain all needed components, even XaAES.

[mikro]

- With post_pcibios both driver don´t work (same behaviour as reported before)

Just to be sure: you did manage to get it running with all the components (mint060, usb060.km, ...) and you can observe that manual and dhcp don't work, correct?

[Kroll]

- With post_pcibios both driver don´t work (same behaviour as reported before)

Just to be sure: you did manage to get it running with all the components (mint060, usb060.km, ...) and you can observe that manual and dhcp don't work, correct?

Here you can find a photo for post_pcibios, for this compilation not working at all, and what I see on the screen if run loader from USB directory.
Mint060.prg for this compilation is in auto folder.

Photo-0081.jpg

[mikro]

Ufff... can't really read it. Is it possible to post just immediate output from usbloader, I can see there's some error when loading usb060.km.

[Kroll]

I've just copy to this directory, but look at the photo, problem with kernel, It also confirms the correct network work on this compilation pre_pcibios

Did you run it with supplied mint060.prg? If I didn't miss anything, both archives should contain all needed components, even XaAES.

I am sure that I copied everything to c:/mint/1-19-cur/ and mint060 to auto folder.
Here you can find a photo made for pre_pcibios compilation, DHCP not working, manually is OK, and what if run loader.prg.
If you need some additional information please let me know.

Photo-0082.jpg

[Kroll]

Ufff... can't really read it. Is it possible to post just immediate output from usbloader, I can see there's some error when loading usb060.km.

I made some screenshot for post_pcibios compilation once again, maybe now will be OK

SNAP002.JPG

[mikro]

OK, this is getting so confusing that I have confused even myself. :-)

We don't need usbloader for this, that's the most important point, I was totally confused with your other USB issue, let's focus on networking here.

So if I understood you correctly, if you run pre_pcibios package, manual network is fine. If you do the same for post_pcibios, you can't get networking working at all. OK, that's a strong indicator then.

[Kroll]

OK, this is getting so confusing that I have confused even myself.

We don't need usbloader for this, that's the most important point, I was totally confused with your other USB issue, let's focus on networking here.

OK, you are right, in this point, we talk only about network card.
USB themes in another thread, because I can run USB mass storage from Netusbee and USB from PCI card , and these are two separate issues

So if I understood you correctly, if you run pre_pcibios package, manual network is fine. If you do the same for post_pcibios, you can't get networking working at all. OK, that's a strong indicator then.

Exactly, for pre_pcibios package is OK
for post_pcibios package is not working

[Latz]

Hi Mikro,

So if I understood you correctly, if you run pre_pcibios package, manual network is fine. If you do the same for post_pcibios, you can't get networking working at all. OK, that's a strong indicator then.

Absolutely correct!
I suggest we should focus on manual networking first, it seems like DHCP introduce more (and different) problems.

Latz

[wongck]

So I downloaded the pre-pcibios and post-pcibios.
The post-pcibios did not boot up to the desktop, it hang after mounting the dosfs... or it reported please do dosfsck and hang.
( the pre-pcibios also reported the same but carries on booting to the desktop... IDK why).

So following is using the pre-pcibios version. I used your rtl8139 driver from this thread.
My 8139 is is RTL8139C which is has constant link on, my RTL8139D seem to drop link now and then.

After hitting PING return, I have to wait forever..... well may be 3-4 minutes (IDK but feels like forever) to get an output from ping.
Massive packet loss ~88% but still it is a step in the right direction. Previously was like 100% loss.

Code: Select all

root@F18:/root>ifconfig
lo0:    flags=0x44b<UP,BROADCAST,LOOPBACK,RUNNING>
        inet 127.0.0.1 netmask 255.255.255.0 broadcast 127.0.0.255
        metric 0 mtu 16384
        in-packets  1 in-errors  0 collisions 0
        out-packets 1 out-errors 0
rtk0:   flags=0x443<UP,BROADCAST,RUNNING>
        inet 192.168.3.8 netmask 255.255.255.0 broadcast 192.168.3.255
        metric 0 mtu 1500
        in-packets  0 in-errors  0 collisions 0
        out-packets 1 out-errors 0
root@F18:/root>ping 192.168.2.99

root@F18:/root>ping 192.168.3.1
PING 192.168.3.1 (192.168.3.1): 56 data bytes
64 bytes from 192.168.3.1: icmp_seq=0 ttl=64 time=0.001 ms
64 bytes from 192.168.3.1: icmp_seq=1 ttl=64 time=0.004 ms
64 bytes from 192.168.3.1: icmp_seq=2 ttl=64 time=0.004 ms
64 bytes from 192.168.3.1: icmp_seq=3 ttl=64 time=0.004 ms
64 bytes from 192.168.3.1: icmp_seq=4 ttl=64 time=0.004 ms
64 bytes from 192.168.3.1: icmp_seq=5 ttl=64 time=0.004 ms
64 bytes from 192.168.3.1: icmp_seq=6 ttl=64 time=0.004 ms
64 bytes from 192.168.3.1: icmp_seq=8 ttl=64 time=5.002 ms
64 bytes from 192.168.3.1: icmp_seq=9 ttl=64 time=0.005 ms
64 bytes from 192.168.3.1: icmp_seq=10 ttl=64 time=0.005 ms
64 bytes from 192.168.3.1: icmp_seq=11 ttl=64 time=0.005 ms
64 bytes from 192.168.3.1: icmp_seq=12 ttl=64 time=0.005 ms
64 bytes from 192.168.3.1: icmp_seq=13 ttl=64 time=0.004 ms
64 bytes from 192.168.3.1: icmp_seq=14 ttl=64 time=0.004 ms
64 bytes from 192.168.3.1: icmp_seq=15 ttl=64 time=0.004 ms
64 bytes from 192.168.3.1: icmp_seq=16 ttl=64 time=0.004 ms
64 bytes from 192.168.3.1: icmp_seq=17 ttl=64 time=0.004 ms

----192.168.3.1 PING Statistics----
137 packets transmitted, 17 packets received, 87.6% packet loss
round-trip min/avg/max/stddev = 0.001/0.298/5.002/1.212 ms
root@F18:/root>

[mikro]

wongck: what happens when using 1.18.0 kernel? It seems to work for Kroll very reliably (if not counting the DHCP issue).

[wongck]

Same for Ektus package (specific 1.17 version) and v1.18 (from bill gates 24 dec 2011 as seen from system info) did a retest.
Thanks. :

[wongck]

The v1.18 retest shows 87.3% failed.... seems to very similar numbers.
I will do the v1.17 retest after work.

[mikro]

I think your packet loss problem is something unrelated to the driver, more like a slightly incompatible hardware. I can imagine if the issue Ektus and Kroll are seeing gets fixed, you will still see lost packets.

[Ektus]

Testing now...
1) In my working 0.17 setup, replace rtl8139.xif with the one from earlier in this thread: Still working (ping and resolve, at least. no packet loss).
2) Pre-PCIBIOS, rtl8139xif from thread: Working (as above)
3) Post-PCIBIOS, rtl8139xif from thread: Boots to desktop, ifconfig reports interface up and running, ping yields

Code: Select all

RTL8139: Setting 100mbps full-duplex based on auto-negotiated partner ability C5E1.

But doesn't report any packages sent. Ifconfig reports one out-error for each ping attempt, all other counts remain zero.

[mikro]

Thanks, Ektus. I consider this issue more or less settled. Right now it's unclear whether the problem is the PCI wrapper or the fact the driver is using XBIOS calls (which are then caught in the wrapper) instead of calling the wrapper directly.

My next plan is to hack up a version which directly calls the wrapper, Alan wasn't very keen to have it but for a test it's enough (and not so complex).

[wongck]

I think your packet loss problem is something unrelated to the driver, more like a slightly incompatible hardware. I can imagine if the issue Ektus and Kroll are seeing gets fixed, you will still see lost packets.

Thanks for your opinion on the incompatible hardware, I wanted a second option and now I have it.
I did not bother much on this thread earlier as I given up on my setup as being incompatible.
The reason is that I cannot remember which version of SDR/ABE v7 I have on my system, it been several years since I done it.
It just shows as SDR/ABE v7+ on boot up.

[Kroll]

I think your packet loss problem is something unrelated to the driver, more like a slightly incompatible hardware. I can imagine if the issue Ektus and Kroll are seeing gets fixed, you will still see lost packets.

Thanks for your opinion on the incompatible hardware, I wanted a second option and now I have it.
I did not bother much on this thread earlier as I given up on my setup as being incompatible.
The reason is that I cannot remember which version of SDR/ABE v7 I have on my system, it been several years since I done it.
It just shows as SDR/ABE v7+ on boot up.

I suppose you are using the latest Boot 2.02, then when I run CTPCI, I have info CTPCI_1M (see photo)

Photo-0087.jpg

If I remember well, I had an older version of Boot 2.00 Beta 2 then I showed SDR / ABE v7+ or CTPCI 1E+

[wongck]

yes it is 2.02 beta 10.
I am missing the colourful background.... IDK why.

screen_s.gif

[wongck]

If I remember well, I had an older version of Boot 2.00 Beta 2 then I showed SDR / ABE v7+ or CTPCI 1E+

From what I know, the SDR/ABE v7+ will come on after you do a warm reboot (or two or more).

[wongck]

So after struggling to get the XiLinX IMPACT running..... I finally flashed again my ABE & SDR.
So with it, I managed to get my CTPCI & RTK 8139 on the network.
Ping losses drop to 0%, but still takes some time (but much shorter) before I get a reply from my gateway.

IMG_3127.png

Surfing still time out Synctime works some times
But amazingly, PH Weather seems to be able to get the weather almost every time. IDK why.

So I may have an earlier version of ABE/SDR v7

Thank you Mikro for the new binaries and your expert observation of hardware incompatibility.

[Ektus]

Did you flash the latest CTPCI firmware (Xilinx config file, whatever) also? Those files must match. Latest versions should be (all from 2012):
-ABE_V7F.JED
-SDR_V7D.JED
-CTPCI_1M.JED

See attached archive if you can't find them elsewhere.

Regards
Ektus.

[wongck]

Yes, that's the one I flashed on my CT63/CTPCI now. Thanks Ektus.

... I totally forget how to flash and have to read my own how-to on the Wiki.
And I found out that I have the following firmware from the screenshot of the wiki in 2012.
I have to re-build the text in Words by copying the mediawiki text and image individually


So from the screenshot, I would have flashed the correct firmware previously, may be there was some wrong flashing.
Anyway, a re-flash seems to work wonders.

[wongck]

FINALLY... all working.
The phweather and synctime issue points to name resolution, phweather uses a fast async name lookup.
I had several old and dead name server defined, mostly my old AP.
Fixed now... I can surf with my Falcon/Ct63/CTPCI

[Kroll]

Wow, super,
Finally, it was a problem with flash, not directly with the Realtek 8139 network card