Fun with Monkeys and Windows

[sechs]

I have a bit of an usual problem, and I'm not getting any headway with it.

I'm looking to move from Windows x86 to x64, but the only issue that I haven't been able to solve or work around is this: my media player sometimes hangs when playing my music.

So, the program that I'm using is MediaMonkey and I'm playing the music off of a CIFS share on my NAS. MediaMonkey has been known to be a bit dodgy with network media, but works perfectly on the same machine in Windows x86.

What happens is that after some period of time playing music, MediaMonkey will stop, giving the moving bars which generally signify seeking/buffering. However, it never starts up again. If I attempt to stop play, the application hangs and, in the process, totally borks all connections to the NAS. This, in turn, borks the Windows Explorer, as I have mapped drives to the NAS. I end up having to reboot to recover. No problems if I play a local file.

I haven't found any obvious difference in the way that Windows x64 works that would cause this kind of problem. I tried running the publicly available debug build of MediaMonkey and found no smoking gun. At this point, I'm not even remotely sure what the point of failure (application, operating system, or storage device) is.

Any guidance on how to troubleshoot, work around, or solve this problem is appreciated!

 

[MaxBurn]

Just looking for what is different: Using the windows default driver for the NIC? Might try using a manufacturer driver or two.

 

[sechs]

It's an nForce3-based board, and I'm using the onboard NIC, so there is no default driver. I'm using the latest (only?) final x64 driver for this chipset. I've tried forcing the NF4 ethernet driver, but it seems to make the system unstable.

Through a suggestion elsewhere, I downloaded and installed OmniPeek Personal, which basically lets me look at information about the packets that are being passed. I seem to get a series of low throughput and busy network/server that leads to a "frustrated user." So it seems like it's some kind of samba thing.

The good news, I guess, is that this is not a problem with MediaMonkey. I was able to reproduce the connection hang-up just by copying a whole lot of files from the NAS. It just seems that MediaMonkey handles the situation badly, as the Windows Explorer will eventually recover from the error, although it won't finish the copy.

I'll have to boot back into Windows x86 to determine if the same series of events happens there, but just doesn't lead to the connection borkage.

 

[sechs]

An update...

So, I booted back into 32-bit XP and ran the same tests. First, I has to disable checksum offload, because it was leading to a load of CRC errors. After that, I started getting the same load of low throughput and busy network/server errors, but it never leads to a Apdex "frustrated user." And of course, there's never any type of hang-up.

Obviously, x64 does something different that leads to the "frustrated user" and hang-up. I've seen a number of posts about the web concerning authentication errors with x64, due to changes in the RPC server; but I don't see that having any relationship to this issue.

Any thoughts?

 

[ddrueding]

Do you happen to have any Intel or 3Com NICs lying around? This sounds like a driver issue, and nVidia (bless them) are not known for their driver prowess, particularly on the NIC/MoBo side of things.

 

[MaxBurn]

To cut the problem in half do you have another PC to test with? To see if it is in the file server or your workstation. Sounds like the workstation though, I don't like the sound of disabling offloading to solve the CRC errors thing. Using gigabit? How is your cabling?

Damn ddrueding, you posted while I was thinking and typing. I like that we are thinking the same thing though.

 

[sechs]

After spending the afternoon swapping cables, installing and uninstalling updates, and running tests on other computers, it appears that the majority of the problem lies somewhere between the RJ-45 connector and the keyboard on the computer.

I ran some tests on the shiny new R60 over the wireless, and, while it it did show some of the same errors in OmniPeek, it certainly didn't spew them like when using my computer. For grins and giggles, I ran a file copy from my computer to the laptop and got a crap-o-rama. Awesome.

So, I do have an old Linksys PCI NIC that I keep around, but there are only two slots open on the computer. One is the on the 133MHz PCI-X bus with my SAS HBA, and the other is the plain-jane slot right next to the AGP slot (and possibly covered by the heatsink fan). It's low profile, so, if I can fit it in that PCI slot, I'll take it for a spin.

The crappy nVidia software is the only thing that I dislike about this motherboard (and it's exactly why I won't buy one of their video cards). I'll probably also be hunting the net for other drivers to see if there's anything better.

 

[time]

NVidia's 32-bit Windows drivers for the nForce 3 network adaptor work just fine for me (is there any difference from the nForce 2 chip?). The fact that you're getting this problem in two quite separate versions of Windows makes me wonder if your hardware is ever so slightly flaky ...

It's only 10/100. Just bung in a NIC and hopefully, your problem's solved.

 

[sechs]

Funny story...

So, I opened my case to realise why I had stuck all of my expansion cards in the bottom three slots: I had replaced the stock cooler on my video card with something that was large but, in return, very quiet. So, the standard PCI slot is completely blocked. Fine, I'll stick the NIC in the open PCI-X slot just to see if it makes a difference.

After futzing around for about twenty minutes trying to get it in past the graphics cooler, I finally get the machine booted up and the card recognised. Problem: there are no Windows x64 drivers for this card! Thanks Cisco.

I've always had problems of some sort with the nForce ethernet. It's the built-in firewall feature that seems to have done in an otherwise great product. Lots of folks complain that they're flakey -- because they are. Since I don't really put a challenge on the interface, I've been able to work with it.

So, I'm back to the driver game. I found a "remix" driver that theoretically should work. It installs, but I haven't put them to a real test yet.

 

[sechs]

I don't like the sound of disabling offloading to solve the CRC errors thing.

FYI, I usually have this off, because the hardware acceleration features of the nForce ethernet tend to make it hang.

And the CRC errors apparently come because the packet sniffer can't properly sniff when the hardware keeps butting in to do stuff.

 

[time]

It's the built-in firewall feature that seems to have done in an otherwise great product.

At the risk of sounding combative, why the hell would you install that feature?

Look, in my experience, any problems are more likely down to your motherboard manufacturer. But then, I haven't even attempted to run WinXP64 on an nForce3/2 network adaptor. Gigabyte always favoured Realtek NICs until nForce 4 came along. :roll:

That doesn't alter the fact that I have nForce 1, nForce 2 and nForce 3 adaptors on my LAN and they work just fine - on 32-bit Windows. :-?

 

[sechs]

You can't uninstall the chipset. I don't install the firewall software for it, as it only makes things worse, but I can't change the silicon.

Under x86, I've determined what the settings and software need to be, and it seemed to be fine. This situation with x64 seems to either be something particular with x64 that has nothing to do with my hardware, or it's nVidia's drivers.

I've got visitors coming this weekend and next weekend, and I need to get that laptop ready, so this will probably have to sit on the backburner for a while -- but I'll get back to it.

 

[Mercutio]

The nForce boards I have seen have an option buried someplace in the BIOS to turn off the hardware firewall. I haven't seen an nForce board yet that had it on by default.

Of course, all I've used are Gigabyte and a small number of MSI or Biostar boards, so maybe there is different stuff out there.

 

[sechs]

There is an option which should technically turn off the the firewall and switch it to 100base-T (which is fine for my purposes); but, after changing that, I can't get a driver to install. It should use the pre-NRM driver, since the network bus enumerator goes away, but it doesn't work with either.

In other news, my visitor for this weekend is sick and couldn't fly out, so free time has appeared. I installed the aforementioned remix ethernet driver, and it appears to work acceptably. I had previously attempted to force a 60.x version driver that caused instability, but this 65.x-based one seems fine.

I did get one connection hang, but that appears to be because the packet sniffer hung and borked the network connection. I ran almost 24 hours of continuous streaming from the NAS (without OmniPeek running) with no noticeable issues. I'll try for a clean install with the new driver and, since Merc mentioned it, maybe futz with that BIOS setting and see if I can get it to work.

 

[sechs]

The saga continues....

So, I did a clean install of Windows x64 with the new driver. After about six hours of testing, I was able to trigger a hang; but I was basically doing stuff that I'd rarely, if ever, do in real life (make a long, multigigabyte copy while updating the database in MediaMonkey and playing music off the NAS). I installed OmniPeek and tried to reproduce the problem, but, of course, got nothing. I'll need to do furthur testing if I'm going to use this driver.

I also turned off the ethernet bridge in the BIOS, basically turning off the hardware firewall. Turns out that Windows x64 comes with the pre-NRM driver and automatically installed with no hiccups. Of course, within five minutes, I had a network hang. I rebooted and turned off all hardware acceleration. After a few hours, I didn't get any errors.

Unfortunately, it seems that the only pre-NRM driver for x64 is the one released with Windows. nVidia didn't even have one with the one and only set of nForce2 drivers for x64 that they released.

In other news, the latest "remix" driver set that I found for 32-bit contains a supposedly leaked pre-NRM driver which actually installs and works, with no futzing around with settings. We'll see how that goes.

Any furthur thoughts from anyone?

 

[ddrueding]

I'm afraid I have no input. I've gone pretty much 100% Vista now, including client machines. (Except for one "Feisty" user )

 

[Mercutio]

Good gods why?

 

[ddrueding]

I'll be kind and start another thread...

 

[sechs]

Good gods why?

Well, he's got to try to speed up that RAID 0 of Raptors somehow. Why not saddle it with a bad operating system?

PS: Three BSODs from the pre-NRM driver in x86. Back to bridge mode....

 

[MaxBurn]

I may have missed it but did you try out that PCI NIC?

Nvidia's answer to me not being able to use my USB based KVM on any nforce chipsets was to use a USB PCI card. I get the feeling they really don't care about the minor things that don't work right for their chipsets.

 

[ddrueding]

PS: Three BSODs from the pre-NRM driver in x86. Back to bridge mode....

It certainly sounds like I'm the one with an unstable system, doesn't it

 

[sechs]

I may have missed it but did you try out that PCI NIC?

As above, no x64 drivers. It wouldn't be a long term solution, anyway. The problem seems to squarely lie with the crappy-butt nVidia drivers.

 

[sechs]

It certainly sounds like I'm the one with an unstable system, doesn't it

More than three BSODs in one morning? I guess it just reflects on your abilities as a technician.

At least I can't inflict Vista on my computer because the operating system won't work on it... or maybe the computer is rejecting it....

 

[Sol]

Hmm the name of the thread kinda threw me and I havn't looked at it before but this sounds exactly like a problem I had with my last Nforce3 board (First too, no prizes for guessing why).

Everything goes along find until you try to do any sort of semi-heavy network job (For me it was copying stuff I don't think streaming would do it but it was gigabit so maybe that made a difference) once the shit hit the fan there was the choice of waiting arround for some insane timeout or just rebooting...

I used a PCI card and just disabled the onboard NIC and the problem cleared right up and my transfer speeds improved a heap... If it's just 10/100 would you be losing that much speed with just a USB NIC? Shouldn't be too hard to find one with a 64bit driver... Or if you can squeeze a PCI card in surely $20 for something with a realtek chipset would sole the problem... It sucks having to use a seperate card when there is one onboard but it's probably better than the pain...

 

[sechs]

The problem is that the one slot available is on the PCI-X bus with my SAS HBA. Even if I shelled out for a 64-bit NIC, it would bring the bus down to 100MHz. That isn't so horribly bad, but I'm not sure it'd be worth the investment.

 

[sechs]

So, does anyone know how nVidia assigns version numbers to its drivers? Do they pull them out of a hat?

Over the holiday weekend, I downloaded a bunch a driver sets off of the nVidia website and just started testing the ethernet drivers. I have learned, foremost, there is no apparent association between version number, date, and package version.

Right now, I have the 55.2.1.0 driver, which is apparently meant for nForce 5xx chipsets, installed. It appears to be stable, doesn't suffer from the hangs, and seems to have fewer errors in OmniPeek. The only problem I see is that throughput seems to be lower than with other drivers that I've tried. I'll try flipping the optimization option from "CPU" to "Throughput" and see if that solves that.

 

[sechs]

After furthur testing, I only found one other driver set that neither crashes nor has the hang, but it's throughput is far worse. So, it seems that drivers with versions lower than 50 are prone to crashing, higher than 55 to hanging, and the rest have throughput issues. nVidia is so craptacular.

Nonetheless, performance is acceptable enough, so I'll go with it. I found some issues with nVidia's network diagnostic program, but will open a new thread on that topic...