In my previous post, I mentioned a couple of gotchas regarding my server upgrade and the Linux install thereon. A day later and things have changed again.
One thing I thought I had fixed: the network autonegotiate problem. I found network performance was once again sucking royally today, and I tried to re-create the circumstances that permitted good network performance the other day. Unfortunately, no luck: disabling autonegotiate on the Cisco RV016 hub and on the NIC didn’t seem to solve anything. One possibility is that I have to disable autonegotiate on both, then reboot both. However, I’m also observing hundreds of errors in the following form
sky2 eth0: rx error, status 0x2940002 length 660
The sky2 kernel driver apparently has known problems with the Marvell 88E8056 Network Interface card and similar Marvell products. One comment in the linked thread that leapt out at me:
The sky2 module is a pile of steaming dung.
Perhaps that is a bit harsh, but…there seems to be a problem here, and what I’m seeing could be related.
Update: I added a small Gigabit ethernet/wireless 802.11n router to my network, hanging it off my RV016 as an access point. I hooked my webserver to it, and suddenly the rx errors in the servers log files stopped. I then moved the other machines on my network with Gigabit-capable NICs to the little router (a DLink DIR-655), and all of the port packet errors associated with them on the RV016 seemed to vanish. That is… the number of packet errors on the port via which the DLink is attaching is significantly less than the aggregate total of the packet errors on the ports the PCs were originally attached to.
The implication… well, I’d speculate (and this is nothing but an educated guess) that the RV016 isn’t happy dealing with the Marvell 1000/100/10 Mbps NICs, but the DLink has no problem with the same NIC. Side benefit: I can now transfer files between my Gigabit ethernet machines at up to 20 MB/s (200 Mbps): at least on initial testing. Handy 🙂
One thing I thought wasn’t going to be fixed: the problem with vncserver/tightvnc and keyboard mapping. There was a response on the thread I linked to yesterday that provides a link to a package of updated files someone thoughtfully and kindly assembled. I installed them and voila: the keyboard mapping problem is gone, and I can remotely control my server. Many thanks to AndrewL733 for creating the fix, and site admin awilliamson for hosting the download!
“The sky2 module is a pile of steaming dung.”
Mmmmm, I’ve been out of the techie side of computers for years now, so I’m a little rusty…. is that a technical assesment 😉
I think it falls under the Technology Ratings Standard (TRS) Request for Comment (RFC) #19237-12. According to that standard, technology can be rated on a simple 29 position scale, beginning at the virtually unachievable “Godlike in its perfection” at position 1, sliding in a predictable fashion to the low end with “total clusterfuck” being position 29. “Pile of Steaming Dung” is the in rating position 26, just above 27 (“sucks the soul from my quivering body”), and below 25 (“pathetic garbage”).
I find that standards make things so much more understandable… 😉