CTPCI and Realtek 8139D

[wongck]

Great stuff. So this will get updated to v1.19 ?

Not sure what you mean but if Ektus tests the new kernel and will be willing to try a few things then yes, the fix would get into 1.19.

Well now that the Guardians of the FreeMint Github knows, I would think that the regression will be fixed.

[mikro]

Well now that the Guardians of the FreeMint Github knows, I would think that the regression will be fixed.

It may be shocking news for you but not all developers have the CTPCI to test. And when I say not all, I mean zero.

[wongck]

Well CTPCI is rather rare and not a lot of ppl who has it gets it working.

[Kroll]

This is true of CTPCI and network card users are very little, I am not a programmer but since there is one build quite old because from 2012. Is it a big problem to implement again, I honestly have a sentiment for this device.

[wongck]

http://www.atari-forum.com/viewtopic.ph ... ek#p299622
Boot output of my working MiNT setup:
MiNT-Net TCP-IP 1.6 PL 1 Nov 3 2012

The Mint 1.17 that I got from the sparemint is date 1/1/2011.
I know you mentioned daily builds, so I think your 1.17 must have been updated.

[Rustynutt]

This is true of CTPCI and network card users are very little, I am not a programmer but since there is one build quite old because from 2012. Is it a big problem to implement again, I honestly have a sentiment for this device.

Think no matter the hardware, we all have sentiment for it.
May be getting a CTPCI, then join in on the head banging

[Latz]

Hi,

today i tried CTPCI network card RTL8139 with current FreeMint (1-19-cur, 23.9.2017).

- ATI Radeon 9250 and RealTek 8139 cards installed.
- CT63/CTPCI flashed with latest ABE_V7F, SDR_V7D, CTPCI_1M; CT60TOS and network driver
from unofficial TOSbeta10 package (see Ektus´ post above).
- With TOS and STinG, network runs perfect (HighWire, Litchi FTP, FalcAmp webradio, ...).

Now with MinT (MinTNet+gluestik), network card is detected correctly at boot:

Code: Select all

RTL8139: RealTek RTL8139CP Fast Ethernet at 0x60040000, 00:08:54:39:B9:85
RTL8139: TX buffers at 0x8D80000, RX buffers at 0x8D81800, DMA offset 0x0
RTL8139: Setting 100mbps full-duplex based on auto-negotiated partner ability 45E1.
RTL8139: ioaddr 0x60040000 handle 0x2 full duplex.

"lspci" shows:

Code: Select all

>lspci 00:02.0 Ethernet controller: Realtek Semiconductor Co.; Ltd. RTL-8139/8139C/8139C+ (rev 10)

MinT network setting manually (no DHCP), "ifconfig" and "route" (a bit shortened) show:

Code: Select all

>ifconfig
rtk0: flags=0x443<UP,BROADCAST,RUNNING>
      inet 192.168.0.4 netmask 255.255.255.0 broadcast 192.168.0.255 metric 0 mtu 1500
      (...)

>route
Destination  Gateway      Flags   Ref   Use  Metric   Iface
default      192.168.0.1  UGD     1     0         0   rtk0
192.168.0.4  *            UH      1     0         0   lo0
(...)

So far, so good. But no webclient work, for example:

Code: Select all

>ping -c 10 192.168.0.1
ping 192.168.0.1:56 data bytes
RTL8139: Setting 100mbps full-duplex based on auto-negotiated partner ability 45E1.

----192.168.0.1 PING Statistics----
10 packets transmitted, 0 packets received, 100.0% packets lost

Litchi hangs when RESOLVING: Litchi errormessage "Cannot find server" and output
"RTL8139: Setting 100mbps full-duplex based on auto-negotiated partner ability 45E1."
on TOSWIN2 console.

Same with HighWire: No matter which address or IP, HighWire shows "No route to host"
or "Connection timeout"; in TOSWIN2 console same message (multiple):
"RTL8139: Setting 100mbps full-duplex based on auto-negotiated partner ability 45E1."

All these clients work perfect when i use a NetUSBee, so my configuration should be ok.

AFAIK FreeMinT 1-17 used a file "socket.dev" for network purposes; since 1-18-0 this
file is not used anymore. So as the rtl8139.xif works with 1-17 and NOT with 1-18 and
upwards, this maybe a startpoint to look at this issue.

It would be really great if someone (mikro?) could fix this and make all CTPCI users
VERY happy
Please tell me if you need additional informations!

Latz

[Kroll]

Exactly,
thank you very much for describing this problem.
I thought to describe it, because there are not many network card users on CTPCI

I'm very supportive of this idea, I'm a CTPCI user, and lately I've been able to run a USB PCI card too, it would be great if I could use the latest freemint on my network adapter also and netusbee I could use on my other Atari computer.

Kroll

[mikro]

Where rtl8139.xif comes from? If it's not from freemint or there is no source code available, that would be a problem. If it is, please report another issue here as usual so it wont get forgotten: https://github.com/freemint/freemint/issues

[Kroll]

It is included in the tosbeta10 archive, available from my website. http://www.ektus.de/tosbeta10.zip
That's the TOS I have to use, together with the latest ABE, CTPCI and SDR versions. ABE7F, CTPCI_1M and SDR7D.

Regards
Ektus.

Ektus send it earlier, I thing, that everything it is here

[mikro]

What a mess. It's labeled as 1.0 beta and it seems to be 1.02, what would make sense as it had been released one year after 1.01. Strangely, 1.01 doesn't contain such source code at all.

[mikro]

Hmm, looked into a it briefly... there's so many things wrong with that driver. :-( If only Didier asked... it uses a lot of user-space calls via trap calls (like Mxalloc(), PCI functions, even some mintlib calls), no wonder it doesn't work properly. I can't say why it works for 1.17, perhaps pure luck.

If I find some time, I'll include it in the freemint tree, it's not that complex (one has to make PCI functions accessible also to XDD/XFS/XIF modules, not just kernel ones) and should fix your issue as well.

[Latz]

Mikro, thank you very much for looking at this!! I feel confident that this long lasting
problem can be solved with your engagement and knowledge!
Please tell me if i can help with testing.

Latz

[mikro]

Although I own a CTPCI, my possibilities are very limited at this time:

• it's somewhere in a closet
• the closet is 15 000 km away
• even if it weren't I don't have a network card like this

Anyway, that didn't stop me to build the driver for you, most likely it will crash but you can always hope. ;-)

[Latz]

Hi,
ouf, you are fast!

Although I own a CTPCI, my possibilities are very limited at this time:

• it's somewhere in a closet
• the closet is 15 000 km away
• even if it weren't I don't have a network card like this

These are definetly not the best conditions

Anyway, that didn't stop me to build the driver for you, most likely it will crash but you can always hope.

Hmm, it doesn´t crash...it behaves the same way as the "original" from beta10 package. >ping shows 100% packets lost.
But this would have been too easy anyway

Thank you very much!

Latz

[mikro]

Strangest thing. So you are guys 100% sure it doesn't work on 1.18, right? Because my strongest suspect (except a bug in driver) was adding PCI BIOS wrapper to the kernel. But that happened in 2014, a year after 1.18 release...

Too bad between 1.17 and 1.18 there are three years and 1058 commits. ;-) However, 'git bisect' says there's roughly 9 steps (builds) to test so if you have time to test them (ideally while we're both online), drop me a PM. I will send you a build, you will tell me whether it's good or bad, according to that answer I will generate another one until the successful end. :-)

[Kroll]

Strangest thing. So you are guys 100% sure it doesn't work on 1.18, right? Because my strongest suspect (except a bug in driver) was adding PCI BIOS wrapper to the kernel. But that happened in 2014, a year after 1.18 release...

Too bad between 1.17 and 1.18 there are three years and 1058 commits. However, 'git bisect' says there's roughly 9 steps (builds) to test so if you have time to test them (ideally while we're both online), drop me a PM. I will send you a build, you will tell me whether it's good or bad, according to that answer I will generate another one until the successful end.

Hi,

I have just test on my system MiNT 1.18.0 and your driver is working on my configuration if I set ifconfig and route manually, DHCP is not working.
On system MiNT 1-18-1 is working too
On MiNT 1-19-cur biuild from 26.09 is still the same, not working at all.

[mikro]

Can you Latz confirm this?

So if I understand you correctly, situation is as follows:

- latest master + original driver: not working
- latest master + my driver: not working
- 1.18.0 + original driver: not working
- 1.18.0 + my driver: DHCP not working, manual working
- 1.17.0 + original driver: DHCP working, manual working
- 1.17.0 + my driver: ?

EDIT: note there is not a 1.18.1 version, please be precise in your reports.

[Kroll]

Can you Latz confirm this?

So if I understand you correctly, situation is as follows:

- latest master + original driver: not working
- latest master + my driver: not working
- 1.18.0 + original driver: not working
- 1.18.0 + my driver: DHCP not working, manual working
- 1.17.0 + original driver: DHCP working, manual working
- 1.17.0 + my driver: ?

1.17.0 - your driver working
DHCP not working at all on original and your driver
1.18.0, 1-19-cur - exactly as you wrote

EDIT: note there is not a 1.18.1 version, please be precise in your reports.

I have this version on my disk (I thing not realeased only beta version, during the start
I have on the screen 1-18-1-BETA
from 8 Fabuary 2016
OK I think we can forgetten about it

DHCP not working at all on all system on my disk

[mikro]

OK, that changes everything then! That means 1.18 kernel is perfectly fine (as long as the original functionality goes...) and therefore it could have been broken with the PCI BIOS addition.

I have attached two (more or less complete) builds -- just before adding PCI BIOS and a few commits after it (as there had been some fixes to it). I hope I haven't forgotten any important file. Feel free to test your USB trouble with it as well. :)

If/when we fix the manual config issue, I suspect fixing DHCP wont be that hard.

[Kroll]

I have checked both versions and I have good news, the version pre_pcibios works correctly on both the original and your driver versions, DHCP not working.
Second version post_pcibios not woring at all
I run loader.prg but there is no file usb060.km in usb directory

[mikro]

Apologies for the missing file, please find it attached to this post. I actually hope this will work too because it will be much bigger pain to debug the cause of wrong PCI BIOS implementation than some random commit which caused it.

[Latz]

Hi,

Can you Latz confirm this?

- latest master + original driver: not working Correct
- latest master + my driver: not working Correct
- 1.18.0 + original driver: not working Correct (1.18.0 from Oct 2 2012 here)
- 1.18.0 + my driver: DHCP not working, manual working Correct (tested only manual)
- 1.17.0 + original driver: DHCP working, manual working ->Ektus say that it works, i don´t have 1.17 anymore
- 1.17.0 + my driver: ? -> Perhaps Ektus can test?

For testing pcibios files i have to re-arrange my equipment a bit, so i´m not so fast.

Regards,
Latz

[Latz]

Ok, i can confirm Krolls report:
- With pre_pcibios, both drivers (original and yours) work correct..
- With post_pcibios both driver don´t work (same behaviour as reported before)

Latz

[Kroll]

Apologies for the missing file, please find it attached to this post. I actually hope this will work too because it will be much bigger pain to debug the cause of wrong PCI BIOS implementation than some random commit which caused it.

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

Photo-0079.jpg