-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ne2k: freeze on ktcp start #1647
Comments
Hello @rvalles, Thanks for the bug report. I don't have a PC with a working NIC at the moment, so I can't actually test this. There had been significant testing towards the end of last year, when the NE2K was last worked on. The fact that the detected MAC address is wrong seems to be a big flag, since this is read early in the NE2K driver startup and hasn't changed in some time. What is the correct MAC address? I'm wondering if any portions of the shown MAC coincide, giving me something to go on as to why it's incorrect. Perhaps there is an issue with 8- or 16-bit bus address with your NIC and the driver. My guess is that your NE2K NIC and the driver aren't working together at all, and when Thank you! |
That's exactly what I was looking for, thank you! So what could be happening is that the driver is using word reads instead of byte reads to get the data, and
It appears there may be an issue with reading from your NIC using 16-bit vs 8-bit moves, depending on the chip. What is your exact NE2k card and do you have a chip number? We might need that. We could compare with the packet driver source as well, but that's probably a lot of work. The function goes on to read the MAC address:
Which then goes into an ASM routine that reads the NIC differently based on whether it thinks the card is 8- or 16-bit. Did you try forcing the driver to run in both these modes? I'm not that familiar with the exact |
Built master with a few changes:
Boots like this:
It freezes all the same. Tried 0xA0 too (leaving buffer size to the default). No dice. But notice how the MAC is now correct. |
This is the card, a D-Link DE-200TP+. non-plus variant is documented here: https://stason.org/TULARC/pc/network-cards/D/D-LINK-Ethernet-DE-200TP-for-PC-AT.html According to this, IRQ is 11. I/O is supposed to be 0x300 according to freedos, which would match this other similar card's I/O bank: https://stason.org/TULARC/pc/network-cards/D/D-LINK-Ethernet-DE-205-TP.html Boot rom (xtide universal bios) is at C8000H and enabled. |
I added a This is as according to: https://wiki.osdev.org/Ne2000 A reset must be done before reading the prom. Unfortunately, the build process takes hours, and build.sh did a clean, so it'll be a while till I can see whether that helped. |
Hello @rvalles, Thanks for your information, I'll take a look deeper at it.
Geez, is running There is a much better way, once the toolchain has been built: you can just use Rebuild ELKS (not toolchain) - takes 2-3 minutes:
Rebuild just the kernel (can be used by you for NE2K mods) - takes 30-40 seconds:
Thank you for trying to debug the problem with your NE2K card! |
The script seems clever enough to skip the toolchain build. But the rest takes a very long time, for reasons unknown. I will of course not be using the script again if I need to rebuild thereon. |
Build finished just now. Over 2h. |
It sounds like its rebuilding the toolchain. If not, and you can somehow capture the log and post it, I can see what is going on. In the meantime, just use |
And I messed that up. Doing a time make kclean &>somelog now. It's extremely slow and I have no idea why. Zen+, 16GB RAM, otherwise builds far larger software much faster. |
On my system (MacBook Pro 16G RAM):
|
As far as I can tell, it's these dokcleans. Each takes a very long time, with low cpu usage.
|
I do notice that that recursive dokclean does run "slow" on my system - about 1/10 second each? What version of make are you running? I'm not sure yet whether its the directory searching or make reinvocation that's taking time. |
Are you saying that running Good news is that you don't actually have to run |
Host is an up to date Arch Linux. When gcc runs, that's of course very fast. But it takes tens of minutes to get there, possibly over an hour for a whole clean (I imagine kclean will be faster). Good to know re: kclean only needed for header changes. |
It is also possible that your shell wildcard expansion is taking forever...:
If I'm not mistaken, the above will run a shell for the |
It finished. It only took this much because kclean vs clean.
Now, to the actual building. |
gcc does its job real fast. Each file compiles in an instant, but there's huge gap between files. It's spending a very long time on else. Make is all I get to see on top's output, whereas gcc seldom is there. |
It sounds like there is something wrong with your |
Try putting copying this to /tmp/rec.sh and then running
This uses the shell to glob and test directories. If this runs quickly, then I would say |
This is slower than it should be, but not that slow. Going to get some sleep. I'll tell you how long the actual build took once I get up. |
As an added note before I sleep, dash takes 0.4s instead of 1.4s (done a few reruns for both, for consistency). Dash really makes a difference, but it's still way slower than I'd like. I might switch the sh link to dash (it's bash by default) at some point, after the build ends. |
Get some sleep! When you wake up, consider:
1.4s to just wildcard expand a few directories and echo them? I would say very very slow, although even on my system this takes 0.5 seconds!
Definite improvement - is /bin/sh actually
I think setting SHELL=/bin/dash may direct |
|
Calling reset made it freeze, not sure if in the reset itself or when trying to get the prom contents. Out of ideas, for now. |
Hello @rvalles, Do you happen to have another NE2K-style network card around? I'm pretty sure the networking works well, but thought that direction might be easier given how long it takes to compile the system with your possible shell/make issue. Thank you! |
I believe I have another 486 (DX/33 I think?) in my old stuff pile. It definitely has a NIC, although I do not know which. I can try the release there, and should it work, check what happens if I swap cards. I will get to it once I get the chance. Might be later today or tomorrow. re: slow build, I could prepare a docker build environment, and see what happens there. If it is slow, anyone will be able to reproduce it with the Dockerfile. |
... that 486 has no cards installed. But a 386 had this NIC: Some info about this one can be found here: http://en.techinfodepot.shoutwiki.com/wiki/D-Link_DE-220P_rev_D2 Now cleaning the contacts with an eraser and alcohol. This one seems pnp, and got no jumpers. I recall there was a dos tool to set it up (set IRQs and such). I will try and see if I can make it work on DOS first. I will not install the boot rom for now, but instead will boot dos via my optromloader floppy (w/xtide universal bios). |
It seems to work with this NIC. This is using the downloaded ELKS 0.7.0 1440K image, only edited config files to set up IRQ and ip addresses.
Of course, the other NIC works with freedos, so we still need to figure out why it doesn't with ELKS. |
Thanks for the testing, and glad to have a working ELKS comparative test case NE2K NIC. I will need to read up on the differences between the cards based on the links you supplied. Do you happen to know whether the cards differ by chip type or ISA card addressing (word/byte) etc? |
Both are 16bit ISA as stated, but the problem one gets detected as 8-bit by the early check in ne2k_drv_init(), which causes the mac address to be misinterpreted. They have different chips as pictured, I'd assume both re-labeled from different manufacturers. The next thing I'll do when I have some time to work on this will be to make a dockerfile for the build environment, using Arch Linux. If it's slow, I can then easily check whether it is also slow on another machine, and also make one with Debian to see if that is slow. On ELKS itself, I'm interested in dumping the eeprom of the good card too, then perhaps try to manually parse it referencing ELKS and somebody else's ne2000 code. |
Looking into it again. Discovered there's a Dockerfile already. Note said Dockerfile needs to be modified to install the |
Do you really need Docker to build? What about the option of building using I wonder what Arch Linux did that's causing /bin/bash to run so very slowly... |
Docker image builds fast. real 3m35.158s (from a clean tree) I should try and make an arch-based equivalent Dockerfile to see if we can reproduce the slowness. But not right now, for this ticket. ATM writing a floppy. I want to try and dump the eeprom values on the working ne2000, for comparison purposes. |
SAPROM reads:
The other NIC (the problem one) did read:
|
There's a lot of repeating |
There's a crynwr ne2k driver that we know works with the card. I'll see if I can figure out how to compile it, when I have some time. It should not be too hard to make it print the SAPROM. |
I have been experimenting with several NE2000 cards running in 8 bit mode. I have a DE220P that I could not get working for any reason. Recently, I bought a Kingston KNET-20T off of ebay from 1996 that was advertised as being 100% ne2000 compatible. I installed it on my 80386 to set with IRQ=3 Address=300h. Tested it with MSDOS and mTCP. Installed it into ELKS .70, set my bootops to net=ne0, ne0=3,0x300,0x81 and it came up flawlessly the first time. I was able to FTP to my FTP Server and Telnet locally. I did assign localip, nameserver and gateway manually. From what I can see, not all NE2000 are created equally. Let me know if I can do some testing. My system is a Leading Edge Model D at 4.77mhz, 640K, 8 Bit CF Card adapter with XTIDE and ISA VGA Card. Thanks for making ELKS a reality. Geoff. |
Hello @gepoolejr, Thanks for the testing report on your NE2K NIC! I have to agree, it seems various NE2K are not compatible, but I am glad to hear that many are with ELKS.
Wow, a Leading Edge Model D. I had one of those and used it as my primary development system long ago. I really liked that machine. I seem to recall it ran quickly although I'm not sure how if they ran at 4.77mhz. |
Happy to do it. I also tried my newer WD8013 and couldn't get it working either. It seems that legacy hardware in the pre2000 era works best. I haven't tried to install an XTIDE chip on the card yet, but that is on my testing schedule. One of these days, I will start looking at the 8390 - I have several 3C503 cards (8 and 16) and they are pretty well documented.
It runs pretty good overall. It is my fav 8088 system also. I dropped in an NEC V20 which speeds it up a bit, but the 80186 instruction set makes it more useful. I originally used it to load Minix 1.5 because I really wanted to do things in smaller spaces. I also used it demo Minix 1.5 at VCFNW in 2019 before Coivd. Had it almost self booting the root disk but I couldn't quite get the bootsec file setup correctly from the Minix Usenet archives. Fortunately, ELKS has made a lot of headway. Plan to get a cross development system setup soon. |
Notice the one that works on my end is the DE220P (!), whereas a DE200 doesn't. See above for pictures of the cards, and the config I used with the DE220P. |
I'm sure it works on a 16 bit ISA slot. I'm testing on an 8 bit slot with ne0=3,0x300,,0x81. That configuration doesn't work - not sure why. The only card I've used so far as a NE2000 in 8 bit mode is the Kingston KNET-20T. |
Description
Networking works.
Partial freeze: Switching virtual consoles with keyboard works, typing into an existing shell ignores keyboard input.
Configuration
How to reproduce ?
Yes.
Boot the floppy, login, then net start.
Raw data
Enabled serial console, producing the log below.
Direct console, scan kbd 80x25 emulating ANSI (3 virtual consoles)
ttyS0 at 0x3f8, irq 4 is a 16450
ttyS1 at 0x2f8, irq 3 is a 16450
64 ext buffers, 65536 ram
eth: ne0 at 0x300, irq 11, (ne1k) MAC 00:35:80:35:c8:35 (16k buffer), flags 0xa2
eth: wd0 at 0x240, irq 2, ram 0xce00 not found
eth: 3c0 at 0x330, irq 11 not found
bioshd: hda BIOS CHS 1024,255,63
bioshd: hda IDE CHS 16383,16,63
/dev/hda: 16383 cylinders, 16 heads, 63 sectors = 8063.5 Mb
/dev/fd0: 80 cylinders, 2 heads, 18 sectors = 1440.0 kb
Partitions: hda:(0,16514064) hda1:(63,8401932)
device_setup: BIOS drive 0x0, root device 0x380
PC/AT class machine, syscaps 0xff, 638K base ram.
ELKS kernel 0.7.0 (59312 text, 12128 ftext, 8528 data, 42624 bss, 14382 heap)
Kernel text at 2d0:0000, ftext 114b:0000, data 1441:0000, top 9f80:0, 492K free
fd: /dev/fd0 ELKS bootable, has 80 cylinders, 2 heads, and 18 sectors
MINIX-fs: mounting unchecked file system 0x380, running fsck is recommended.
VFS: Mounted root 0x0380 (minix filesystem).
Running /etc/rc.sys script
Fri Aug 11 17:19:43 2023
ELKS 0.7.0
login: root
elks86# net show
ip 192.168.1.186 gateway 192.168.1.1 mask 255.255.255.0 ne0
elks86# net start
Starting networking on ne0
ktcp -b -p ne0 192.168.1.186 192.168.1.1 255.255.255.0
(frozen)
Additional information
The text was updated successfully, but these errors were encountered: