Jump to content

98 SE SP 3.32


Gape

Recommended Posts

Renaming the VIA driver to USBHUB2V.SYS or something, should solve the problem (theoretically). The only downside would be wasting some memory, having to load duplicate driver files instead of a unique one. But where there's no unique solution, there must be a compromise.

Better ideas, anyone...?

I must apologyze for not being active lately - got some hardware issues to deal with in real life and therefore haven't been able to work on software (NE editor, SP installer and other projects I planned to deal with).

Link to comment
Share on other sites


Renaming the VIA driver to USBHUB2V.SYS or something, should solve the problem (theoretically). The only downside would be wasting some memory, having to load duplicate driver files instead of a unique one. But where there's no unique solution, there must be a compromise.

Better ideas, anyone...?

I must apologyze for not being active lately - got some hardware issues to deal with in real life and therefore haven't been able to work on software (NE editor, SP installer and other projects I planned to deal with).

I'm all out of ideas with this VIA issue. If I had a machine with VIA we probably wouldn't have an issue. Since I can't test, I can't give any further input.
Link to comment
Share on other sites

Totally understandable. I've had reports of some of my toys misbehaving or not working at all and couldn't reproduce and fix because I didn't have any x64 machine and/or OS to test on.

Anyway, to keep it theoretical, your idea of pulling VIA-related commands from the inf and making a separate, VIA-only installation inf, combined with renaming the driver file as mentioned above, should allow for any combination of USB chipsets on a given machine. Unfortunately I can't test either, because the only working machine I have with VIA chipset is my main 98SE machine which works 24/7 and can't afford to botch the 6-year old installation.

I hate to add to this issue, but recently, while trying to fix a video issue in my test machine by installing different video/AGP drivers on a SiS630 chipset, I got system lockups (Windows protection error blah-blah). After fiddling around, I discovered the AGP driver package installs its own openhci.sys USB driver overwriting the one in SP, which leads to these lockups. As soon as I replaced the SiS openhci.sys with the one provided by the SP, the machine started up and worked correctly.

There still is the video issue that I cannot put the finger on, but on that I'll get back after some more testing. Right now I'm back at the NE Editor but it's coming out very slowly.

Edited by Drugwash
Link to comment
Share on other sites

Renaming the VIA driver files may result in them not being able to properly interact with one another. I can't say that for certain, but I have a feeling it isn't a good idea.

I started to suggest having them install to a different folder than the MS files, say SYSTEM32\DRIVERS\VIAUSB2 instead of just \DRIVERS, but that may break their ability to interact with other files in the \DRIVERS directory. I believe WDMCHECK will report missing functions from files that are not in the same folder as the file being checked...

I would think that moving the VIA data to a separate INF file would be sufficient. I don't know of any situations where two different branded USB2 controllers would exist in the same system, but maybe I'm wrong... :unsure:

Link to comment
Share on other sites

I have a VIA VT6202 USB 2.0 PCI adapter on my main 98ESE machine. If I weren't using it daily, I could very well pull it and plug it into another machine's PCI slot, where would coexist with its native USB controller, or - if I had any money - I could buy another PCI to USB adapter from another maker and plug it along the on-board USB 1.1 controller and the VIA 2.0 adapter.

Incidentally, both the 1.1 and the PCI 2.0 USB controllers are manufactured by VIA, but it could've well been otherwise. And I've posted details about my not-so-good installation somewhere earlier in this topic, if I recall correctly.

I don't think the filename matters, as long as there are no others in the package to depend on it. Since the system registers the driver with the name it's being presented in the inf, whatever filename would do, as long as it doesn't clash with an already existing file in the same location. But of course, that is to be proven practically.

Link to comment
Share on other sites

I have a VIA VT6202 USB 2.0 PCI adapter on my main 98ESE machine. If I weren't using it daily, I could very well pull it and plug it into another machine's PCI slot, where would coexist with its native USB controller, or - if I had any money - I could buy another PCI to USB adapter from another maker and plug it along the on-board USB 1.1 controller and the VIA 2.0 adapter.

Incidentally, both the 1.1 and the PCI 2.0 USB controllers are manufactured by VIA, but it could've well been otherwise. And I've posted details about my not-so-good installation somewhere earlier in this topic, if I recall correctly.

I don't think the filename matters, as long as there are no others in the package to depend on it. Since the system registers the driver with the name it's being presented in the inf, whatever filename would do, as long as it doesn't clash with an already existing file in the same location. But of course, that is to be proven practically.

Good point about add-in cards. I wasn't thinking. :wacko:

Driver files interdependent on one another may not be able to interact with each other if renamed. Often they have internal references to one another. Theoretically one might be able to Hex them all and change the names internally and externally, but that would also have to be proven in practice.

Another angle:

(dencorso please comment on this, you seem to be the most informed member about this)

Do we know 100% for sure that ALL versions of the MS USBHUB20.SYS cause errors/do not work with VIA controllers? Or is it just the version used by NUSB? Earlier versions of the MS USBHUB20.SYS driver exist (I tracked them down trying (unsuccessfully) to find the oldest possible versions of a USB2 stack to load on Win95). I can provide a link if someone can test.

Link to comment
Share on other sites

Another angle:

(dencorso please comment on this, you seem to be the most informed member about this)

Do we know 100% for sure that ALL versions of the MS USBHUB20.SYS cause errors/do not work with VIA controllers? Or is it just the version used by NUSB? Earlier versions of the MS USBHUB20.SYS driver exist (I tracked them down trying (unsuccessfully) to find the oldest possible versions of a USB2 stack to load on Win95). I can provide a link if someone can test.

AFAIK, the MS's USBHUB20.SYS v. 5.0.2195.6891is the troublesome one. What previous versions did you find?

I *think* that VIA's USBHUB20.SYS v. 4.90.3000.11 is universal and might be used for all users, while MS's USBHUB20.SYS v. 5.0.2195.6891 is not. So, one compromise solution would be to install VIA's USBHUB20.SYS v. 4.90.3000.11 for everybody, regardless and forget about it. However, I think that some select users experienced enough to be able to substitute back the USBHUB20.SYS for the one they already know works in their systems should test this approach. Of course, those testers must be running non-VIA machines, for this test to be useful. These are my 2 ¢.

Link to comment
Share on other sites

AFAIK, the MS's USBHUB20.SYS v. 5.0.2195.6891is the troublesome one. What previous versions did you find?

I *think* that VIA's USBHUB20.SYS v. 4.90.3000.11 is universal and might be used for all users, while MS's USBHUB20.SYS v. 5.0.2195.6891 is not. So, one compromise solution would be to install VIA's USBHUB20.SYS v. 4.90.3000.11 for everybody, regardless and forget about it. However, I think that some select users experienced enough to be able to substitute back the USBHUB20.SYS for the one they already know works in their systems should test this approach. Of course, those testers must be running non-VIA machines, for this test to be useful. These are my 2 ¢.

I found USBHUB20.SYS v.5.0.2195.5605 inside this package (issued for Q319973). There may be others, but I'll have to look through all of the many, many packages I downloaded again. :wacko: Maybe someone can test that version and see if it has the same bugs as the later one... :unsure:

My next question was going to be whether or not the VIA USB2 stack works for all other chipsets, and if so, suggest using it instead. Similar to your suggestion. :thumbup

Link to comment
Share on other sites

The fact that VIA's USBHUB20.SYS is versioned as 4.90.3000.11 is suggestive it might be 9x/ME universal. However, remembering that VIA and Intel use the UHCI standard for USB 1.x while all the other manufacturers use OHCI, I'd say the most relevant tests should be with non-VIA and non-Intel USB controller chips. And I do think we should concentrate on it, before engaging in a hunt for other versions. It's too bad I only have VIA based machines and USB add-on cards (except for my NEC USB 3.0 card, but that's another thing entirely, since I've not yet even got my 98SE to detect it).

Link to comment
Share on other sites

The fact that VIA's USBHUB20.SYS is versioned as 4.90.3000.11 is suggestive it might be 9x/ME universal. However, remembering that VIA and Intel use the UHCI standard for USB 1.x while all the other manufacturers use OHCI, I'd say the most relevant tests should be with non-VIA and non-Intel USB controller chips. And I do think we should concentrate on it, before engaging in a hunt for other versions. It's too bad I only have VIA based machines and USB add-on cards (except for my NEC USB 3.0 card, but that's another thing entirely, since I've not yet even got my 98SE to detect it).

I tend to prefer using the MS stack if the older versions don't have the bugs with VIA chipsets, but I agree the other option should be tested and considered as well.

I have the same problem you do regarding UHCI/OHCI so I can't help with testing the second option. All of my hardware is Intel based with UHCI USB 1.1 controllers. (And man, has it been a pain for a project currently in development that I've been involved in. :ph34r: )

Link to comment
Share on other sites

I tend to prefer using the MS stack if the older versions don't have the bugs with VIA chipsets, but I agree the other option should be tested and considered as well.

Me too :yes: The thing is, people who have other chipsets, will using the VIA file cause problems? All of my chipsets are intel as well. My thing is, if the VIA file is not a universal solution, then we are back to square one. It seems the MS version works with everything except VIA. At least this is what has been reported.

I found USBHUB20.SYS v.5.0.2195.5605 inside this package (issued for Q319973). There may be others, but I'll have to look through all of the many, many packages I downloaded again. :wacko: Maybe someone can test that version and see if it has the same bugs as the later one... :unsure:

dencorso, since you do have a VIA chipset, can you test the file for us? Edited by PROBLEMCHYLD
Link to comment
Share on other sites

Guys, what exactly is the problem with MS' usbhub20.sys and Win98SE? I forgot and finding that info in such long topic isn't easy. Besides, I'm looking at my VIA VT6202 USB 2.0 Hub driver details panel and it says usbhub20.sys 5.00.2195.6891 (Microsoft). The controller also uses a MS driver usbehci.sys 5.00.2195.6882, with USBPORT.SYS 5.00.2195.5652.

My Lexmark X1150 printer/scanner works fine (used to, cartriges are now dry), the CSR Bluetooth dongle is also active and running fine and whatever USB Flash stick I plug into the only free outlet, works without any issue.

So, again, what seems to be the problem with that driver and VIA USB chipsets...?

Edited by Drugwash
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...