Update ethernet device names & more #1467
Conversation
|
With the new ethernet names, the boot screen looks like this: |
|
Hello @Mellvik, You've got quite the boot screen there, it looks fantastic! I would say it seems you are using ELKS to the fullest, very impressive! And thank you for your work on this PR. I notice that wd.c has been modified quite a bit, are you able to test that? A question on cp.c using In (On another small note, for all the "int opt_xxx = 0" in cp.c, removing the "= 0" will remove them from the disk-based data segment and make the code file smaller, and ELKS guarantees the initial values will be 0). Thank you! |
|
Thank you, @ghaerr - and yes, I've had some real fun with this one!
I notice that wd.c has been modified quite a bit, are you able to test that?
Also, in wd.c, fmemcpy is too generic a symbol to remain global, especially since it uses an internal variable. Can you make that a static function?
Yes, I've been beating it up heavily over the past days one machine running the 8003, the other running the 8013. Much more so than intended, I had 2 nodes on the segment responding to the same ip. Big arp fun - and lots of testing. Btw, testing continues but I know of no problems at this time.
And yes, the fmemcpy is already static.
A question on cp.c using cp -f: it seems you only do the create if unlink is successful. Shouldn't that be changed so that you always do the unlink, ignore its result, and always execute the create?
I was pondering this one for some time, eventually going for this solution. If the target cannot be unlinked, create will fail and I'd like to know which one actually failed.
In wfd < 9 below that, what is the purpose of comparing with 9? Its a file descriptor and should only be compared with < 0, it seems to me. (Perhaps cp -f has not been fully tested?)
You got me there. This is a typo, thank you very much. revealing that more testing would have been appropriate. OTOH, I've been beating up sys with the new cp a lot, it fixes a major headache. I'll fix the typo.
(On another small note, for all the "int opt_xxx = 0" in cp.c, removing the "= 0" will remove them from the disk-based data segment and make the code file smaller, and ELKS guarantees the initial values will be 0).
Thanks, now that you mention it I know you've pointed that out before. Memory error. Will fix.
-M
… |
I'm not sure that's guaranteed to be the case. But in any case, your version of |
|
Demo - interface switching in real time Starting with Commands: |
|
This looks OK now, thanks for the requested changes. I hadn't seen the extra BTW, the ifdef APPLE allows for this code to be compiled and run on macOS (or Linux) for testing using |
|
BTW, the ifdef APPLE allows for this code to be compiled and run on macOS (or Linux) for testing using cc cp.c. I've found that useful for better test cases and it was used in development of the recursive option, as well as for more portable code.
OOps - that didn't occur to me - I guess it should have.
Revert coming.
Thank you.
…-M
|
|
Thanks for the revert and timing information. Interesting showing the timing information in real time, as well as seeing is believing with the speed differences between the cards! |
|
Thank you @ghaerr, As to speeds, yes - it's interesting to see the real numbers. Talking about which, here are some actual file transfer numbers, this is incoming FTP to ELKS (destination ... the latter running with 16k buffer and reporting (ca.) 8 occurrences of NIC BAD checksum (buffer screwup which requires NIC reset and packet discards). Very decent for all 3. And PIO beats shared memory but just barely. Outbound numbers are about 1/3 of this, primarily because of the smaller packet size.
I've also found cases (outbound file transfers) in which the -M |
|
Hello @Mellvik,
I haven't looked at any code for this yet, but thinking that perhaps ktcp isn't checking the sequence number before processing the FIN. There a number of "optimizations" ktcp takes that might contribute to problems like this. The "optimizations" aren't technically legal and may have be a result of trying to keep ktcp quite small. This might help you as you're looking at tcpdump logs! Other possibilities include changing the count-down timers back to more normal levels. Thank you! |
|
Thank you @ghaerr,
yes, I think your analysis is spot on. It turns out this is a quite elusive one: I've had only 3 occasions and not been able to make it repeatable. So evidently a combination of circumstances are required to trigger it.
And - as things happen, while trying to find that combination and (randomly) choosing the ne1k interface for the testing, I ran into some interesting errors during outgoing ftp (the type of errors triggered by the forced 16k buffer usage). I couldn't restrain myself and headed into the ne2k-driver only to discover how much I've already forgotten about the details, such as the (configuration) flags, the error messages and the tricks to make it work.
Not wanting to make that discovery again 6 months from now and having to start over yet again, I sat down to write man pages for the ethernet drivers - which is time consuming for the very reason I started: The details need to be rediscovered.
So before anything else, the man pages (proposals) are coming …
…-M
8. des. 2022 kl. 16:36 skrev Gregory Haerr ***@***.***>:
Hello @Mellvik <https://github.com/Mellvik>,
If the first packet ktcp sees after startup is a FIN from an earlier (improperly terminated) session, it locks up.
I haven't looked at any code for this yet, but thinking that perhaps ktcp isn't checking the sequence number before processing the FIN. There a number of "optimizations" ktcp takes that might contribute to problems like this. The "optimizations" aren't technically legal and may have be a result of trying to keep ktcp quite small. This might help you as you're looking at tcpdump logs! Other possibilities include changing the count-down timers back to more normal levels.
Thank you!
—
Reply to this email directly, view it on GitHub <#1467 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA3WGOGWTB75UOQA4S3PJGTWMH6BHANCNFSM6AAAAAASRARJTQ>.
You are receiving this because you were mentioned.
|
This PR changes all Ethernet device names per discussion in #1445 - which entails minor mods to many system files and the setup.8 man page.
Also included is an updated
fsckman page, an enhancement tocpwhich adds a -f (force) option, making thesysscript more useful when used to update an existing installation. Thesysscript has been updated accordingly, as has thecpman page.The
wddriver has been made fully compatible with the SMC/WD 8013 NIC, including the auto-detection of 8003 vs 8013 types. More testing of the switching between interfaces on a running system is required and ongoing.Updates to the wiki and other documentation pages will follow when this PR has been merged.
-M