Epox 8RDA+ & losse IDE controller problem!

[Verwijderd]

Ik heb sinds kort een extra IDE controller gekocht (Promise Ultra133 TX2) voor mijn Epox Nforce2 mobo. Maar het doet alles behalve goed werken!!! ik wordt er echt ziek van

Omdat ik 'weet' dat een losse controller optimaler werkt dan een 'onboard IDE controller' heb ik alle hardeschijven aan de Promise controller gehangen. Verse Windows XP SP1 installatie gedaan met nieuwste promise WHQL driver (met F6 in setup), Nvidia 2.03 driver pack geinstalleerd (zonder SW IDE driver), alles lijkt goed te gaan. Maar toen ik in Windows kwam merkte ik dat mijn muis schokkerig werkte als ik iets met de hardeschijven doe (kopieren van veel bestanden of 1 grote), ook muziek begon te kraken.
Het eerste dat mij opkwam was dat er een IRQ conflict was. In 'device manager' bleek dat de Promise controller netjes z'n eigen IRQ had:



Echter in het BIOS-opstartscherm staat de Promise controller geshared met USB2.0 cntrlr. Ik heb daarvoor de Promise controller verplaatst naar verschillende PCI-slots, maar niks helpt, de controller blijft als enige een IRQ sharen met een ander device. wat ik ook doe



Voordat ik APIC ging uitzetten in BIOS en windows weer opnieuw installeer, heb ik ook geprobeerd terug tegaan naar oudere Promise BIOSen en drivers, maar na alles is het probleem in z'n geheel gebleven.
Nu ik er ziek van ben geworden, heb ik al mijn schijven weer terug aan de onboard controller gehangen en alles werkt weer goed (CD-ROM en DVD-RW aan Promise Cntrlr), totdat ik dus veel data vanaf cd-rom gaat kopieren krijg ik dus dat gekraak weer.

geprobeerd:
- Nvidia SW IDE driver/MS IDE driver
- Microsoft SP2 Nforce CPU/IDE util patch
- verschillende PCI slots en andere kaarten eruit gehaald
- APIC / ACPI
- Windows Update
- Promise Bios/drivers (alle combinaties)
- Epox biosen (nieuwste: 3501)
- andere muizen

Zonder die Promise controller werkt alles goed!!! geen gekraak in geluid, geen frame drops bij video capturen, perfect....!!! (veel mensen hebben problemen met krakend geluid maar ik NIET, althans als ik die losse IDE controller niet gebruikt )

Het probleem wijst dus naar de losse "Promise Ultra133 TX2 IDE controller" en z'n communicatie met de PCI bus van de Nforce2 SB of de CPU. Hopelijk is het een driver of BIOS bug dat snel wordt verholpen!

Mijn vraag is: Heeft iemand ook een losse IDE controller samen met een Nforce2 mobo? en problemen ermee? of weet iemand de oorzaak en oplossing van het probleem?

ik hoop de situatie duidelijk te hebben beschreven....

ps. wat ik ook merkwaardig vind is dat de promise controller geen IRQ shared maar wel een I/O port.....


weet iemand of dit kwaad kan?

[ Voor 9% gewijzigd door Verwijderd op 05-05-2003 20:38 ]

[zetje01]

Heb op got vaak gelezen dat de 2.03 drivers niet echt lekker zijn en dat je beter 2.0 kunt gebruiken

edit: ik heb overigens de ep-8rda+ met een raidcontrollerkaartje (met Sil680 chipset) in raid0.
geen gekraak of muisproblemen gehad.

[ Voor 42% gewijzigd door zetje01 op 05-05-2003 22:25 ]

[XoReP]

Disable ff alle onboard zooi op je mobo in je bios (dus USB enzo )

[Dukey]

Je kunt idd die USB 2.0 apart uitzetten zodat je nog USB 1.1 overhoudt. Heb ik zelf ook gedaan aangezien ik geen USB 2.0 apparaten heb en toch liever Firewire gebruik.

En dit
"Omdat ik 'weet' dat een losse controller optimaler werkt dan een 'onboard IDE controller' heb ik alle hardeschijven aan de Promise controller gehangen"
vindt ik persoonlijk bullshit aangezien de onboard controller bij nieuwere mobo's bijna niet meer aan de PCI bus hangt.

[ Voor 65% gewijzigd door Dukey op 06-05-2003 09:01 ]

[Verwijderd]

Djoekie schreef op 06 mei 2003 @ 08:55:
Je kunt idd die USB 2.0 apart uitzetten zodat je nog USB 1.1 overhoudt. Heb ik zelf ook gedaan aangezien ik geen USB 2.0 apparaten heb en toch liever Firewire gebruik.

En dit
"Omdat ik 'weet' dat een losse controller optimaler werkt dan een 'onboard IDE controller' heb ik alle hardeschijven aan de Promise controller gehangen"
vindt ik persoonlijk bullshit aangezien de onboard controller bij nieuwere mobo's bijna niet meer aan de PCI bus hangt.

tja, maar waar die ook aanhangt, op een losse controller heb je altijd rond de 10% CPU usage (of zelfs minder)

maar nu even on topic. Ik snap er niks meer van, veel mensen hebben dit probleem ook, en lossen dit op door een oudere driver voor de promise te installeren. Maar bij mij werkt het gewoon niet.

Elke keer als ik ga capturen in Studio8 krijg ik continu framedrops. En als ik capture naar een schijf op de onboard controller gaat het wel soepel.
Als de onboard controller niet aan de PCI-bus zit waar zit die dan aan?
de onboard is een controller met eigen IRQ, maar de promise is ook een controller met eigen IRQ (volgens APIC mode in windows). Zal die promise controller toch een IRQ sharen met iets anders in een onderliggend niveau? (of zoiets )
Promise cntrlr heeft IRQ 17 (zonder APIC zijn er maar 15 IRQ's)

[ Voor 37% gewijzigd door Verwijderd op 06-05-2003 09:40 ]

[Verwijderd]

Schop... (sorry)

[Mentalist]

Op verzoek move :

PMG > OM

Denk dat ie daar misschien ook wel beter past, het gaat wel erg om de controller tenslotte.

[Verwijderd]

Hey thanks he!!!

[BalusC]

Verwijderd schreef op 07 May 2003 @ 09:01:
Hey thanks he!!!

Da's niet nodig hoor, wij wéten dat je ons bedankt
Dat wordt dan ook gezien als een verkapte kick .. Niet meer doen dus.

Ontopic: even voor de zekerheid, hij deelt elke keer de IRQ met USB 2.0 controller, ongeacht de PCI slot waar je de promise in prikt? Heb je al gepoogd om de USB 2.0 controller in de BIOS te uitschakelen, zodat je de invloeden daarvan in ieder geval kunt uitsluiten?

[ Voor 34% gewijzigd door BalusC op 07-05-2003 09:05 ]

[Verwijderd]

hij deelt idd altijd met 'een' device. Als ik er nog een PCI kaart bij stopt veranderd de IRQ config. en shared de Promise contrlr dan met de 'Serial Bus Contrlr' en krijgt de kaart die bij geprikt heb een eigen IRQ. Achter de USB2.0 contrlr staat dan 'N/a' (omdat die niet genoeg IRQ's heeft?).

de fout zit in de richting van de Promise cntrlr, maar of dat aan de IRQ sharing ervan ligt.... denk ik haast niet. Die dingen moeten IRQ's kunnen sharen (uitgebracht tijdens de w2k tijdperk toch?). Ik zou er niet raar van opkijken als het ligt aan de Promise drivers (of een conflict ervan met de PCI bus drivers van Nforce2). Ook zal het niet gek zijn als Epox straks uitkomt met een BIOS update die het probleem oplost.

[Verwijderd]

Ik ken 't probleem..

Ik heb namelijk hetzelfde met een onboard promise Ultra100/FT100.

'T wordt niet veroorzaakt door een IRQ probleem of iets dergelijks, maar doordat Win2K sinds SP3 en WinXP een zgn Flush_Cache commando doorsturen naar SCSI schijven. (Schijven aan de Ultra controller worden als SCSI gezien).

Microsoft heeft deze functie erin gedaan, omdat 't de integriteit van de data beter zou waarborgen, immers er blijft niets meer in de write cache van de schijf over, zodat bij stroomuitval of een crash deze data niet verloren gaat.

Bij de oudere promise Ultra drivers werdt dit Flush_Cache commando niet naar de schijven doorgestuurt. Echter werken de oudere drivers niet zo lekker met XP (en met grotere schijven, maar dat is nu niet aan de orde)

Elke keer dat de schijven dus 't Flush_Cache commando krijgen, wordt even alle CPU-tijd aan de controller toegewezen, omdat 't dus een hoge prioriteit krijgt. Met alle 'schokkende' gevolgen vandien...


Goed.. Na véél zoeken, vissen, editten, ergeren en installeren, heb ik een (tijdelijke?) oplossing gevonden. (woei )

Maxtor levert in hun retail paketten met ATA133 schijven, ook een promise mee. Nu werken die promise drivers op alle Ultra100/133/TX2000 etc typen (dus ook mensen met een andere Ultra kunnen deze 'oplossing' gebruiken.)

De versie die Maxtor aanbiedt heeft één extra 'feature': Je kan namelijk 't doorsturen van 't Flush_Cache commando naar de schijven uitschakelen. (Je krijgt een extra tabblad bij de eigenschappen van de controller)

Als je die functie uitschakelt, zul je zien dat je systeem niet meer hapert. (mocht die 't toch blijven doen, ligt 't probleem toch ergens anders )


Goed, mijn oplossing:

De Maxtor Ultra controller drivers kan je HIER vinden.

Die kan je installeren met 'Update Driver' bij de eigenschappen van je Ultra. Mocht hij niet automatisch de juiste driver selecteren, of installatie weigeren, dan moet je 'm gewoon handmatig installeren.

reboot -> uitschakelen Flush_Cache commando doorsturen naar schijven -> reboot -> checken of je bak nog hapert

Als 't allemaal prima werkt, zou ik 't zo laten, ik heb zelf echter de drivers weer handmatig 'geupdated' naar de laatste drivers van de Promise site Na 'update' blijft 't extra tabblad gewoon behouden.

Overigens geen verkeerd plan als je eens kijkt of je wel de meest recente BIOS hebt..


NOTE

Ik ben tot nu toe één _ERG_ vervelend probleempje tegengekomen, waarvan ik nog niet uit heb kunnen vogelen of 't aan de BIOS versie van mijn Ultra100 (pdc20265r chip, BIOS versie 2.01.0 build 43) of aan de drivers. (Draai overigens W2K pro SP3)

'T probleem doet zich (voor zover ik weet) alleen voor als ik met Executive software's Diskeeper een zgn 'Boot-Time Defragmentation' doe. 'T resultaat van die handeling is een vern**kte partitie (Gelukkig maak ik iedere dag images van alle partities...) Defragmenteren in Windows zelf gaat probleemloos.

Overigens heb ik sterk 't vermoeden dat 't de Ultra BIOS is... ik ben al eerder meldingen tegengekomen dat die build wat probleempjes geeft. (Toch maar weer een nieuwere versie in m'n BIOS plakken dan )

[Verwijderd]

oh wow, dat zijn pas antwoorden

ik ga het proberen als ik thuis ben.
ja ik had de nieuwste bios van de Promise site geflash (2.20.0.14) .

Edit: ze hebben sinds vandaag weer nieuwe biosen en drivers op hun site staan
http://www.promise.com/su...Id=87&category=All&os=100

deze drivers (2.00.0.42) fixen volgens hun:
- Fixed burst data transfer rate performance issue
- Add support for Windows 2003 Server

ik heb sterk het vermoeden dat alles nu toch weer goed komt.....
zijn deze nieuwe drivers overigens niet dezelfde als die van Maxtor (2.0.0050.42)?

hoop dat dit de oplossing is. Vanuit een andere opzicht vindt ik het HEEEEEL vreemd waarom Promise een driver uitbrengt dat niet goed werkt in W2K-SP3/WinXP. Ik bedoel ze kunnen toch wel in XP testen en zo doende zien dat hun drivers niet werken (met de flush functie).
Ook is het erg stom dat je op de Promise site zelf niks kan vinden over zulke problemen. hoelang bestaan die kaarten al en nu pas met fixed drivers uitkomen

jullie horen het nog van me.

[ Voor 6% gewijzigd door Verwijderd op 08-05-2003 10:41 ]

[Vorlon]

Verwijderd schreef op 08 mei 2003 @ 10:31:
oh wow, dat zijn pas antwoorden

...heel verhaal...

jullie horen het nog van me.

en? al wat getest?

ik was namelijk van plan om ook een ultra100 of 133 te halen. En aangezien ik ook een Epox 8RDA+ heb ben ik wel benieuwd naar de resultaten.

Of kan ik beter een andere controller kopen? Het is alleen maar voor een udma4 schijfje dus zo heel snel hoeft het niet te zijn. (De ultra100 is goed te krijgen en niet duur.)

[Verwijderd]

Probleem is opgelost met driver: 2.00.0.24 en BIOS: 2.20.0.15

Zoals HedKandi al eerder in deze topic heeft uitgelegd, lag het aan de 'Flush_Cache' commando, die nu standaard uitgezet is in driver 2.00.0.24 van Promise.

Vorlon schreef op 09 May 2003 @ 16:22:
[...]


en? al wat getest?

ik was namelijk van plan om ook een ultra100 of 133 te halen. En aangezien ik ook een Epox 8RDA+ heb ben ik wel benieuwd naar de resultaten.

Of kan ik beter een andere controller kopen? Het is alleen maar voor een udma4 schijfje dus zo heel snel hoeft het niet te zijn. (De ultra100 is goed te krijgen en niet duur.)

je kan gewoon de Promise ultra100/133 gerust kopen want het werkt perfect in mijn 8rda+ nu. Ik heb 4 schijven eraan gehangen en ze worden supersnel gedetecteerd, dit heb ik anders ervaren met een highpoint controller.
en ook iets wat het overwegen waard maakt, is een CPU usage van 5-7%.