Jump to content

Problem Installing Card Reader [Solved]


Dave-H

Recommended Posts

Thanks belatedly for the Test-Run program too.

I had a look at it, and the first thing that the readme says is that Windows has to be installed on drive C:, which it is, and in a folder called "Windows", which it isn't!

My Windows 98 is in a folder called C:\WIN-98, so I suspect that Test-Run won't work.

The installer and user batch files would need a bit of editing on the paths to make it install and work properly. The installer extracts to a temp directory, which would give you the opportunity to edit the files if you're so inclined.

One common symptom of a bad battery is the system time changing on a shutdown. Was the time off when the BIOS settings changed? A weak or dead battery wouldn't likely show up on a restart. It usually takes a full shutdown where it's fully powered down for a few before it shows up in the system time.

Link to comment
Share on other sites


I think something has gone wrong on the motherboard itself.

I assume it's not an actual hardware failure, or it wouldn't work in Windows 2000, but I think that something has happened in the BIOS.

Make sure that you have all your BIOS settings fully documented on a piece of paper, so that you can manually reset them to where they were.

Another idea may be to install a fresh rudimentary 2nd Win98 opsys on a different partition, and then see whether you can get the sound card to work on the clean fresh Win98.

I have used Driver Magician http://www.drivermagician.com/ (old v3.28 is good enough for me), not Driver Magic. Driver Magician was helpful in identifying drivers on my system during my installation of the HP2605dn Color LaserJet under Win98. After installing the HP driver, the category "Universal Serial Bus controllers" in Device Manager was renamed to "HPP EWS", probably because some people at Hewlett Packard thought that the only purpose of USB is to connect HP printers. nusb works fine nevertheless, the screenshot shows a 1TB USB HDD used under nusb as "USB Mass Storage Device".

I have added also a screenshot of DriverMagician. nusb is not in the list of drivers of Driver Magician, Driver Magician does not regard nusb to be a driver, although MS drivers installed by nusb are indicated ("USB Mass Storage Device" and "SMSC USB Floppy", both dated 11-16-2007, in the 3rd screen shot). The SCSI controller drivers shown in screenshot 4 may (or may not) cause corruption on my system because they were not removed before installing nusb; the VAX347S SCSI controller is something of the Alcohol software.

I have installed nusb after (= on top of) ASPI Layer v4.60.1021 and after the HP2605dn printer, which also has a built-in USB hub/USB Composite Device and a Win98 driver for USB Printing Support.

Edited by Multibooter
Link to comment
Share on other sites

Well, I've just spent a frustrating afternoon trawling the web for information about IRQ steering problems in Windows 98.

I'm still trying to get my sound hardware to work again before I even think of going any further with NUSB!

Didn't actually get very far.

It does appear to be an IRQ allocation problem, but I can't think why it should have suddenly happened, or how to resolve it. If only I had some old copies of system.dat and user.dat.............. :(

Please save them now! ... ok ... some time travel ...

Well, just tried a set of old files.

I had a set of files called system.els and user.els, which from their sizes looked like they might actually be backed up registry files. I've no idea what generated them, and a web search didn't reveal anything either.

They are date stamped some time in last March.

Renamed them to system.dat and user.dat, and they worked!

The system booted OK, with registry data from eight months ago.

You should know that you can use this awesome utility called RegDat (website: http://freenet-homepage.de/h.ulbrich/) Win9x version is regdat.zip. It allows you to open the binary files SYSTEM.DAT and USER.DAT directly within the program and then export an ASCII registry file complete or any selected section. Very Very nice. Then you can try using these previous registry values in .REG patches among other things.

But here is another idea which I am always suggesting. Grab a spare HDD and replace your system drive with it, and then re-install Win9x (nothing else), and you can grab that new registry as a parallel working prototype to manually fix any holes in your current one. I suggest that before you install Win9x again, that you first flush the BIOS (maybe pull the battery and/or short the reset jumper too) and reset defaults and then make sure that all settings are correct (ACPI, USB, etc). With that new registry in hand and a lot of spare time, anything should be able to be fixed by carefully porting the known good values.

Also the disabled "APCI IRQ Holder for PCI IRQ Steering" is there in the device list exactly the same, and I'm sure it was never like that before.

I can tell you exactly how to re-enable them (though the suggestion above to re-install on a spare drive is better). But, in a nutshell here it is (export the registry and use an editor!):

First, find out exactly how many IRQ Holders you have defined by counting the subkeys under:

HKEY_LOCAL_MACHINE\Enum\Acpi\*pnp0c0f

Note: that red color indicates that it is probably within *pnp0c0f but I am not sure if that is a constant. Anyway, you are looking for and counting all the subkeys that contain the string value pair:

"DeviceDesc"="ACPI IRQ Holder for PCI IRQ Steering".

For example I have eight of them:

[HKEY_LOCAL_MACHINE\Enum\Acpi\*pnp0c0f\00000001] ...thru...

[HKEY_LOCAL_MACHINE\Enum\Acpi\*pnp0c0f\00000008]

Now, these devices must appear under two other keys, ENUM and START ...

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Asd\Prob\{9b4e7760-3196-11cf-97ea-00aa0034319d}]
;;; "Problem"="Enumerating a Device"
"Acpi\\*pnp0c0f\\00000001"=hex:00
"Acpi\\*pnp0c0f\\00000002"=hex:00
"Acpi\\*pnp0c0f\\00000003"=hex:00
"Acpi\\*pnp0c0f\\00000004"=hex:00
"Acpi\\*pnp0c0f\\00000005"=hex:00
"Acpi\\*pnp0c0f\\00000006"=hex:00
"Acpi\\*pnp0c0f\\00000007"=hex:00
"Acpi\\*pnp0c0f\\00000008"=hex:00
[color="#FF0000"];;; NOTE: lots of other devices are in this list![/color]

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Asd\Prob\{cf2524c0-29ae-11cf-97ea-00aa0034319d}]
;;; "Problem"="Starting a Device"
"Acpi\\*pnp0c0f\\00000001"=hex:00
"Acpi\\*pnp0c0f\\00000002"=hex:00
"Acpi\\*pnp0c0f\\00000003"=hex:00
"Acpi\\*pnp0c0f\\00000004"=hex:00
"Acpi\\*pnp0c0f\\00000005"=hex:00
"Acpi\\*pnp0c0f\\00000006"=hex:00
"Acpi\\*pnp0c0f\\00000007"=hex:00
"Acpi\\*pnp0c0f\\00000008"=hex:00
[color="#FF0000"];;; NOTE: lots of other devices are in this list![/color]

If there was a problem the hex:00 will either show up as hex:01 or be deleted completely. If they are deleted completely, they show up as disabled in Device Manager. For example if #4 and #7 were disabled from above, those two keys would look like so ...

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Asd\Prob\{9b4e7760-3196-11cf-97ea-00aa0034319d}]
"Acpi\\*pnp0c0f\\00000001"=hex:00
"Acpi\\*pnp0c0f\\00000002"=hex:00
"Acpi\\*pnp0c0f\\00000003"=hex:00
"Acpi\\*pnp0c0f\\00000005"=hex:00[b] <-- see?[/b]
"Acpi\\*pnp0c0f\\00000006"=hex:00
"Acpi\\*pnp0c0f\\00000008"=hex:00[b] <-- see?[/b]

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Asd\Prob\{cf2524c0-29ae-11cf-97ea-00aa0034319d}]
"Acpi\\*pnp0c0f\\00000001"=hex:00
"Acpi\\*pnp0c0f\\00000002"=hex:00
"Acpi\\*pnp0c0f\\00000003"=hex:00
"Acpi\\*pnp0c0f\\00000005"=hex:00[b] <-- see?[/b]
"Acpi\\*pnp0c0f\\00000006"=hex:00
"Acpi\\*pnp0c0f\\00000008"=hex:00[b] <-- see?[/b]

Keep in mind that the contents of those two keys are not necessarily in sorted order (although in REGEDIT they will look sorted). So in your editor you have to scroll all the way through all the devices under those two keys to see everthing (or just use your editor's search/find command ;-)

Anyway, this REG patch would restore the missing ones (#4 and #7 from my example only! you would need to make a custom one for yours!) ...

REGEDIT4

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Asd\Prob\{9b4e7760-3196-11cf-97ea-00aa0034319d}]
"Acpi\\*pnp0c0f\\00000004"=hex:00
"Acpi\\*pnp0c0f\\00000007"=hex:00
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Asd\Prob\{cf2524c0-29ae-11cf-97ea-00aa0034319d}]
"Acpi\\*pnp0c0f\\00000004"=hex:00
"Acpi\\*pnp0c0f\\00000007"=hex:00

Note that when playing in this part of the registry it is good practice to reboot several times before you go back in and compare registry settings because Windows can change things very quickly from INF files.

My workaround is not to transfer data directly between 2 USB mass storage devices (even between a USB DVD-Drive and a USB HDD!), but indirectly via the internal HDD. I try to avoid as much as possible to have two 1TB USB HDDs connected at the same time,

This is very good advice for highly CPU bound busses. I do the exact same thing on Win9x and on slow processors as a rule. :thumbup (though Vista/7 with Dual/Quad Core finally makes it a moot point).

Link to comment
Share on other sites

Thanks "Charlotte" that's really useful diagnostic information!

:thumbup

I checked the registry parameters you referred to.

I too have eight "APCI IRQ Holder for PCI IRQ Steering" devices.

They are all listed under the {9b4e7760-3196-11cf-97ea-00aa0034319d} with "00" data.

However under the {cf2524c0-29ae-11cf-97ea-00aa0034319d} key, number 00000007 was missing.

That is the problem one.

I manually restored the key for that device and gave it "00" data.

When I rebooted nothing had changed, but the key was still there.

I tried removing the sound hardware in Device Manager, and it put it back as before when I rebooted, and those registry entries still hadn't changed.

I them removed the sound hardware and the problem steering device using the HP System Diagnostics program. (This does tell you which devices have a problem, which Device Manager in Safe Mode doesn't).

On a reboot everything was put back exactly as before, and the registry entry under{cf2524c0-29ae-11cf-97ea-00aa0034319d} for that device had disappeared again.

I am now pretty sure that the sound problem must have appeared when I had the problem with the BIOS resetting itself.

I think I'm going to have to open the machine up, check the CMOS backup battery (I'll probably replace it anyway even if it seems OK) and then decide whether I'm going to bite the bullet and clear the CMOS and try reloading it again.

I do have a motherboard BIOS recovery boot disk, so I hope I'm covered in case of disaster.

If I disappear from here for a while, it will be because I've rendered my PC completely useless and am tearing my hair out trying to get it up and running again!

:)

I'm really sorry that this thread has been so much off topic, I hope the MSFN mods understand why it has rambled away from the original subject so much.

At least the memory stick problem was vaguely relevant, this problem is almost certainly just an awkward and annoying coincidence which might well have happened anyway but has nothing whatsoever to do with any USB issues!

Link to comment
Share on other sites

I'm really sorry that this thread has been so much off topic
I don't think that you have been off-topic, this is just what may happen when you install nusb: You find one can of worms after another, with more cans of worms hidden inside other cans, like a Russian Matryoshka doll , until your system is more or less clean. The cans of worms deep inside contain unsolvable multiple drive letter problems.

Your nusb problems just got seriously compounded by a lack of backups.

Edited by Multibooter
Link to comment
Share on other sites

I'm really sorry that this thread has been so much off topic, I hope the MSFN mods understand why it has rambled away from the original subject so much.

At least the memory stick problem was vaguely relevant, this problem is almost certainly just an awkward and annoying coincidence which might well have happened anyway but has nothing whatsoever to do with any USB issues!

IMHO, it's not really off topic. The thread title itself became outdated in view of the developments that unfolded from the Card Reader installation. So, I think we should concentrate into helping you solve your system's issues, but maybe also update the thread title, when we come up with a more adequate one. I don't think "problems arrising from installing nusb" is a fair alternative, because nusb not always lead to such complicated issues. Most of the time it does not. And I agree with Multibooter that a big part of what made this really complicated was the lack of suitable backups. Whatever the title we agree to, I think the thread must be renamed like this: "New Agreed Title (was: Problem Installing Card Reader)". But that's not a pressing matter, and solving Dave's system issues surely is.
Link to comment
Share on other sites

Thanks yet again guys!

:)

Well, I've had the crate apart, replaced the CMOS backup battery just to be on the safe side, although the one in there seemed to be perfectly OK.

I cleared and re-flashed the BIOS, just to completely re-initialise it.

System's still working thank goodness, but the Windows 98 sound problem hasn't gone away.

:no:

I must say I was deeply surprised when restoring a months' old registry backup had no effect on the problem.

All the registry backups in the world wouldn't have helped with this it seems.

I'm usually pretty good at backing up the registry, even though I got caught this time, but what I don't do is back up my entire Windows folder regularly.

I think I may well review that policy now.........

:yes:

I would have bet the farm after the registry restore didn't work that that the cause of the problem was on the motherboard, either a BIOS corruption of some sort (especially after it spontaneously reset on me) or an actual hardware failure of some sort (although why that wouldn't affect Windows 2000 as well is beyond me!)

It would seem that's not the case.

So, what are we left with if it's not something in the registry or the hardware/BIOS?

It can only be a wrong file or files sitting somewhere.

I'm pretty sure it can't be incorrect sound driver files as I've uninstalled them and reinstalled them several times, so I can only assume that it's a Windows system file or files that have been replaced perhaps with problem versions.

Time for the Windows System File Checker I think...........

:)

Link to comment
Share on other sites

I manually restored the key for that device and gave it "00" data.

When I rebooted nothing had changed, but the key was still there.

I tried removing the sound hardware in Device Manager, and it put it back as before when I rebooted, and those registry entries still hadn't changed.

I them removed the sound hardware and the problem steering device using the HP System Diagnostics program. (This does tell you which devices have a problem, which Device Manager in Safe Mode doesn't).

On a reboot everything was put back exactly as before, and the registry entry under{cf2524c0-29ae-11cf-97ea-00aa0034319d} for that device had disappeared again.

Note that it was removed from the {cf2524c0 START key which I read as Windows attempted to start some device (maybe Audio) on this shared IRQ and it failed. This could mean that the current PnP arrangement is ineffective and may require re-arranging cards, BIOS resets and a boat-load of patience ... or ... there is an actual hardware failure.

Two ideas that might help if it is not a hardware failure. Please be sure the BIOS has been flushed and settings are then set correctly:

(1) The In-Place Nuclear Option: back up the twin files Drvdata.bin and Drvidx.bin located in Windows\INF (also save the registry files at the same time and consider them a four file matched set). Then you delete those BINs in true DOS (F8 Menu: Command Line, this is much fast than Safe Mode), reboot and enjoy the show while Win9x performs drastic Plug and Pray brain surgery. After several more reboots some chance exists that the audio might be working.

(2) Re-arrange the PCI cards and then do the Nuclear Option. (ACTUALLY: you boot to DOS (F8 Menu), then delete the BINs, then shut the power off, then re-arrange the cards, then power up. Make sense?) Save the files beforehand as mentioned above!

In either case: if it works and the audio is fixed, grabbing the new four file matched set as a working prototype to be WinDiff'd against the saved set will lead to the answer as to what had changed (NOTE that if the cards have changed slots, there will be new registry key names and a comparison requires some skill as well).

Both of the above is still a rough approximation to (3) a clean install on a different HDD which later can be slaved to the system, allowing you to cherry pick fresh working objects (registry entries, INF files, INI files, etc) and shoe-horn them into your current system. To be clear, I do not recommend the above (deleting the INF database) for casual users because it is a truly destructive approach: you may blue screen halt. You would then have to know how to go into true DOS and manually restore those four files in order to recover. This is why working on a spare drive (while the system drive is safely sitting on the shelf) is so much more preferable. Or, you could even clone the current system to a spare HDD and experiment away on the clone without fear (including drastic measures like deleting the INF database, re-installing the Chipset INF package, swapping card slots).

Really, if all three of these drastic measures (especially the clean install) results in a system that still has audio problems your culprit is likely a hardware problem. These do happen (perhaps static discharge while changing RAM DIMMs) although rarely after a proper burn-in period.

So, what are we left with if it's not something in the registry or the hardware/BIOS?

It can only be a wrong file or files sitting somewhere.

I'm pretty sure it can't be incorrect sound driver files as I've uninstalled them and reinstalled them several times, so I can only assume that it's a Windows system file or files that have been replaced perhaps with problem versions.

Time for the Windows System File Checker I think........... :)

I highly doubt that SFC will lead anywhere promising. But the only thing you've got to lose is a little time, so go for it!

BTW, for anyone wondering why not just re-install Windows and start over, you must understand the need for this preservation method: you have tons of stuff installed with all their attendent registry keys and files spread all over the disk, countless updated Windows core files and runtime libraries. Not to mention private data, passwords, users, customizations, etc. Blasting away a working system has consequences, especially when you ponder reverting the majority of the environment to 4-23-99 or older. IMHO, with enough effort any problem can be rectified this way, except for hardware failures of course. However, for this to work you must have a clean working set of registry/INF data for a reference. Hence the repeated suggestion to install to a spare drive. If the problem cannot be rectified on a nice new (and smaller and faster) registry, it will never be rectified under the current one.

If I disappear from here for a while, it will be because I've rendered my PC completely useless and am tearing my hair out trying to get it up and running again!

Yikes! this should never happen! Golden Rule: never experiment on your one-and-only system drive! Backup, Backup, Backup (or Clone, Clone, Clone). Then you can try anything with nothing to lose.

Link to comment
Share on other sites

Thanks again Charlotte!

:)

I tried your first suggestion, saving and deleting the two .bin files in the inf folder.

When I re-booted the system started up normally, which surprised me.

I assume that I should have removed the problem device first, which you didn't mention!

Anyway, I did that, and it was put back exactly as before.

I then tried removing all the devices on the PCI bus, and the steering devices and the PCI bus itself.

When I restarted it went through all the motions of installing everything again, but the sound card still has no IRQ.

There are now two new bin files in the inf folder.

Should I just keep them, or restore the ones I saved?

Incidentally, in case you didn't pick this up from earlier, the sound "card" and the ethernet controller (which is working fine) are part of the motherboard, so swapping cards around, at least as far as they are concerned, isn't possible.

The other things actually in the slots are the AGP graphics card, a SCSI card, and a DV video capture card.

They are all working perfectly.

So, does this leave us with a hardware fault?

I find that very hard to believe as the sound on Windows 2000 still works perfectly, using the same hardware.

I believe that the IRQ steering system on Windows 98 (I assume 2000 is completely different) uses a thing called an IRQ table, which it gets from the motherboard BIOS or the devices themselves.

The settings can be changed using the PCI Bus properties in Device Manager.

I have tried different settings here (it's on the default at the moment) but nothing seems to help.

Is it possible that the system is not getting the information for the sound device, or is getting incorrect information?

Could some sort or corruption on the motherboard cause this (I'm still very suspicious of that BIOS re-set which I've never had happen before)?

Maybe there could be something wrong in this area which doesn't affect Windows 2000 because it detects devices in a different way?

I would phone Supermicro technical support about this, but I'm sure they won't want to know as soon as I say the words "Windows 98"! They did tell me ages ago that the board was never tested with Windows 98, but it's worked for years without any problem.

Are there any diagnostics programs which will allow me to see what's on the PCI bus at a very basic BIOS level?

So many questions.......

:)

Link to comment
Share on other sites

Are there any diagnostics programs which will allow me to see what's on the PCI bus at a very basic BIOS level?

Yes! Below BIOS level, at PCI Bus level, in fact. Craig's PCI Programs. They're console apps. Generate a report by redirecting the output to a file. Use v. 1.6 in 2k and 1.1 in 98, and compare the logs. Let's see what it finds. If you wish, you may zip the logs and attach the zip here, so we all may muse over them and see whether we find something useful. If that doesn't lead us anywhere, my next suggestion is for you to remove ACPI altogether (after a backup, of course) to see where it leads us. By now, I'm becoming short of ideas, sorry. :( But, just for the record, and for what it's worth: you're right in thinking that 2k (but not 98) detects all devices independently of what the BIOS says. And to deduce that if the sound works in 2k its hardware must be OK.

Link to comment
Share on other sites

I tried your first suggestion, saving and deleting the two .bin files in the inf folder.

When I re-booted the system started up normally, which surprised me.

I assume that I should have removed the problem device first, which you didn't mention!

Doh!, my bad. You have to cause a re-detection somehow, this is usually done by deleting the whole key or just branches in HKEY_LOCAL_MACHINE\Enum or removing devices in Device Manager or pulling or swapping PCI cards or even by disabling a couple of items in the BIOS (like USB, serial, parallel, ethernet, sound etc), anything that will trigger a shuffling of interrupts.

Let the record show that my real suggestion is to install Windows on another HDD to find out if this mobo is still 100% functional, because if it is not, we are just spinning wheels (not that wheel spinning isn't fun mind you ;-)

There are now two new bin files in the inf folder. Should I just keep them, or restore the ones I saved?

Well, I always restore to an exact known state, so as mentioned in that last post I would restore those two BINs and the Registry as well (four file matched set).

So, does this leave us with a hardware fault?

This we do not know yet. There was a time when IBM machines had BIOS based or 5.25" floppy disk diags which made this simple. Unless you can scour the Supermicro website and forums and locate some DOS based utility that queries their hardware, well, your are only left with deductive reasoning.

Incidentally, in case you didn't pick this up from earlier, the sound "card" and the ethernet controller (which is working fine) are part of the motherboard, so swapping cards around, at least as far as they are concerned, isn't possible.

yeah, I saw that, although after re-reading this thread I am confused a little, I need to ask: Are you still dual-booting Win2K and the audio is absolutely positively definitely ok in Win2K?

I find that very hard to believe as the sound on Windows 2000 still works perfectly, using the same hardware.

This seems to answer that question as yes, and that means there is NO hardware problem! We got our answer.

Incidentally, in case you didn't pick this up from earlier, the sound "card" and the ethernet controller (which is working fine) are part of the motherboard, so swapping cards around, at least as far as they are concerned, isn't possible.

The other things actually in the slots are the AGP graphics card, a SCSI card, and a DV video capture card.

Yeah but AC97 or SB card is all the same to Plug and Pray. Disabling the onboard ethernet is like removing a NIC, disabling the onboard sound is like pulling out a SB card, etc. Does this mobo also have onboard video which may have somehow become re-enabled thereby re-arranging IRQs? I should have asked earlier but have you already killed un-necessary devices in the BIOS (serial, parallel, etc)?

I believe that the IRQ steering system on Windows 98 (I assume 2000 is completely different) uses a thing called an IRQ table, which it gets from the motherboard BIOS or the devices themselves.

From the BIOS is the first choice in that infamous IRQ Steering dialog box. This table (located in the BIOS Eprom) actually can change if you flash your BIOS with an updated (or modded) image. If you have not done any flashing whatsoever, and the sound did in fact work at some time, the problem is most definitely not in here. Doublecheck that Control Panel > System > Device Manager > System Devices > PCI Bus > (Properties) > IRQ Steering and make sure only the 3rd box (Protected Mode) is unchecked.

Dave, it seems clear to me that this is just a configuration error in Win9x. If you handed me this mobo, I would ...

- Pull all the cards (3 right? AGP included if there is onboard video)

- Clear the CMOS

- Disable practically everything in the BIOS (USB, ethernet, etc)

- Install Win9x on a spare drive

- Install Chipset INF

- Install Audio drivers

- Ensure Audio is working (save REG/BINs)

- Re-Enable one-by-one

- Ensure Audio is working (save REG/BINs)

If all is ok I would transplant the Hardware tree to the old system. It is difficult. But this is the nature of Plug and Pray (don't get me started on this subject!). You see, you need to jigger the IRQ arrangement which is a real PITA. Sometimes you can manually change them in Device Manager under certain Resources tabs, and then you change another and another, etc, but it sucks in a big way. Near as I can tell the sound problem began when the USB reader was added. This is a clear case of Interrupt conflict and Windows not really sharing devices as Plug and Pray promised.

Are there any diagnostics programs which will allow me to see what's on the PCI bus at a very basic BIOS level?

In addition to what dencorso said (Craig Hart's software) there is also Martin Mal¡k (REALiX) HwInfo, get the DOS Version. Both of these (Craig Hart and Martin Mal¡k) query the hardware directly. They are ran from true bare DOS on floppies.

Link to comment
Share on other sites

I've run the Craig Hart utility successfully, and I've attached the logs as a zip file.

There are three logs, one is PCI logging in true DOS, one is PCI logging using a DOS prompt with Windows 98 running, and one is PCI32 logging at a Windows 2000 command prompt.

I was glad to see that to my untrained eye there seemed to be no obvious problems recorded.

I didn't have so much luck with the HWinfo utility.

I just kept crashing and/or throwing up "not enough memory" messages (this was in true DOS).

I hope these logs may show something up.

Certainly it seems to be happy with the IRQ tables, which is a relief!

:)

Link to comment
Share on other sites

I've run the Craig Hart utility successfully, and I've attached the logs as a zip file.

There are three logs, one is PCI logging in true DOS, one is PCI logging using a DOS prompt with Windows 98 running, and one is PCI32 logging at a Windows 2000 command prompt.

attachment=28033:PCITestResults.zip

Wowza. Looking at that IRQ11 makes me wonder how Win9x is even working ...

 System IRQ  5, INT# C ... Intel Corporation 24C7h 82801DB/DBL USB UHCI Controller #3 (ICH4/ICH4-L B0 step)
System IRQ 10, INT# B ... Intel Corporation 24C4h 82801DB/DBL USB UHCI Controller #2 (ICH4/ICH4-L B0 step)
System IRQ 11, INT# A ... Adaptec Inc 8178h AHA-2940U/UW/2940D Ultra/Ultra Wide/Dual SCSI Host Adapter
System IRQ 11, INT# A ... ATI Technologies Inc 5961h Radeon 9200 Series (RV280)
System IRQ 11, INT# A ... Conexant Systems 2F00h HSF 56k HSFi Churchill Data/Fax Modem
System IRQ 11, INT# A ... Intel Corporation 100Fh 82545EM Gigabit Ethernet Controller (Copper)
System IRQ 11, INT# A ... Intel Corporation 24C2h 82801DB/DBL USB UHCI Controller #1 (ICH4/ICH4-L B0 step)
System IRQ 11, INT# A ... Philips Semiconductors 7146h SAA7146 Multimedia Bridge Scaler
System IRQ 11, INT# B ... Intel Corporation 24C3h 82801DB/DBL SMBus Controller (ICH4/ICH4-L B0 step)
System IRQ 11, INT# B ... Intel Corporation 24C5h 82801DB/DBL AC'97 Audio Controller (ICH4/ICH4-L B0 step)
System IRQ 11, INT# D ... Intel Corporation 24CDh 82801DB/DBL USB 2.0 EHCI Controller (ICH4/ICH4-L B0 step)
System IRQ 15, INT# A ... Intel Corporation 24CBh 82801DB/DBL (ICH4/ICH4-L) UltraATA/100 EIDE Controller

I didn't have so much luck with the HWinfo utility.

I just kept crashing and/or throwing up "not enough memory" messages (this was in true DOS).

Jeez, unless he has changed something in this version it should work. Just for the heck of it, try adding the himem.sys file to the floppy and this line to config.sys:

device=himem.sys /testmem:off

I am not sure why you would get that error. On my HwInfo floppies (I just checked) I only have lastdrive=z in the config. Anyway, there is a nice thing in HwInfo where he shows the Supported IRQ(s) for the devices it finds. I also like comparing its IRQ summary against the Win9x summary (see below).

Certainly it seems to be happy with the IRQ tables, which is a relief! :)

Looks good from PCI.EXE (The ROM PCI IRQ routing table appears to be OK.), though I am not exactly sure what PCI/PCI32 can tell except for the fact that the table can be successfully read or not. But as stated previously, as long as you have not flashed or physically replaced the chip itself, the routing table is a constant and not part of the problem. But a few other things now come to mind:

Any chance that you have some resources reserved in that Device Manager > Computer > Properties > Reserve Resources Tab?

Does your BIOS allow disabling USB completely? If so, you might try it and reboot and see if the sound works.

Could you please explain exactly the cards installed (I thought 3, but it looks like there is a modem too?). I looked throughout this thread but do not see it detailed. Are you actually using both Ethernet and modem?

Can you post the the Device Manager > Computer > Print > All Devices > Print To File. This is the Win9x view of the environment and essentially tells us what Win9x did with the BIOS IRQ Routing Table it called up.

Does the motherboard have onboard video (yeah I do see the ATI card)? The reason I ask is that sometimes it helps to first install the chipset INF without any video card and get only the mobo native devices working, then install the video card and its drivers. This results in a different IRQ arrangement, most importantly the onboard USB gets first pick of the IRQ litter (typically four different ones).

Link to comment
Share on other sites

Ah yes, I realised after I posted that I'd forgotten about the modem!

I don't actually use it now of course, but I've always kept it there as a backup in case my broadband fails (it actually did once, and I had to use the modem again, I'd forgotten how painfully slow dial-up was!)

There is no on-board video hardware on the motherboard, just ethernet and audio.

There has always been a large number of things sharing IRQ11 on Windows 98, but it's always worked OK.

I will try HWinfo again, using the settings you suggest.

I have updated the BIOS version to the latest, but I assume that doesn't change the routing tables.

I think I may have discovered what caused that BIOS settings reset.

I used my USB ZIP drive yesterday for the first time in ages, and it worked fine, but I rebooted without unplugging it.

When the system booted up, the BIOS correctly detected the drive after a bit of a pause, and when I rebooted again, the BIOS had reset again!

I think what may be happening is that every time the BIOS detects a new USB device connected to it, it resets itself.

I've no idea why it should do that, but the first reset was probably caused by my rebooting with my USB flash drive plugged in. It therefore probably has no bearing on the sound problem.

I will try booting with all USB functions disabled in the BIOS, to see if that has any effect.

There are no reserved resources.

I'll report back on all this later, and I'll attach that readout from Device Manager.

Thanks Charlotte!

:)

Link to comment
Share on other sites

Dave's board is the X5DAE. Attached here's the motherboard manual. It may be of help at this point.

@Dave: please confirm I've got the right manual. You might: Turn the machine off. Remove the powe cable.

Wait 60 s for all capacitors to discharge. Open the case and use the jumper JP40 to disable the onboard sound.

Then boot to safe mode and remove all sound drivers. Then go to add/remove and remove the sound driver there also if possible. Reboot in normal mode in 98 and make a backup. Then, turn the machine off. Remove the powe cable. Wait 60 s for all capacitors to discharge. Open the case and use the jumper JP40 to enable the onboard sound.

If all goes well, this time, when you go into 98, you'll have the big yellow question mark at the sound device. Check that everything else is working all right. Then install the sound drivers, as if it were the first time, preferably using the manufacturer's install program. Take care *not to boot* into 2k during the time the sound is disabled, to avoid unecessarily messing with 2k that is working all right. If this doesn't work, we might try to force the sound card into another IRQ, using the 98 device manager.

MNL_0680.7z

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...