Anyone using a Belkin PCI USB card?
I've just bought a Belkin PCI USB card to use in my Windows 2000 SP4 PC. It's Belkin's product F5U220, which gives you four external USB2. 0 ports and one internal USB2. 0 port. Does anyone know if the supplied USB2.
I've just bought a Belkin PCI USB card to use in my Windows 2000 SP4 PC. It's Belkin's product F5U220, which gives you four external USB2.0 ports and one internal USB2.0 port. Does anyone know if the supplied USB2.0 drivers have to be installed, as I've already got installed a set of standard Microsoft USB2.0 drivers, which currently work fine with the PC's six embedded ports?
The user guide that came with the card gives specific installation instructions for the CD-supplied drivers, with different methods for Win98, ME, 2K and XP. However, from the wording in the guide, it appears that it was written before the time when standard Microsoft USB2.0 drivers were supplied in WinXPSP1 and Win2KSP4. Thus, I'm wondering if adding the Belkin drivers would actually mess things up.
Has anyone here used this card with Windows 2000 and therefore can they say what needs to be done?
From what I've googled so far, those WinXP users who've added the Belkin drivers have ended up with corrupted drivers.
When you add a PCI device like this, would you definitely expect additional drivers to have to be installed? In other words, should extra controller and hub entries be effectively loaded into the USB entries in Device Manager?
My system BIOS settings aren't helping either, as the motherboard handbook gives no guidance whatever on the configuring of the USB 2.0. The motherboard manufacturer has long since stopped providing support, as well. Other than USB2.0 [enabled] [disabled], all that the BIOS gives is:
USB0 Access Interface [EDB bus][PCI bus]
USB1 Access Interface [EDB bus][PCI bus]
USB2 Access Interface [EDB bus][PCI bus]
USB2.0 Access Interface [EDB bus][PCI bus]
The bracketed entries represent the choice between the USB bus that's embedded on the motherboard, which the current six use, and any USB porting done via the PCI bus. Currently, all are set to EDB. I'm assuming that USB0,1 and 2 refer to the motherboard's six embedded ports but I've been unable to find anything that ties up with that. USB0,1 and 2 could equally refer to PCI slot positions, for example. What d'ya reckon? And what's that other entry there all about? Could it be that I'll need to leave USB0,1 and 2 on EDB bus and just set USB2.0 Access Interface to PCI bus?
The user guide that came with the card gives specific installation instructions for the CD-supplied drivers, with different methods for Win98, ME, 2K and XP. However, from the wording in the guide, it appears that it was written before the time when standard Microsoft USB2.0 drivers were supplied in WinXPSP1 and Win2KSP4. Thus, I'm wondering if adding the Belkin drivers would actually mess things up.
Has anyone here used this card with Windows 2000 and therefore can they say what needs to be done?
From what I've googled so far, those WinXP users who've added the Belkin drivers have ended up with corrupted drivers.
When you add a PCI device like this, would you definitely expect additional drivers to have to be installed? In other words, should extra controller and hub entries be effectively loaded into the USB entries in Device Manager?
My system BIOS settings aren't helping either, as the motherboard handbook gives no guidance whatever on the configuring of the USB 2.0. The motherboard manufacturer has long since stopped providing support, as well. Other than USB2.0 [enabled] [disabled], all that the BIOS gives is:
USB0 Access Interface [EDB bus][PCI bus]
USB1 Access Interface [EDB bus][PCI bus]
USB2 Access Interface [EDB bus][PCI bus]
USB2.0 Access Interface [EDB bus][PCI bus]
The bracketed entries represent the choice between the USB bus that's embedded on the motherboard, which the current six use, and any USB porting done via the PCI bus. Currently, all are set to EDB. I'm assuming that USB0,1 and 2 refer to the motherboard's six embedded ports but I've been unable to find anything that ties up with that. USB0,1 and 2 could equally refer to PCI slot positions, for example. What d'ya reckon? And what's that other entry there all about? Could it be that I'll need to leave USB0,1 and 2 on EDB bus and just set USB2.0 Access Interface to PCI bus?
Participate on our website and join the conversation
This topic is archived. New comments cannot be posted and votes cannot be cast.
Responses to this topic
The EDB stands for Extended Data Bus and generally speaking the drivers supplied with the interface card should normally be used, however, you may want to try the standard SP4 drivers and see how well they work.
It's very possible you could see no performance/campatibility difference between the two sets of drivers.
Another thing you should do is to check Belkin's website for updated drivers for this model card, they most likely have newer ones then what was supplied on the drivers CD.
It's very possible you could see no performance/campatibility difference between the two sets of drivers.
Another thing you should do is to check Belkin's website for updated drivers for this model card, they most likely have newer ones then what was supplied on the drivers CD.
So what exactly does Extended Data Bus mean, then?
Yeh, I'll fit the card shortly and see what happens when I boot up. I'm anticipating, however, that it'll invite me to install drivers - and that's my dilemma.
Re updated drivers, yes, I've already done a lengthy search around Belkin's website and finally found what appears to be the latest USB drivers for the card. Having downloaded it, it turns out to be a file called U2v241.exe, which implies that the drivers are v2.41. They're dated 26th Aug 2005. However, when I've run the Belkin CD in Windows Explorer, I've been unable to find a software version no., so I can't tell whether I'd need to run U2v241.exe or not. For all we know, anyway, U2v241 might just simply be bringing the Belkin drivers into line with Microsoft's.
Yeh, I'll fit the card shortly and see what happens when I boot up. I'm anticipating, however, that it'll invite me to install drivers - and that's my dilemma.
Re updated drivers, yes, I've already done a lengthy search around Belkin's website and finally found what appears to be the latest USB drivers for the card. Having downloaded it, it turns out to be a file called U2v241.exe, which implies that the drivers are v2.41. They're dated 26th Aug 2005. However, when I've run the Belkin CD in Windows Explorer, I've been unable to find a software version no., so I can't tell whether I'd need to run U2v241.exe or not. For all we know, anyway, U2v241 might just simply be bringing the Belkin drivers into line with Microsoft's.
Right, I've fitted the card. I used a spare PCI slot next to my soundcard, furthest away from the PSU.
All seems to have gone well. When I booted up, various controllers and hubs were automatically detected, but there was no "Found New Hardware" message (thank goodness).
When I now look in Device Manager, besides the original Microsoft USB entries that I had, there's now in addition:
NEC PCI to USB Open Host Controller
NEC PCI to USB Open Host Controller
Standard Enhanced PCI to USB Host Controller
USB2.0 Root hub
USB Root hub
USB Root hub
I've checked the Properties of these and they're now using exactly the same Microsoft driver files as the PC's embedded USB ports. So, it does look as though you don't need to install the Belkin drivers that come on the CD. I've tried out all the four Belkin ports that are on the PCI backstrip, using a USB flash memory stick, and they all appear to be working.
Curiously, all four ports work despite me having made no changes in the System BIOS. All USB2.0 ports on my PC are still configured to EDB Bus. I was definitely expecting to have to configure to PCI Bus (in the same way that, for instance, my soundcard is allocated to PCI Bus; it won't work if allocated to EDB Bus and indeed would then clashes with the onboard soundchip).
The above additional entries are what the Belkin user's guide states will be installed for Windows 2000, except that the above are the Microsoft drivers rather than the Belkin/NEC drivers, even though a couple of them are called "NEC PCI to USB ....". Also, the Belkin user's guide omits to mention an additional "USB2.0 Root hub".
Conceivably, the Belkin versions of these drivers - those on the CD and those contained in the update file U2v241.exe available from Belkin's website - are more refined and more compatible with the NEC chip on the card. But, who knows? Maybe I'll discover some differences in due course. I'll report back here soon.
In the meantime, the watchword is that, if you're definitely using Microsoft USB2.0 drivers that are updated from SP4, you DON'T need to install the Belkin drivers on the CD. I hope this helps anyone else who's about to use this Belkin PCI card on a Windows 2000 machine.
Addendum: Hmm, well, I thought I'd check out the position now as regards IRQs and I now see that one of the Standard Enhanced Controllers is sharing an IRQ with my graphics card. Also, one of the NEC Open Host Controllers is sharing an IRQ with my soundcard. Eh, is that desirable? Perhaps I should try moving the Belkin card to a different PCI slot? What d'ya think?
All seems to have gone well. When I booted up, various controllers and hubs were automatically detected, but there was no "Found New Hardware" message (thank goodness).
When I now look in Device Manager, besides the original Microsoft USB entries that I had, there's now in addition:
NEC PCI to USB Open Host Controller
NEC PCI to USB Open Host Controller
Standard Enhanced PCI to USB Host Controller
USB2.0 Root hub
USB Root hub
USB Root hub
I've checked the Properties of these and they're now using exactly the same Microsoft driver files as the PC's embedded USB ports. So, it does look as though you don't need to install the Belkin drivers that come on the CD. I've tried out all the four Belkin ports that are on the PCI backstrip, using a USB flash memory stick, and they all appear to be working.
Curiously, all four ports work despite me having made no changes in the System BIOS. All USB2.0 ports on my PC are still configured to EDB Bus. I was definitely expecting to have to configure to PCI Bus (in the same way that, for instance, my soundcard is allocated to PCI Bus; it won't work if allocated to EDB Bus and indeed would then clashes with the onboard soundchip).
The above additional entries are what the Belkin user's guide states will be installed for Windows 2000, except that the above are the Microsoft drivers rather than the Belkin/NEC drivers, even though a couple of them are called "NEC PCI to USB ....". Also, the Belkin user's guide omits to mention an additional "USB2.0 Root hub".
Conceivably, the Belkin versions of these drivers - those on the CD and those contained in the update file U2v241.exe available from Belkin's website - are more refined and more compatible with the NEC chip on the card. But, who knows? Maybe I'll discover some differences in due course. I'll report back here soon.
In the meantime, the watchword is that, if you're definitely using Microsoft USB2.0 drivers that are updated from SP4, you DON'T need to install the Belkin drivers on the CD. I hope this helps anyone else who's about to use this Belkin PCI card on a Windows 2000 machine.
Addendum: Hmm, well, I thought I'd check out the position now as regards IRQs and I now see that one of the Standard Enhanced Controllers is sharing an IRQ with my graphics card. Also, one of the NEC Open Host Controllers is sharing an IRQ with my soundcard. Eh, is that desirable? Perhaps I should try moving the Belkin card to a different PCI slot? What d'ya think?
I do believe things will be ok for the most part, however, it's knowing which port/usb root hub is sharing IRQ's with other devices, unless these are labeled you will have to test things out with an external USB device and say playing some games to generate a lot of graphics work to see if this sharing is going to cause any issues.
Yeh, I've been trying that sort of thing in the meantime. So far, I've not encountered any clashes or any visible or audible degradations. For instance, I tried a USB flash memory stick in each of the four new Belkin USB ports whilst I was playing an audio CD with the soundcard. All seemed fine. I've not tried quite the same with the graphics card but I have run some DVD films on the PC and there's been no problem, as far as I can see. Still, it might be different if and when I actually have something plugged into the appropriate USB port at the same time as running the video.
I do still have a couple of spare PCI posittions, so I could certainly move the Belkin card to a different slot. However, I've a suspicion that it won't make any net difference, as I recall a similar exercise with another PCI card a few years ago had the same result.
What I can't understand is why, in effect, two USB hubs - the one embedded in the PC and one on the Belkin card - should need to use so many resources and therefore so many IRQs. This, for instance, is the current resultant allocation:
AGP slot: Graphics card IRQ16
Standard Enhanced Host Controller IRQ16
PCI slot 0: Spare
PCI slot 1: Spare
PCI slot 2: Belkin USB2.0 card
PCI slot 3: Sound card IRQ19
NEC Open Host Controller IRQ19
PCI slot 4: Passive USB strip (PCI slot not actually used)
PCI slot 5: Network card IRQ17
NEC Open Host Controller IRQ18
Standard Open Host Controller IRQ20
Standard Open Host Controller IRQ21
Standard Open Host Controller IRQ22
Standard Enhanced Host Controller IRQ23
Oh, and I'm assuming that "Enhanced" means USB2.0, whereas "Standard Open" means USB1.1, and that it's not permissible to disable any of their entries in Device Manager.
COM Ports 1 and 2 are currently unused and disabled but their IRQs (3 and 4) aren't released for alternative usage, for some strange reason. Same with the Midi Port (IRQ10). Similarly, IRQ5 and IRQ11 remain reserved. So that's everything taken up - all 24 IRQs.
On my machine (ACPI-compliant), all resources, and therefore IRQs, are handled by the BIOS. That said, my system BIOS does allow for manual allocation of about 10 of the IRQs to the PCI Bus. However, I've read that even if I were to stop the BIOS from having automatic control of IRQs and try manual, it wouldn't work.
So, I don't know quite what to do at present. It looks as though, under Win2K (and assuming an ACPI system), the user has very little control indeed of the IRQs. On the other hand, it appears that sharing of IRQs does not necessarily result in resource clashes and therefore any problems.
Does anyone know more about this subject area and can give some advice?
I do still have a couple of spare PCI posittions, so I could certainly move the Belkin card to a different slot. However, I've a suspicion that it won't make any net difference, as I recall a similar exercise with another PCI card a few years ago had the same result.
What I can't understand is why, in effect, two USB hubs - the one embedded in the PC and one on the Belkin card - should need to use so many resources and therefore so many IRQs. This, for instance, is the current resultant allocation:
AGP slot: Graphics card IRQ16
Standard Enhanced Host Controller IRQ16
PCI slot 0: Spare
PCI slot 1: Spare
PCI slot 2: Belkin USB2.0 card
PCI slot 3: Sound card IRQ19
NEC Open Host Controller IRQ19
PCI slot 4: Passive USB strip (PCI slot not actually used)
PCI slot 5: Network card IRQ17
NEC Open Host Controller IRQ18
Standard Open Host Controller IRQ20
Standard Open Host Controller IRQ21
Standard Open Host Controller IRQ22
Standard Enhanced Host Controller IRQ23
Oh, and I'm assuming that "Enhanced" means USB2.0, whereas "Standard Open" means USB1.1, and that it's not permissible to disable any of their entries in Device Manager.
COM Ports 1 and 2 are currently unused and disabled but their IRQs (3 and 4) aren't released for alternative usage, for some strange reason. Same with the Midi Port (IRQ10). Similarly, IRQ5 and IRQ11 remain reserved. So that's everything taken up - all 24 IRQs.
On my machine (ACPI-compliant), all resources, and therefore IRQs, are handled by the BIOS. That said, my system BIOS does allow for manual allocation of about 10 of the IRQs to the PCI Bus. However, I've read that even if I were to stop the BIOS from having automatic control of IRQs and try manual, it wouldn't work.
So, I don't know quite what to do at present. It looks as though, under Win2K (and assuming an ACPI system), the user has very little control indeed of the IRQs. On the other hand, it appears that sharing of IRQs does not necessarily result in resource clashes and therefore any problems.
Does anyone know more about this subject area and can give some advice?
My suggestion would be to disable both onboard serial/com ports as most likely you are not using either one.
I would also disable the onboard lpt/printer port if you printer is the USB type.
This will free up some system resources as well, like IRQ's for instance.
As to why the Root Hubs require their own IRQ's, simple, most every expansion card requires an IRQ for proper synchronization to the system bus, be it PCI/AGP/PCIe.
Since pretty much most of the devices support bus mastering, this will allow the devices to share IRQ's with other bus mastering cards. However, I've found some bus mastering devices like Soundblaster cards to be less the friendly when sharing their resources with other devices
I would also disable the onboard lpt/printer port if you printer is the USB type.
This will free up some system resources as well, like IRQ's for instance.
As to why the Root Hubs require their own IRQ's, simple, most every expansion card requires an IRQ for proper synchronization to the system bus, be it PCI/AGP/PCIe.
Since pretty much most of the devices support bus mastering, this will allow the devices to share IRQ's with other bus mastering cards. However, I've found some bus mastering devices like Soundblaster cards to be less the friendly when sharing their resources with other devices
Both COM ports are ALREADY disabled but, as I've pointed out, that doesn't release their IRQs. And the LPT printer is USED, actually; it's a laser monochrome printer; it uses IRQ7.
These are the IRQs that are unassigned at present, or are, in theory, available:
IRQ3
IRQ4
IRQ5
IRQ10
IRQ11
but it seems that the BIOS has a will of its own, in that it won't allow any of these to replace the two shared interrupts that I now find, interrupts IRQ16 and IRQ19.
I agree with you about Soundblaster soundcards, in that they've a reputation for being difficult IRQ-sharers. But, so far, I've not encountered a system freeze or other problem with my particular Soundblaster card, even though it's now sharing IRQ19. I suspect that a lot depends on the types of devices sharing any one IRQ and the likelihood of them being in use at exactly the same time and using maximal resources.
These are the IRQs that are unassigned at present, or are, in theory, available:
IRQ3
IRQ4
IRQ5
IRQ10
IRQ11
but it seems that the BIOS has a will of its own, in that it won't allow any of these to replace the two shared interrupts that I now find, interrupts IRQ16 and IRQ19.
I agree with you about Soundblaster soundcards, in that they've a reputation for being difficult IRQ-sharers. But, so far, I've not encountered a system freeze or other problem with my particular Soundblaster card, even though it's now sharing IRQ19. I suspect that a lot depends on the types of devices sharing any one IRQ and the likelihood of them being in use at exactly the same time and using maximal resources.
If you review the MB manual, you will see that each PCI slot is assigned a specific IRQ depending on what that slot number happens to be.
Of course this means that it will share IRQ resources with whichever onboard device happens to use the same IRQ as well.
It does look like everything is working just fine for you and you have done all the testing that one can do to verify the devices are sharing the IRQ's properly
I would conclude you should not have any issues from this point forward using everything as you want to...
Of course this means that it will share IRQ resources with whichever onboard device happens to use the same IRQ as well.
It does look like everything is working just fine for you and you have done all the testing that one can do to verify the devices are sharing the IRQ's properly
I would conclude you should not have any issues from this point forward using everything as you want to...
I wish I could be as confident as you, jmmijo. I suppose that all I can do is just see how things run over the course of time. I'm keeping my fingers crossed that there'll be no IRQ clashes.
My particular motherboard manual does NOT, in fact, give any information about IRQs assigned to the PCI slots. If it did, it'd help an awful lot. I think the reason is that, when you're running an ACPI-compliant Win2K PC and the BIOS is in control of the IRQs, there are no set IRQs for a particular PCI slot. I confirmed this to be the case some years ago, when I experimented with switching one or two PCI cards from slot to slot. I think that what happens is that the BIOS assesses the situation whenever a new PCI card is introduced and then reassigns IRQs, and the resources that go with them, according to each card's requirements.
What's been surprising has been the large number of IRQs that USB2.0 requires - on the setup as now devised, some seven IRQs, in all. And because my PC's already run out of IRQs, two devices have each had to share an IRQ with a USB controller.
My particular motherboard manual does NOT, in fact, give any information about IRQs assigned to the PCI slots. If it did, it'd help an awful lot. I think the reason is that, when you're running an ACPI-compliant Win2K PC and the BIOS is in control of the IRQs, there are no set IRQs for a particular PCI slot. I confirmed this to be the case some years ago, when I experimented with switching one or two PCI cards from slot to slot. I think that what happens is that the BIOS assesses the situation whenever a new PCI card is introduced and then reassigns IRQs, and the resources that go with them, according to each card's requirements.
What's been surprising has been the large number of IRQs that USB2.0 requires - on the setup as now devised, some seven IRQs, in all. And because my PC's already run out of IRQs, two devices have each had to share an IRQ with a USB controller.
