more Code 10..Firewire device
hi anybody?
Code 10 problems.....they definitely SUCK....I'm going start with a quick description of where I'm at.
I have two PC's.....both generate "Code 10 errors" when I try to re-install an External IEEE 1394 SBP2
BusLink CD_RW.
Both PC's are running Windows 2k Pro.
The Tyan Box is the newer of the two.....
Mboard is Tyan 2462ung....This is a AMD Dual 1400Mhz.Processor Server Board
1 Gbyte Ram.
Came with no Firewire Ports....so an add-on Pci Card is required.
The CD-RW actually worked at least for a short while....Then, I crashed the OS..I re-installed over existing
OS....w/ new SID ...(I forgot I had a backup stored on it...LOL) So, I've been re-establishing new links, etc to
all my OLD programs......(most were in other partitions...but not all).
Currently this box is nearly complete.
Service packs...yes up to SP4.....just chasing this problem.
++++++++++++++++++++++++++++++++++++++
The other box is my Intel Box....a little older
MBoard is a Intel L440GX.....(dual 700 Mhz processor)...A server board
256 Kbyte Ram
No Firewire ports...So add on is required.
This box has not been a problem....running fine. So I thought that if I could get the CD-RW to work
on it maybe I could fix the the Tyan Box....
So I've chased down most every SP pack and driver upgrade I can find...Still no LUCK....except BAD
++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++
I've seen some suggestion for the ASUS mother boards where re-setting the BIOS was successful for a
similar CODE 10 problem (different device).
I've also seen a successful Utility program with a file named "TOGGLE" (toggle.exe)...which was provided for
some Nvdia device. A guy in France has a FTP site.....It's still ther...so I down loaded it.
Haven't tryed it......
I've seen some discussion about a need for more resources (IRQ's). And some suggestions to pull all your
cards out and/or move the Firewire card to a different slot.
I haven't seen a real "Honest to goodness Fix".....
A lot of people have these Code 10 problems....some are USB...some Firewire....mostly different
External devices.....
So where am I at now.?....Pretty much lost I guess.
If I haven't tried to correct this (Code 10) on one machine, then I did tried it on the other. Still no real fix.
++++++++++++++++++++++++++++++++++++++++++++++
AS of now...I'm thinking to pull the firewire card...power up, power down, then reinstall firewire card.
First I'll try this on one box and thern maybe the other...
++++++++++++++++++++++++++++++++++++++++++++
If I find a sure fire fix ...I'll be back to post it....In the mean time if anybody else finds a real SURE Fire Fix
Let Me Know...
thanks in advance, to any and all
ron_of_orange
2:40PM, PST
So I think your 'test situation' is just too complicated, turn some stuff off !
So another thing worth mentioning (both for Ron & anyone who passes by also confus-ed by this) is that as far as windows is concernced All cdrw writing is done via scsi - oh no it ain't I hear you all cry, I've only got IDE or something else that ain't scsi, anyway nothing that is, so how can they all be 'scsi' writes ? ...
Well every single writing application there is ennumerates a scsi device for any atapi type writing, they all introduce a proprietry driver to ennumerate the scsi bus & take advantage of the direct functions of that interface, try starting any machine in safe mode & you'll find a 'non windows driver' {it says press 'esc' to avoid loading} hanging about, these 'drivers' though can be a nightmare .. (strictly they aren't really drivers, as they ennumerate a device class to take advantage of that classes features)..
Methinks this will get more solveable if we figure out whether ANY writing s/w is at fault or not - so I think that's relatively easy to figure out, take all your writing software off for now (also check via my 'safe mode trick' that we still haven't got some non-windows driver hanging about) & then see if we get all these reconnect issues ..
BTW all these other TSRs mentioned 'not loading' at various points can't be helping either, for troubleshooting purposes, the less running at any time the better .. RUNDLL32 simply runs a dll as a seperate process (makes it like an .exe or near enough) its never a very reliable way to fire anything due to how encapsulation works in an embedded programming environment (can't get released program hooks as not 'parent' process - leads to lots & lots of 'timing' issues !)..
& I just realised you've got INCD running all the time - this is packet writing s/w (makes a cdr type device 'behave' as a hard disk) - for now lets also be rid of this complication, first we want to know if the 'reconnecting bit' is getting done right, never mind buring s/w going 'screwey'..