Hoofdcategorieën

VIA engineer verklaart PCI bus problemen

Door Bram Kouwenberg, donderdag 6 juni 2002 13:15
Bron: Tech Report, views: 732

VIA heeft de oorzaak van één van de problemen met hun vroegere chipsets geopenbaard, zo schrijft Tech Report. Op de Computex-beurs deed een ingenieur van het bedrijf tegenover de pers uit de doeken dat de south bridge chips niet beschikten over een PCI-extensie genaamd 'bus parking', een standaard die ontwikkeld was door Intel. Omdat veel fabrikanten van PCI-kaarten er vanuit gingen dat men gebruik kon maken van bus parking, konden er problemen ontstaan, waarvan het euvel met de Creative Soundblaster het meest bekend is:

Via logo (klein) Many PCI card makers simply assumed bus parking would be available to them, and when it wasn't, all heck broke loose. snap, crackle, pop on your SoundBlaster. That's what I hear, anyway. Driver patches seem to have resolved the worst of the problems for most folks, but PCI card makers have to play along in order to resolve such issues.

VIA claims its newer south bridge chips, especially the 8235 chip showing up in P4X333 and KT400 prototype boards, do not suffer from this problem. The new PCI bus, they claim, performs like a champ. We'll test that theory ourselves soon.
Volgende 14:26
Vorige 05:06

Reacties

«  1  2  3  4  »

Dat verklaard al een heleboel. Veel problemen gelezen met die soundblaster.

Laat VIA maar eerst eens de PCI latency timing glitches oplossen voordat ze in de sound markt gaan.
Die is echt SOEP. Kraken bij het leven.

Wordt dit door de heren van VIA bevestigd. |:( (sukkels)

Maar dit geldt niet alleen voor de soundblaster, dit geldt ook voor de muziek makende gebruikers onder ons EMAGIC AUDIOWERK 8 kaart, waarbij je fijne extra kraken krijgt als je tijdens een muziek productie iets wilt opnemen in je sequencer.

Kortom de consument is de lul en je kan er niets tegen doen. (behalven het feit dat men VIA gaat boycotten)

:)

mm, niemand schijnt mijn mening te mogen, en daar heb ik schijt aan. Ik heb toch gelijk, kan mijn rug op.
HAHAHA losers 8-)

men gaat VIA helemaal niet boycotten... ik niet in iedergeval...
maar ehh, heb je een linkje of wat meer info over de problemen met de Audiowerk 8? daar wil ik wel wat over lezen

ik ben dat eeuwige gelul over dat je er niets tegen kan doen behoorlijk zat (no flame intended)

er is ook zoiets als een pci latency patch. en wie zegt dat VIA een licentie heeft gekregen van Intel om die standaard te gebruiken? Je moet even verder kijken dan je neus lang is, want VIA ligt al met Intel in de klins dus het zou me niets verbazen dat ze geen licentie hebben gekregen.

Ik heb net even de definitie van Busparking volgens de PCI standaard bekeken en het gebruik van BusParking scheelt slechts 1 clockcycle met gewoon gebruik... Dit verhaal lijkt me dan ook een geval van klok hebben horen luiden.... Het lijkt me zeer stug dat het iets uitmaakt.


/edit
zie ook:
http://www.ebookstech.com/samples/LLH/PCIBDsamp.pdf
pagina 26 => Bus Parking
eind edit/


Heb jij het bovenstaande stukje dan gelezen???
lees eerst eens
http://www.ebookstech.com/samples/LLH/PCIBDsamp.pdf pagina 26 en kom dan eens met tegenargumenten!

BozoQed: Het probleem is dat de kaart er van uit gaat dat ie geparked is en dus nalaat een REQ# te doen.

Dit veroorzaakt een leuk geluidje op je Sound Blaster (of een andere nadelig effect op een andere kaart).

Dit laatste lijkt me eerder een probleem van b.v. het soundblaster board en niet van de VIA.... Bovendien kunnen andere kaarten of zelfs de VIA het in enkele cycles overnemen dit zou geen hoorbaar effect mogen hebben. Indien tijdens dma transfer nooit een request van de soundblaster zou komen zou je helemaal niets horen lijkt me... Vergeet niet dat een audio kanaal slechts een frequentie heeft van 44kHz en de PCI bus over een capaciteit beschikt die meer dan een veelvoud hiervan is. Tijd genoeg om bus problemen op te lossen zonder dat je het kan horen (time-outs e.d.). Het is mij nog steeds niet duidelijk hoe de combinatie Bus Parking / VIA de oorzaak van de problemen is.

Jij maakt nu allemaal aannames die niet waar zijn: De busfrequentie (bandbreedte) van PCI doet er niet toe, noch DMA-transfers, noch iets anders.

Het probleem met de SB!Live is zéér simpel te verklaren:

De kaart gaat er vanuit dat ie aan bus-parking kan doen, terwijl de bus zelf (PCI) de kaart niet in bus-parking zet.

Kortom: De kaart en de bus zijn het dus tijdelijk niet eens over de status van de kaart. en moeten opnieuw syncen. Er is destijds afgesproken dat dan de kaart z'n status aanpast aan de bus, om te voorkomen dat anders andere kaarten uit sync raken met de bus en je dus in een loop terecht kunt komen.

Daardoor moet de SB!Live tijdelijk eventjes vanuit een semi-ongedefinieerde status terugkomen naar een defined-state. Gedurende deze transition-phase doet de kaart niks anders dan garbage produceren en kun je em dus ook niet aanspreken.

Gevolg: Hickups, stotteringen, tikjes e.d. totdat de kaart en PCI-bus weer 100% in sync zijn en dan kan de boel weer goed doorlopen.

In sync bedoel ik mee: Alle status-registers die van belang zijn voor de PCI-bus zijn zowel bij de PCI-controller als bij de kaart bekend en gelijk. Heeft dus ook niks met een evt. CLK signaal te maken.

Bekijk het als een simpele DSP: Op het moment dat je een DSP een RST geeft, is ie volledig van slag en doet ie er, afhankelijk van het type 100-2000 kloktikken over om in een 'defined state' te komen. Gedurende die tijd moet je een DSP ook niet aanspreken of beluisteren: Alles wordt ge-garbled.

In theorie (en dat wordt in fault-tolerance apparaten ook gebruikt) kun je dit probleem omzeilen door het gebruik van een (grote) buffer die los-staat van de PCI-bus interface + een IC dat alle informatie controleert op echtheid via bv. CRC en eventueel een request kan doen om data opnieuw te ontvangen.

Omdat een geluidskaart echter niet fault-tolerant hoeft te zijn, wordt dat niet gedaan. Het zou een kaart onnodig duur maken. Bovendien is PCI daar in beginsel nooit voor ontworpen.

- per ongeluk 2x geklikt, mod deze maar weg -

--edit--

dus toch geen via probleem...

Gevolg: Hickups, stotteringen, tikjes e.d. totdat de kaart en PCI-bus weer 100% in sync zijn en dan kan de boel weer goed doorlopen.

en daarna loopt hij weer vast neem ik aan omdat Bus Parking niet werkt ... dan gaat hij weer in sync etc...
het lijkt me dat dit helemaal niet zou kunnen werken...

en is er er nu al een universele officiele ALTIJD werkende oplossing?

of kan dit probleem gewoon NIET universeel opgelost worden door een fout in de hardware? (hoor ik daar RMA?)


Hierboven staat dat de p4x333 en de kt400 er geen last meer van hebben dus via is aan de beterende hand (moet ook wel als je dit niuews gaat uitbrengen, win je niet echt vertrouwen mee)

Uiteraard. Maar een andere oplossing dan de PCI-Latencypatch is er dus niet voor huidige VIA-chipsetmoederbordbezitters (<- leuk woord voor galgje). En zeker geen een die 'officieel ALTIJD' werkt, behalve dan dus een ander mobo kopen.

het gaat hier over de south bridges, jij hebt het over north bridges....

het gaat hier over de south bridges, jij hebt het over north bridges...

Niet dus. Ordos20 heeft het over de KT400. KT400 is de benaming voor de hele chipset, dus north- én southbridge.... vaak wordt de laatste tijd (niet helemaal terecht) de naam van de chipset ook voor de northbridge gebruikt.

Waarom hebben ze niet aan "bus-parking" gedaan? was dit om kosten te besparen? of is het per ongeluk over het hoofd gezien?

Zoals al in het artikel staat, het is een PCI extensie. Dit is dus een uitbreiding op de PCI standaard, en valt zelf niet binnen deze standaard.
VIA heeft zich dus netjes aan de standaard gehouden, maar kaartenbouwers ging er van uit dat iedereen deze Intel feature wel zou overnemen.
Overigens, deze extensie is pas na de befaamde Intel BX chipset geintroduceerd (BX was het 'super overklokkers' bord, omdat je hier stabiel met een FSB van 133 op konwerken terwijl Intel officieel alleen nog maar 100 Mhz ondersteunde), dus mogelijk zijn er ook andere mensen geweest met oude mobo's die dezelfde problemen hebben gehad met hun Intel chipsets.

Wat raar dat niemand met een SB Live dan problemen heeft met een BX chipset!

Wat raar dat niemand met een SB Live dan problemen heeft met een BX chipset!
je moet die bx lezen als een 440bx geloof ik. en hoezo raar dan? VIA legt uit dat zij problemen hadden de BX (intel) niet... volgens mij was je gedachengang niet helemaal recht

Die zijn er wel degelijk wel - dat probleem heeft een vriend van me gehad met zijn BX mobotje.

een persoon met een probleempje is nog geen bug ;)
het enige probleem waar ik van heb gehoord was dat de SB Live kaarten nog al wat problemen hadden met sharede IRQs en dat dat nogal veel voor kwam als mensen niet opletten in welk PCI slot ze hem stoken...
(zelf mee gemaakt met m'n BE6-II) menselijke error

Met Intel SE 440 BX/2 ben ik het probleem nooit tegengekomen.

Met Intel SE 440 BX/2 ben ik het probleem nooit tegengekomen.
Ik ook niet met m'n VIA 694 chipset (zou zo'n probleemgeval moeten zijn).
Niet met de SB Live! Value die er eerst in zat, en ook niet met de Audigy Platinum die ik nu gebruik.

extensie staat voor iets verlengen... dus als het een pci extensie is dan betekent het dat het een verlenging op de pci standaard is. dus er is een pci standaard waar via aan voldoet... maar die extensie wordt dus niet ondersteund. fout ligt dus niet bij via....

het feit dat de sblive het onder linux wel goed doet geeft ook meteen aan dat het een driver issue is en dat het gewoon opgelost kan worden. (er is dus gen sprake van hardware matig niet op te lossen)

verder is het zo dat alle pci apparaten backward compatible moeten zijn met versie 1 dus hij mag wel alles ondersteunen van de laatste versie maar dat moet dus niet ten koste gaan van backward compatibiliteit.

vergelijk het maar met processoren. hij mag meer ondersteunen (mmx,sse,sse2,etc.)maar hij moet de oudere software kunnen draaien.

fout blijft dus nog altijd bij creative niet bij via... heel lullig en ik ben ook niet pro via maar zo liggen de feiten.

dat creative weigert het op te lossen geeft al aan met wat voor een bedrijf je te maken hebt (immers hoezo valt het wel onder linux op te lossen maar niet onder windows?

Stel dat dit waar is, is dit dan niet indirect een fout van Intel. Of hebben zij de PCI standaard uitgevonden, en mogen ze die zelf ook zo aanpassen?

Lijk me dus niet.

Het probleem zit hem er juist in, dat een aantal hardware-makers ( zoals Creative in dit geval ) er klakkeloos vanuit ging dat iedere chipsetbakker deze extra ( niet binnen de PCI standaard vallende ) feature zou inbouwen. Nu maakt de SB Live dus gebruik van een niet aanwezige PCI extentie die er niet is in het geval van VIA chipsets.

En Via is er van uitgegaan dat de hardwarefabrikanten die extensie niet zouden gebruiken - terwijl ze wel wisten van het bestaan van die extensie.
Er is m.i. niet een enkele schuldige aan te wijzen, maar ik zou denken dat Via als chipsetfabrikant hier wel veel verantwoordelijkheid draagt.

..als Via nou bvb zelf ook soundcards zou maken, zouden ze dan wel hebben stilgestaan bij die extensie?

Nu hebben ze het -of- helemaal niet in de gaten gehad, -of- ze hebben gedacht dat het niet belangrijk was.... in dat laatste geval hadden ze het ff kunnen checken. Als ze het gewoon niet in de gaten hebben gehad... nou ja, dan kunnen we misschien nog meer van dit soort fraais verwachten.

Nu hebben ze het -of- helemaal niet in de gaten gehad, -of- ze hebben gedacht dat het niet belangrijk was.... in dat laatste geval hadden ze het ff kunnen checken.
OF (en dit is waarschijnlijk zo) ze hebben het prima in de gaten gehad, hebben een weloverwogen kosten/baten analyse gedaan, en hebben beseft dat het niet implementeren van deze feature niet ten koste zou gaan van de standards-compliance van de chipset.

Iets dergelijks hadden we hier ook: een clock-functie hoeft een OS volgens ANSI niet te implementeren, als die dan maar '-1' teruggeeft als klokwaarde.
VxWorks is er dus zo eentje :( die het dan maar niet heeft geimplementeerd :(

Zoals hierboven al genoemd, moeten alle PCI-kaarten wel compatible zijn met versie 1. Anders zou je op een gegeven moment bijvoorbeeld geen nieuwe geluidskaart meer in je wat oudere PC kunnen zetten, wegens gebrek aan features.

Lullig........ :'(

Volgens mij ligt de fout dus wel degelijk bij Creative.

Is het niet zo dat dan de chips niet voldeden aan het PCI reference design (of hoe dat ook mag heten), ik bedoel hier moet toch ook een standaard voor zijn?

Of heeft intel iets verzonnen voor zijn eigen chips en gaan veel fabrikanten van er van uit dat alle chips dit wel hebben?

Leuk dat ze dat ff vertellen, als je op het punt staat om alweer een nieuwe comp aan te schaffen

Dus het probleem ligt idd bij VIA, Wat een ........

Maar het lost natuurlijk niks op. Wat kunnen we nu doen om deze problemen te laten verdwijnen??

Naar mijn idee is het dus een hardware fout. Dit is dus niet op telossen met drivers etc etc.

Dit word dus nu een nieuw mobo kopen :( :(

Waarom ligt het bij Via als pci kaart fabrikanten ervan uitgaan dat er een extrensie van de standaard zal zijn wat vervolgens niet zo blijkt te zijn?

Dan hebben die pci-kaartenmakers gewoon niet de officiele spec gevolgd.
Dus hun schuld.
Helaas is vervolgens de klant de dupe, maar dat is niks nieuws.

Ok, probleem gevonden..

Maar.....
PCI Bus parking.. is dat een eis van de PCI standaard???

of is dat een extra iets, wat men aanneemt dat iedereen dat ondersteunt??


In het 1e geval: Dat zit VIA fout, ze hebben zich dan niet aan de standaard gehouden.

In het 2e geval is het de fout van (bv) creative... door gebruik te maken van extra (niet-standaard) instructies....

Edit: shit he, ff tig posts alweer hierboven... naja, zal alwel een dubbelpost geworden zijn.. men is hier ook zo fucking snel met reageren :)

PCI-extensie genaamd 'bus parking', een standaard die ontwikkeld was door Intel.

Tis dus een std extensie.. een SB-Live doet het namelijk ook al in hele oude PCI mobo's, dus dat kan het ook niet zijn. Via is gewoon vergeten die extensie, die dus in de standaard zit, mee te nemen in het ontwerp. Heeft toen gedacht, who cares, tot dat iedereen last kreeg. Daarna leek Creative de boe-man, terwijl Via uiteindelijk de whole blame hoort te krijgen. (los van andere Creative-problemen natuurlijk).

Nee, geen standaard extensie oftewel eens extensie die er standaard bij hoort, want als het er standaard bij zou horen was het geen extensie maar juist standaard!
Intel heeft alleen zoiets bedacht en dan moet iedereen maar volgen want PCI kaartmakers gaan gewoon die extra Intel dingen gebruiken terwijl da NIET de standaard is!

Mischien heeft het iets temaken met licenties :? In het bricht staat dat "bus parking" door Intel is ontworpen. Mischien was het voor VIA te duur om voor die functie te betalen. En omdat die functie niet zo belangrijk was hebben ze hem er uit gelaten. Dat zou ze weer een boel geld besparen :Y)

Nee, want het is een extensie van de standaard en die is vrij implementeerbaar.

Op de Computex-beurs deed een ingenieur van het bedrijf tegenover de pers uit de doeken dat de south bridge chips niet beschikten over een PCI-extensie genaamd 'bus parking', een standaard die ontwikkeld was door Intel.
Die VIA borden hebben dus een niet PCI-gestandardiseerde PCI controller op het mobo zitten. Dus eigenlijk is het niet eens pci, of in ieder geval geen complete pci. Nu ben ik misschien een beetje vreemd aan het denken, maar is het dan niet zo dat de schuld dus uiteindelijk niet bij Creative lag, maar bij Via. En dat Via dus eigenlijk schuld had moeten bekennen voordat Creative in een kwaad daglicht kwam te staan? Is het dan ook niet zo dat Creative nu Via gaat aanklagen wegens smaad en daardoor gemiste inkomsten?

Beetje typisch om dit nu een jaar na dato te melden.. misschien kan ie erbij vertellen waarom Via's pci bus ook zo langzaam is vergeleken met concurrerende chipset's.. was dat ook weer een misser in het ontwerp?

Ik heb een via kt266a zonder live problemen, maar dit valt me tegen van Via.

Mijn Abit KR7A-Raid (KT266a) werkt ook prima met mijn SB Live! Value (een oude).

Snap de volgende zin ook niet:
"VIA claims its newer south bridge chips, especially the 8235 chip showing up in P4X333 and KT400 prototype boards, do not suffer from this problem."

Dat is tot raar :? kunnen ze niet gewoon een lijstje uitgeven welke chipset nu wel 'bus parking' ondersteund ? Lekker vaag om te praten over "do not suffer from this problem' zeg dan gewoon 'PCI bus-parking ready' o.i.d. Bijft vaag... jammer !!

Sterker nog, ik met mijn KT7 (KT133) had ook geen problemen met de Live.
Echter wel met me SCSI, TV kaart... :(
Ben dagen bezig geweest dat hele spulletje stabiel te krijgen, blijkt het dus gewoon een bug in het chipset... Erg kwalijk dit, geen Via meer voor mij.

Zoiets hadden ze eerder bekend moeten maken.Tevens waren, lijkt me, de mobo-fabrikanten ook wel op de hoogte, tenminste ik mag aannemen dat ze een nieuwe plank eerst testen...

Sja... gelukkig heb ik nu een P4 plank (i850) alles heeft nog nooit zo goed gewerkt :)

Als je de tekst goed leest, dan kun je er uithalen dat de extentie niet binnen de standaard specificaties van PCI valt. Dus VIA heeft wel netjes volgens de standaard gewerkt. De door Intel ontwikkelde 'extentie' ( lees uitbreiding !! ) valt hier dus buiten.

Ik vind een hapje uit de bovenstaande tekst ook niet helemaal 'eerlijk'. Want er staat
.... beschikten over een PCI-extensie genaamd 'bus parking', een standaard die ontwikkeld was door Intel.
Nu heb ik de specs van PCI niet gelezen hoor, maar bovenstaand is nogal tegenstrijdig. Ik krijg in ieder geval de indruk, dat extentie en standaard hier nogal door elkaar worden gegooid. Is het nou een extentie ( uitbreiding op de standaard ) of een standaard ?

Probleem is, dat er door dergelijk interpreatie verschillen, mensen zitten met niet goed werkende hardware configs. Zij moeten dus of aan een ander MoBo, of aan een andere geluidskaart. Nu is dus grote gedupeerde de eindgebruiker :(

Het krakende geluid bij soundblaster PCI kaarten doet zich ook voor bij sommige systemen met een Intel chipset. Dit betekent dat er waarschijnlijk meerdere oorzaken een rol spelen.

Ja, dit betekend ook niet dat Creative helemaal gevrijwaard is van crap-drivers. Al is het dus wel zo dat een groot deel van de problemen waar je het meeste last van hebt/had dus niet door Creative kwam. De naam van Creative is voorgoed omgezet in een soort debiele-driver/briljante-geluidskaart fabricant.

Ik denk zomaar dat Via niet wilde dat iedereen dit wist, anders kom je er niet een jaar na dato mee, terwijl Creative nu best nog wel es dwars kan gaan doen.

Tja helemaal mee eens, die geluidskaarten zijn goed van design, maar ow wee die driverbugs. Heb nu een Audigy en die kaart = perfect !! maar weer die domme drivers en jeee die mixer word ook steeds minder van Soundblaffer. Je kunt niet eens meer een annaloge opname channel kiezen omdat je dan ook een output channel van een analoge channel moet open zetten (lekker hoor die feetbacks ! ).
«  1  2  3  4  »

Op dit item kan niet meer gereageerd worden.

Volgende 14:26
Vorige 05:06
VNU Media logo Powered by True

© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden

Uitgever van: