kocenje lucenta i kako to prevazici

[spree82]

zasto se svaki put kompjuter ukoci pri inicijalizovanju i biranju broja modema .......Lucent winmodem je u pitanju, win98/xp, epox, via kt133 maticna, 128ram, 1GHz Tbird, KAKO DA SE RESIM TOGA?

unapred hvala

 

[JoeKuboj]

zasto se svaki put kompjuter ukoci pri inicijalizovanju i biranju broja modema .......Lucent winmodem je u pitanju, win98/xp, epox, via kt133 maticna, 128ram, 1GHz Tbird, KAKO DA SE RESIM TOGA?

unapred hvala

kupi externi modem koji je 101% hardwerski
ili neki rockwell 33,6 ISA ako imas ISA slot...a verovatno nemas

 

[DusaN]

Instaliraj Linux

 

[gojkos]

Jel' ovo rade svi PCI modemi ili je to samo Lucentov feature? A jel' ima neko ideju ZASTO to rade? Moj lucent je kao HW, gledao sam ranije po chipsetu. Al' svejedno i da je softverski. Mislim, ocigledno je da drajver za modem zaledi ceo komp, cak i ostale drajvere (ne samo user level aplikacije)! Pa ne mogu da verujem da mu treba max prioritet samo da bi prekinuo vezu ctp;. I sam sam pravio neke drajvere (doduse VxD) i znam da sve to moze sasvim lepo da se uradi i kad uredjaju treba precizan tajming.

Ja pretpostavljam da je to namerno ugradjeno da bi neko kupio i skuplje (eksterne) modele ;-)

 

[gojkos]

Instaliraj Linux

Pod linuxom ne secka? Onda su definitivno sugavo uradjeni drajveri FX. A moguce je i da je MS kriv jer se drajveri za comm/modem naslanjaju dosta na vec postojece MS-ove FX

 

[mikis]

Interesantno je da recimo WinAmp 2.x secka kad se uspostavlja/prekida veza, dok WinAmp 3 ne secka! Ima li neko ideju kako naterati i stari WinAmp da ne prekida, bar dok trojku ne srede kako valja.

BTW, svi PCI Lucenti su softverski, bas kao i Rockwell/Conexant, Motorola, PCTel i slicno djubre. Kol'ko se secam neke price, Lucent ipak nije 100% softverski, tj. nedostaje mu neki kontroler ili tako nesto za uspostavljanje i prekidanje veze, pa zato i on secka. Ima cak i eksternih USB modema koji seckaju!

A sve je to napravljeno da bi OEM-i ustedeli 2-3 centa na svakoj prodatoj konfiguraciji...

 

[silverglider]

Problem sa winampom se prevazilazi tako sto se poveca buffer u output pluginu koji koristis.

Skoro sve funkciije modema mogu da se urade softverski - moze jedan obican DSP cip da se programira da simulira modem ili zvucnu ili nesto trece. Kod tih "softverskih" i "shatro-hardverskih" modema je samo pitanje sta ce da implementiraju kroz cipove, a sta kroz drajvere. Generalno, postoje dve grupacije funkcija kod takvih modema; jedna je modem-control, a druga je data-transfer funkcije modema. U zavisnosti od toga sta ko radi, postoje dve grupacije PCI modema:
- tzv. softverski: obe grupacije radi softver
- tzv. windows i RPI (rockwell protocol interface): modem-control radi softver, datapump funkcije radi hardver
Trecu grupaciju cine modemi koji imaju sve implementirano kroz hardver, kao sto su neki USR PCI modemi.

Zasto ti PCI modemi hoce da blokiraju masinu ? Zbog UART-a (Universal Asynchronous Receiver-Transmitter). Putem UART-a serijski uredjaji (samim tim i modemi) komuniciraju sa racunarom. Sami UART cipovi su relativno zastareli, ogranicenog kapaciteta (115.200), itd. Prelaskom sa ISA na PCI bus, UARTovi su vecinom prestali da se ugradjuju, zbog svoje 'prirode'. No, posto se gomila komunikacionog softvera oslanja na UARTove, u PCI modeme se ugradjuju kola koja ih emuliraju. Zbog svoje gradje, UARTovi su se do sada oslanjali na odredjenu organizaciju PIC-a (programmable interrupt controller), te su mogli da 'dohvate' samo niske interapte (0-7, teoretski). Posto su PCI uredjaju po PICu orijentisani na visoke interapt linije (8-15), potreban je drajver u dva dela - jedan mora da "mapira" te zahteve da bi se UART normalno emulirao. medjutim, posto imamo mapiranje i emulaciju, u trenutku kada to kolo koje emulira UART obezbedjuje FIFO bafere, dolazi do tog prekida. Eksterni serijski modem koristi pravi UART koji je ugradjen u serijski port na ploci, te nema tog mapiranja, a samim tim ni takvih problema. Osim ukoliko se (kod serijalca) opet ne koristi nesto za emulaciju UARTa, mada je to stvarno retko. Takodje, dobri i skupi PCI modemi koji ne prave takve probleme imaju takodje na sebi ugradjen "pravi" UART.

 

[gojkos]

//
Problem sa winampom se prevazilazi tako sto se poveca buffer u output pluginu koji koristis.
//
Ne moze, probao ja Probao sam (u WinAmpu 2.7) da menjam podesavanja za DirectSound/WaveOut. Menjao sam velicinu i broj buffer-a, prioritet programa itd. ali nista nisam postigao. Apsolutno uvek isto secka. Tako da sam zakljucio da se blokada vrsi na nizem nivou. Sam drajver za zvucnu je blokiran (mada moze biti i multimedia core ili DirectX core) i ne stize da salje buffer-e hardware-u tako da se javlja sitno seckanje. Da je blokiran samo WinAmp, onda bi buffer >2s resio problem.
Ali ako WA 3.x radi OK onda nista vise ne znam.

//
potreban je drajver u dva dela - jedan mora da "mapira" te zahteve da bi se UART normalno emulirao. medjutim, posto imamo mapiranje i emulaciju, u trenutku kada to kolo koje emulira UART obezbedjuje FIFO bafere, dolazi do tog prekida
//

Ovde sam te negde izgubio. Poznato mi je programiranje UART-a i PIC-a. OK, UART mora da se emulira, drugim recima, softverski se emulira COMM port tako da sistemu izgleda kao pravi (IRQ i i/o adresa). Drajver se brine o tome da podize interapte za RI, DCD itd. Ali opet mi nije jasno zasto mora da zaledi masinu!? Posto se pod windows-om sav hadver virtualizuje, nijedna aplikacija nema direktan pristup hardveru, vec se in/out instrukcije hvataju i prosledjuju drajveru zaduzenom za taj uredjaj. Dakle, u windows-u je lako napraviti virtualni COMM port, virtaelni disk ili virtualno bilo sta vec. To nije razlog. Jedini razlog moze da bude da je drajveru potrebno da neko duze vreme radi polling tj. da neprekidno cita(ili salje) nesto na hardver, al' ne vidim sta bi to radio samo kad prekida vezu. Verovatno mi nesto promice ovde...

 

[silverglider]

U windowsu je lako napraviti virtuelni port, ali ovde se ne radi o tome - ne emulira se comm port i to kompletno softverski u windowsu, nego imas el.kolo koje emulira UART i to lose. Blokada dolazi u trenutku kada se rezervisu i stave na raspolaganje/osllobadjaju FIFO baferi (in & out). To je "zvanicno" objasnjenje koje moze da se nadje na netu vrlo lako i proveri - samo sto ljude mrzi.

Takva blokada ne moze da se desi zbog neprekidnog citanja/pisanja na hardver - jer taj 'komunikacioni' cip koji imas na modemu nema definitivno takav propusni opseg da bi zakrcio PCI-ovih 133MB/s -> jedan IDE ATA-100 kontroler to ne moze da uradi. Ako bi zakrcio svoj propusni opseg (115.200), onda bi blokirao samo sebe, ne i ostalo.

 

[gojkos]

Ma znao sam ja da je to neki fusheraj . Uzeo sam najgori slucaj da je sve softverski emulirano, jer ni onda nista ne bi smelo da secka. A oni su stavili chip i to los . OK, salim se, taj cip sigurno rasterecuje CPU, a sto nije idealan verovatno i za to postoji realan razlog (da se ustedi koji $ ).

Nisam mislio da blokada nastupa zbog zagusenja PCI magistrale, nego ako je drajveru potrebno da odredjeni period PRATI nekakav port. Kad drajver dobije kontrolu onda on ima masinu za sebe. On bi onda trebao da sto brze odradi sta ima i da vrati kontrolu windowsu. Medjutim, posto nije sigurno kad ce sledeci put dobiti svojih 5 minuta (tj milisec ), drajver moze da odluci da ne vraca uopste kontrolu windows-u dok ne zavrsi svoj posao. I zato sve stane.

Anyway, hvala na objasnjenju i informacijama, ima tu nesto.

 

[silverglider]

... taj cip sigurno rasterecuje CPU, a sto nije idealan verovatno i za to postoji realan razlog (da se ustedi koji $ ).

Rasterecenje ovde nije u pitanju, razlog sam vec pomenuo - softver. Dosta softvera (bilo kompletnih programa, bilo komunkacionih biblioteka) pokusava da ocita UART kao hardver - tu nije bilo druge, nego je moralo hardverski. Tesko da mozes da izbacis neko parce hardvera i odjednom pola softvera ne radi Ta velika baza postojeceg softvera je i blagoslov i prokletstvo.

Nisam mislio da blokada nastupa zbog zagusenja PCI magistrale, nego ako je drajveru potrebno da odredjeni period PRATI nekakav port. Kad drajver dobije kontrolu onda on ima masinu za sebe. On bi onda trebao da sto brze odradi sta ima i da vrati kontrolu windowsu. Medjutim, posto nije sigurno kad ce sledeci put dobiti svojih 5 minuta (tj milisec ), drajver moze da odluci da ne vraca uopste kontrolu windows-u dok ne zavrsi svoj posao. I zato sve stane.

Hm da, ali drajver ne upravlja celim sistemom da bi ga on blokirao. Kernel upravlja drajverima, a sam kernel slusa interapt kontroler da bi mogao da deli CPU time izmedju vise procesa - i samih drajvera. Sistem je napravljen tako da tajming interapt kontrolera zavisi i od komunikacije NorthBridgea i SouthBrigdea - na kojem lezi PCI Bridge, kao host tom kontroleru. Dakle, interapt kontroler ne sme da dozvoli (hardverski) da jedan uredjaj 'zatrpa' propusni opseg busa (u ovom slucaju PCI), pa ce zato nakon kratkog intervala dati i drugim uredjajima da kazu svoje i okinuti interapt; tada kernel stopira doticni drajver i daje sansu drugome da obavi svoj posao.
Ako se i nekada desi greska koju je prouzrokovao drajver (BSOD), to je zbog kilavo napisanog kernela, koji bi morao da se snadje u tom trenutku i odrzi kontrolu nad sistemom. Ukratko, tu je neki drugi OS jaci.

 

[gojkos]

Rasterecenje ovde nije u pitanju, razlog sam vec pomenuo - softver. Dosta softvera (bilo kompletnih programa, bilo komunkacionih biblioteka) pokusava da ocita UART kao hardver - tu nije bilo druge, nego je moralo hardverski. Tesko da mozes da izbacis neko parce hardvera i odjednom pola softvera ne radi Ta velika baza postojeceg softvera je i blagoslov i prokletstvo.

Pa zar se nismo slozili da je port/uredjaj lako (ili da kazem sasvim moguce) emulirati potpuno softverski tako da ga sav softver vidi kao pravi?
Naravno, govorim o windows-u i eventualno DOS prompt-u. Pod pravim DOS-om ionako nijedan WinModem nece raditi upravo zato jer ne postoji drajver da emulira UART, a koji za DOS nije ni moguce napraviti AFAIN.

Hm da, ali drajver ne upravlja celim sistemom da bi ga on blokirao. Kernel upravlja drajverima, a sam kernel slusa interapt kontroler da bi mogao da deli CPU time izmedju vise procesa - i samih drajvera. Sistem je napravljen tako da tajming interapt kontrolera zavisi i od komunikacije NorthBridgea i SouthBrigdea - na kojem lezi PCI Bridge, kao host tom kontroleru. Dakle, interapt kontroler ne sme da dozvoli (hardverski) da jedan uredjaj 'zatrpa' propusni opseg busa (u ovom slucaju PCI), pa ce zato nakon kratkog intervala dati i drugim uredjajima da kazu svoje i okinuti interapt; tada kernel stopira doticni drajver i daje sansu drugome da obavi svoj posao.
Ako se i nekada desi greska koju je prouzrokovao drajver (BSOD), to je zbog kilavo napisanog kernela, koji bi morao da se snadje u tom trenutku i odrzi kontrolu nad sistemom. Ukratko, tu je neki drugi OS jaci.

Prvo, da, realno bi trebalo da bude tako, ali prakticno sam se uverio da drajveri mogu vrlo efikasno da zalede masinu ako upadnu u neku mrtvu petlju pri servisiranju callback-ova (zasto je to tako, nisam dublje ulazio u to). I da se ogranicim na VxD drajvere i Win9x. Nisam siguran za NT-based sisteme, odnosno, NT kernel mode drajvere i WDM (Windows Driver Model) drajvere, ali ocigledno je, cim se dogadjaju ovakve stvari (seckanje misa), da bar mogu da uzmu max prioritet i da pojedu vreme ostalim procesima.

Drugo, ako se npr u interrupt handler-u uradi jedan CLI, tj. zabrane interrupti, tu je kraj price - nema vise ni jednog interrupt-a, totalni freeze systema.

A BSOD nije uopste tako strasna stvar To je jedini nacin da drajver izbaci neku poruku korisniku. Ako ima nesto da kaze drajver pozove sasvim legalan VMM service, posalje string i to se ispise na plavom ekranu ( BSOD). Ja sam to koristio za debagiranje, znaci ispise nesto kao "Sad sam tu i tu, otvaram handle..." Naravno, drajver ne treba da prica mnogo i ovaj vid "komunikacije" sa korisnikom se koristi retko - samo kad je nesto bas zapelo i zato je, hm, "nepopularan"

 

[silverglider]

Pa zar se nismo slozili da je port/uredjaj lako (ili da kazem sasvim moguce) emulirati potpuno softverski tako da ga sav softver vidi kao pravi?
Naravno, govorim o windows-u i eventualno DOS prompt-u. Pod pravim DOS-om ionako nijedan WinModem nece raditi upravo zato jer ne postoji drajver da emulira UART, a koji za DOS nije ni moguce napraviti AFAIN.

Pa mi smo se manje-vise slozili da je to tehnicki moguce - ali oni ocigledno nisu Da mogu to da odrade sve softverski, na kartici modema ne bi postojao ni jedan chip, nego sam konektor za modemski kabl. Ako je vec moguce sve to uraditi softverski tako glatko, postojao bi drajver i za dos. Naravno, morao bi se napraviti u real86 modu, ali UART valjda nije toliko komplikovana spravica da bi protected mod bio must, right ?

Prvo, da, realno bi trebalo da bude tako, ali prakticno sam se uverio da drajveri mogu vrlo efikasno da zalede masinu ako upadnu u neku mrtvu petlju pri servisiranju callback-ova (zasto je to tako, nisam dublje ulazio u to). I da se ogranicim na VxD drajvere i Win9x. Nisam siguran za NT-based sisteme, odnosno, NT kernel mode drajvere i WDM (Windows Driver Model) drajvere, ali ocigledno je, cim se dogadjaju ovakve stvari (seckanje misa), da bar mogu da uzmu max prioritet i da pojedu vreme ostalim procesima.

Windows kernel ima isti mehanizam (interrupt pool) u ovom slucaju - on proverava interruptID da vidi da li je obrada gotova - ukoliko nije gotova, tj. interrupt handler jos uvek 'radi nesto', kernel ga izdvaja na poseban thread, ocekujuci sledeci event. Drajveri se pisu tako da rade u kernel adresnom prostoru, ne u standardnom aplikacijskom prostoru i tu prioritet threadova ne moze tek tako da se 'zamrlja'. Bar ne bi smeo

Drugo, ako se npr u interrupt handler-u uradi jedan CLI, tj. zabrane interrupti, tu je kraj price - nema vise ni jednog interrupt-a, totalni freeze systema.

Paaa... ne bas. Interapti se dele na tri grupe i jos u njima po prioritetima, tako da interrupt handler moze da blokira samo neke interapte i to samo one nizeg prioriteta od svog (kao i svoj nivo). Uz cinjenicu da se neki interapti ne mogu blokirati. Naravno da drajver ne moze imati vec i prioritet od kernela. Mislim, jesu ovi iz MS-a krelci ponekad, ali nisu toliki Zar bi ti dozvolio da jedna komandica, dostupna svima moze tako da freezuje sve ? To bi bio suvise otvoren sistem da bi bio iole siguran (od unutrasnjih i spoljasnjih uticaja).


Elem, da skratim pricu; ne bih smeo da tvrdim da se to sve moze svesti na problem preuzimanja prioriteta - cak i MS bi mogao to da resi jednim apdejtom na nivou kernela, kao glavnog dispecera. Pre bih rekao da do tih 'excesnih' situacija sa drajverima dolazi zbog nekog buga u samom kernelu - koncept im i nije toliko los (mislim, "njihov" koncept - to je generalni koncept OSova). Stvari do kojih dolazi imaju uzroke i u hardverskoj podlozi - pomenuti bug VIA-e sa PCI latencijom, ili nesto slicno sta se desilo sa i850/860 cipsetovima kod veceg saobracaja na nekom busu - dogadjaji se desavaju u realnom vremenu, bafer (za event queue) je ogranicenog kapaciteta, hardver (ove u primeru implementacija cipseta) okine break, loop se prekine (ili dodje do buffer overflowa) i jedan deo dogadjaja sa hardvera je "popapala maca". Jedan deo hardver (ni to nije savrseno), drugi deo softver.

Odosmo mi od winmodema ...

 

[magick]

Vidim da ste se vi već lepo ispričali i ne zamerite ako ne kažem ništa novo, priznajem da nisam imao živaca da sve detaljno isčitavam.

Kao prvo nisam razumeo suštinu problema. Da li se komp trajno zablokira ili samo u toku biranja? Drugo, problem sa Winamp-om, dok radi bilo šta drugo, je klasičan primer traljavosti VIA čipseta, odnosno njegovog programiranja. Tu mislim na čuveni burst rate PCI magistrale, a rešenje bi mogao da bude onaj VIA-PCI-latency patch.

To takođe miriše na neki konflikt na nivou drajver-čipset ( PIC ), a i Win ima tu svoj udeo, čim tajmer dozvoljava to otimanje resursa. Sve u svemu, teško je to za rešiti, a i besmisleno je toliko se cimati kada pričamo o trošku od desetak 10€, možda ni toliko ako utopiš svoj modem.

Rezime rešenja:

1) probaj prvo softverski, tj druge verzije modemskog drajvera i 4in1

2) promeni modem

3) uzmi ploču sa nForce čipsetom ( mačka u džaku ) ili pređi na Intel platformu, što ne verujem da podrazumevaš pod razumnim rešenjem.

 

[drapin]

Rezime rešenja:

1) probaj prvo softverski, tj druge verzije modemskog drajvera i 4in1

2) promeni modem

3) uzmi ploču sa nForce čipsetom ( mačka u džaku ) ili pređi na Intel platformu, što ne verujem da podrazumevaš pod razumnim rešenjem.

Nema nikakve veze sa platformom, odnosno cipsetom...
Presao sam upravo sa VIA na Intel i modem se apsolutno isto ponasa.

To je jednostavno karakteristika Win modema, mozda ne svih, cak ne ni svih Lucenta - npr. moj stari Lucent od pre dve godine prouzrokuje to zastajkivanje dok jedan noviji takodje no name sa Agere cipom to ne radi.
Inace to nije nista strasno, samo malo nervira ako bas insistirate da radite jos nesto drugo dok modem bira broj...

 

[ZorMi]

To je jednostavno karakteristika Win modema...

Ako je za utehu, isti zastoj postoji i kod ISDN adaptera (Elsa) koji takodje emulira neki COM port...

 

[gojkos]

Pa mi smo se manje-vise slozili da je to tehnicki moguce - ali oni ocigledno nisu Da mogu to da odrade sve softverski, na kartici modema ne bi postojao ni jedan chip, nego sam konektor za modemski kabl.

Uh ti sad ode u extreme pa ne moze telefonska linija direktno da se spoji na PCI magistralu, mora da ima bar ADC/DAC Salu na stranu, verujem da su oni i odradili sto god vise moze softverski, a da opet ne bude preterano opterecen CPU.

Ako je vec moguce sve to uraditi softverski tako glatko, postojao bi drajver i za dos. Naravno, morao bi se napraviti u real86 modu, ali UART valjda nije toliko komplikovana spravica da bi protected mod bio must, right ?

Hm, mislim da u real modu nema exeptions-a na i/o read i write, tj. CPU mora da radi u protected modu da bi mogao da hvata in/out instrukcije, tako da nista od emulacije u DOS-u.

Windows kernel ima isti mehanizam (interrupt pool) u ovom slucaju - on proverava interruptID da vidi da li je obrada gotova - ukoliko nije gotova, tj. interrupt handler jos uvek 'radi nesto', kernel ga izdvaja na poseban thread, ocekujuci sledeci event. Drajveri se pisu tako da rade u kernel adresnom prostoru, ne u standardnom aplikacijskom prostoru i tu prioritet threadova ne moze tek tako da se 'zamrlja'. Bar ne bi smeo

Nije mi tu nesto jasno pa imam jedno pitanje. Sta pokrece task schleduler ili kako se zvase (verovatno sam pogresno spelovao ) , u win9x je to VMM. Znaci mislim na srce sistema koje deli vreme procesima. Ja pretpostavljam da ga pokrece real time clock, znaci samo jedan od interrupta (bese 8) koji moze da se maskira tj. zabrani?

Paaa... ne bas. Interapti se dele na tri grupe i jos u njima po prioritetima, tako da interrupt handler moze da blokira samo neke interapte i to samo one nizeg prioriteta od svog (kao i svoj nivo). Uz cinjenicu da se neki interapti ne mogu blokirati.

Cek, cek, mislis verovatno da interrupt handler moze biti prekinut i pre IRET ako se desi interrupt viseg nivoa? Za to se slazem. Ja rekoh ako se uradi CLI. To zabranjuje SVE interrupte, osim NMI (non maskable interrupts) za koje se BTW ne secam bas cemu sluze . A koja je treca grupa?

Naravno da drajver ne moze imati vec i prioritet od kernela. Mislim, jesu ovi iz MS-a krelci ponekad, ali nisu toliki Zar bi ti dozvolio da jedna komandica, dostupna svima moze tako da freezuje sve ? To bi bio suvise otvoren sistem da bi bio iole siguran (od unutrasnjih i spoljasnjih uticaja).

Hm, pa nije bas dostupna svima, samo drajverima jer rade u ring-u 0. A drajvere ne instalira bas svako (il nebi trebaolo ). Aplikacije (user level, ring 3) naravno ne mogu to da urade. Moja iskustva su, kazem, sa 98-ice gde je vrrrlo lako zalediti sistem. Jedan pogresan korak i freeze. Moguce je da su stvari malo drugacije na NT platformama. Sad nemam pri ruci neki 9x da bih proverio tu neke stvari u praksi jer nisam ja napisao ni previse drajvera, a i nikad se nisam trudio da zaledim sistem (nisam ni morao ) vec da sve radi sto glatkije moguce.

Elem, da skratim pricu; ne bih smeo da tvrdim da se to sve moze svesti na problem preuzimanja prioriteta - cak i MS bi mogao to da resi jednim apdejtom na nivou kernela, kao glavnog dispecera. Pre bih rekao da do tih 'excesnih' situacija sa drajverima dolazi zbog nekog buga u samom kernelu - koncept im i nije toliko los (mislim, "njihov" koncept - to je generalni koncept OSova). Stvari do kojih dolazi imaju uzroke i u hardverskoj podlozi - pomenuti bug VIA-e sa PCI latencijom, ili nesto slicno sta se desilo sa i850/860 cipsetovima kod veceg saobracaja na nekom busu - dogadjaji se desavaju u realnom vremenu, bafer (za event queue) je ogranicenog kapaciteta, hardver (ove u primeru implementacija cipseta) okine break, loop se prekine (ili dodje do buffer overflowa) i jedan deo dogadjaja sa hardvera je "popapala maca". Jedan deo hardver (ni to nije savrseno), drugi deo softver.
Odosmo mi od winmodema ...

Pa dobro, moguce je i da je neki hardverski problem. Ne verujem da je u pitanju bug jer bi vec bio ispravljen do sada. Ali ja ipak mislim da je drajver I to opet ne mora da bude bug. Mozda jednostavno (ajde sad malo da ublazim ) drajver mora zbog necega da trazi maksimalni (tj. real time) prioritet i time ce bar da blokira sve procese sa nizim prioritetom od tog. I ako se takvo stanje zadrzi na bar 10-ak milisekundi - eto seckanja svih drajvera i user mode aplikacija koji nisu trazili real time priority.

P.S. Da li imas neki link gde se precizno opisuje ovaj problem sa soft modemima (ono o el.kolu za simulaciji UART-a i praznjenju FIFO bafera )? Ja sam nesto google-tao al' nalazim samo objasnjenja tipa: "to je winmodem - to mora tako".

 

[gojkos]

Nema nikakve veze sa platformom, odnosno cipsetom...
Presao sam upravo sa VIA na Intel i modem se apsolutno isto ponasa.

To je jednostavno karakteristika Win modema, mozda ne svih, cak ne ni svih Lucenta - npr. moj stari Lucent od pre dve godine prouzrokuje to zastajkivanje dok jedan noviji takodje no name sa Agere cipom to ne radi.
Inace to nije nista strasno, samo malo nervira ako bas insistirate da radite jos nesto drugo dok modem bira broj...

A taj no-name Agere, koje drajvere koristi? Ove "generic" lucentove?

 

[mikis]

Neki Agere modemi koje sam ja instalirao NE RADE sa lucentovim drajverima (v8.20 sam probao), zahtevaju svoje (Agere). Lucent drajveri se instaliraju ali ne prepoznaju modem.

 

[drapin]

A taj no-name Agere, koje drajvere koristi? Ove "generic" lucentove?

Ne, Win ga ne prepoznaje kao Lucent WinModem, vec trazi svoje drajvere sa CD-a i onda se prijavi kao Agere Systems PCI modem - dosta cudna situacija
Ocigledno i medju Lucent/Agere-ima postoje razne podvarijante...

Inace sam upravo negde zagubio CD a moram da reinstaliram doticni na drugom kompu ! FX
Totalno bunilo jer ne znam ni sta da trazim po net-u, kad ne znam sta je i koji je u pitanju ! FX

 

[drapin]

Neki Agere modemi koje sam ja instalirao NE RADE sa lucentovim drajverima (v8.20 sam probao), zahtevaju svoje (Agere). Lucent drajveri se instaliraju ali ne prepoznaju modem.

Jel imas mozda neku oznaku za bas te Agere drajvere koji idu na te Agere modeme koji se ne odazivaju na svoje Lucent poreklo ??? (RE: moj prethodni post )

 

[silverglider]

Vidim da ste se vi već lepo ispričali i ne zamerite ako ne kažem ništa novo, priznajem da nisam imao živaca da sve detaljno isčitavam.

Pazi njega, nije imao zivaca da procita o cemu se prica, ali je imao zato zivaca da istakne traljavost VIA cipseta i PCI latency bug (kao uzrok svog hardverskog zla) i neophodnost prelaska na Intel, kao resenje svih problema.

Da predjemo svi na intel, pa da zatvaramo forum, nece nam vise trebati


Elem, Marko, problem je u tom sto u ovom slucaju leka bez promene hardvera nema - modem je takav (zato i kosta toliko), a rasprava se oduzila zato sto je napokon (barem meni) zanimljiva, jer se ne dotice pitanja "da li da kupim GF3 ili RadeOn 8500LE" ili slicnih.

 

[Calimero]

I ja imam tog Agere Lucent-a i sa original drajverima mi secka tj. zastajkuje pod Win98SE a pod XP-om ne! Platforma je VIA (KT133A) (D)

 

[silverglider]

Uh ti sad ode u extreme pa ne moze telefonska linija direktno da se spoji na PCI magistralu, mora da ima bar ADC/DAC Salu na stranu, verujem da su oni i odradili sto god vise moze softverski, a da opet ne bude preterano opterecen CPU.

UART i jeste serijski kontroler, on je taj koji vrsi serijalizaciju podataka; recimo da skupi po bit sa osam zica i formira to kao jedan bajt i pusti niz stream.

Da, jesam malo preterao za modem bez elektronike, ali na to se svodi. Neretko neko kolo vrsi te sve operacije, tj cesto te simulacije ne radi sam CPU, nego neki mikrokontroler.

Hm, mislim da u real modu nema exeptions-a na i/o read i write, tj. CPU mora da radi u protected modu da bi mogao da hvata in/out instrukcije, tako da nista od emulacije u DOS-u.

Razlika izmedju protected i real (ili V86) moda se manje vise svodila na alokaciju i segmentaciju memorije, (ne)mogucnost multitaskinga i, ono sto je ovde interesantno - razlicite Interrupt Desktriptor tabele (za isti hardver).
E sad, in/out je postojao, naravno, i za 8088/8086, a signalizacija greske je mogla da se odradi i na drugi nacin, cak i NMI-jem.

Cek, cek, mislis verovatno da interrupt handler moze biti prekinut i pre IRET ako se desi interrupt viseg nivoa? Za to se slazem. Ja rekoh ako se uradi CLI. To zabranjuje SVE interrupte, osim NMI (non maskable interrupts) za koje se BTW ne secam bas cemu sluze . A koja je treca grupa?

Pa generalno su se gurali u NMI, zatim masked i softverske, iliti one koje generise procesor, a ne ostali 'ardver.
NMI klasa interapta se i koristi bas u svrhe kada treba CPU prekinuti, cak i kada si startovao "ignorisanje" okidanja interapta.
Kod grupisanje po prioritetima sam mislio i na sledece;
- najnizi su prioriteti softverskih servisa, kao sto je pomenuti int21h
- prioriteti hardverskih interapta kako ih rasporedjuje njihov int.kontroler. E tu je vec malo drugacija situacija; po starom XT standardu, opostojao je samo jedan PIC sa interaptima 0-7 i definisao je njihove prioritete kao 0-najveci, 7-najmanji. Kada je kasnije dodan i drugi PIC (Master-Slave), interapti ovog drugog (8-15) su mapirani preko irq2 linije ovog prvog, tako da prioriteti sad idu 0,1,(8,9,10,11,12,13,14,15),3,4,5,6,7 i kod dodele i kod okidanja (uz ogradu da su neki unapred rezervisani pre dodele, recimo 8 i 13)
- najveci prioritet, NMI koji prolazi svuda kao kroz sirac

Hm, pa nije bas dostupna svima, samo drajverima jer rade u ring-u 0. A drajvere ne instalira bas svako (il nebi trebaolo ). Aplikacije (user level, ring 3) naravno ne mogu to da urade. Moja iskustva su, kazem, sa 98-ice gde je vrrrlo lako zalediti sistem. Jedan pogresan korak i freeze. Moguce je da su stvari malo drugacije na NT platformama. Sad nemam pri ruci neki 9x da bih proverio tu neke stvari u praksi jer nisam ja napisao ni previse drajvera, a i nikad se nisam trudio da zaledim sistem (nisam ni morao ) vec da sve radi sto glatkije moguce.

Ja sam do sada ucestvovao u pisanju tri drajvera ovaj zadnji (USB-to-IDE) za linux jos drndam.

Hm, nije samo za drajvere u ringu 0. Mislim, dostupnost CLI-ja. U 99% slucajeva CLI i STI se pozivaju kada hoces da preuzmes interrupt vektor, tj registrujes svoj interrupt handler - cli, registracija, sti. To, naravno, ne mora da bude drajver - svaki tsr to radi, na primer.
Elem, to je jako kratko - baci registre i ostalo na stek, registruj, vrati stanje - ne vidim nekog osnova da bi trebalo toliko dugo da traje (jos manje za realno vreme). Uostalom, toliko se buke diglo oko toga, da su cak i ovi iz Lucenta culi za to - valjda bi i u njihovom interesu bilo da to oprave, pa da se ide glatko
Novije drajvere su izbacivali, problem ostao.

Evo ga jedan fini link ovde.

P.S. Da li imas neki link gde se precizno opisuje ovaj problem sa soft modemima (ono o el.kolu za simulaciji UART-a i praznjenju FIFO bafera )? Ja sam nesto google-tao al' nalazim samo objasnjenja tipa: "to je winmodem - to mora tako".

Koliko se ja secam, bilo je na jednom od AT&T sajtova, neki od faqova, za neki od njihovih modema - ubi me sad za tacnu stranu.


Da, i na kraju nagradno pitanje - sta ako je ta PCI karta (nazovimo to "modemom" ) trenutno ukljucena u IRQ sharing ?

 

[gojkos]

Razlika izmedju protected i real (ili V86) moda se manje vise svodila na alokaciju i segmentaciju memorije, (ne)mogucnost multitaskinga i, ono sto je ovde interesantno - razlicite Interrupt Desktriptor tabele (za isti hardver).
E sad, in/out je postojao, naravno, i za 8088/8086, a signalizacija greske je mogla da se odradi i na drugi nacin, cak i NMI-jem.

Hm, kolko se ja secam, poruke kao "General protection fault..." zbog brljanja po memoriji smo poceli da vidjamo tek sa pojavom DOS ekstendera koji su radili u protected modu i koji su zato mogli da iskoriste sve te fault mogucnosti 386 procesora. Mozda moze i drugacije da se odradi i/o fault ali nisam bas siguran kako.

Pa generalno su se gurali u NMI, zatim masked i softverske, iliti one koje generise procesor, a ne ostali 'ardver.
NMI klasa interapta se i koristi bas u svrhe kada treba CPU prekinuti, cak i kada si startovao "ignorisanje" okidanja interapta.
Kod grupisanje po prioritetima sam mislio i na sledece;
- najnizi su prioriteti softverskih servisa, kao sto je pomenuti int21h
- prioriteti hardverskih interapta kako ih rasporedjuje njihov int.kontroler. E tu je vec malo drugacija situacija; po starom XT standardu, opostojao je samo jedan PIC sa interaptima 0-7 i definisao je njihove prioritete kao 0-najveci, 7-najmanji. Kada je kasnije dodan i drugi PIC (Master-Slave), interapti ovog drugog (8-15) su mapirani preko irq2 linije ovog prvog, tako da prioriteti sad idu 0,1,(8,9,10,11,12,13,14,15),3,4,5,6,7 i kod dodele i kod okidanja (uz ogradu da su neki unapred rezervisani pre dodele, recimo 8 i 13)
- najveci prioritet, NMI koji prolazi svuda kao kroz sirac

Da, da, softverske interapt servise nisam ovde uzeo u obzir jer to i nisu pravi (hardverski) interrupti. Ovo sa prioritetima je interesantno. A NMI mi i dalje nije jasan al nema veze...

Hm, nije samo za drajvere u ringu 0. Mislim, dostupnost CLI-ja. U 99% slucajeva CLI i STI se pozivaju kada hoces da preuzmes interrupt vektor, tj registrujes svoj interrupt handler - cli, registracija, sti. To, naravno, ne mora da bude drajver - svaki tsr to radi, na primer.
Elem, to je jako kratko - baci registre i ostalo na stek, registruj, vrati stanje - ne vidim nekog osnova da bi trebalo toliko dugo da traje (jos manje za realno vreme). Uostalom, toliko se buke diglo oko toga, da su cak i ovi iz Lucenta culi za to - valjda bi i u njihovom interesu bilo da to oprave, pa da se ide glatko
Novije drajvere su izbacivali, problem ostao.
Evo ga jedan fini link ovde.

Tacnije CLI se koristi gde god je potrebno osigurati da neka kriticna operacija ne bude prekinuta interruptom, jer moze doci do katastroficnih posledica. Ali u user-level aplikacijama ove instrukcije (CLI i STI) nemaju efekta valjda upravo zbog sigurnosti sistema.
I interrupt vektor ne moze nikako da preuzme windows aplikacija, u windows-u ne postoji mehanizam (API) za tako nesto. Kad kazes TSR verovatno mislis na DOS TSR-ove ili Linux? Zauzimanje IRQ-ova i postavljanje interrupt handlera u win-u je moguce je samo u drajverima, AFAIN. Cak i tu windows sistem se postavlja kao posrednik izmedju hardvera i drajvera. BTW, M$-ova DDK dokumentacija vrlo vesto izbegava da opise detaljnije kako hardver funkcionise, vec samo daje tacno onoliko koliko je potrebno da se shvati kako funkcionise njihov layer. Sto se njih tice, najbolje bi bilo da njihov sistem smatramo, maltene, za hardver.

A ne vidim ni ja osnova zasto bi modem drajveru trebalo toliko vremena i max proiritet ali izgleda da mu treba.

Da, i na kraju nagradno pitanje - sta ako je ta PCI karta (nazovimo to "modemom" ) trenutno ukljucena u IRQ sharing ?

Ne znam, sta se desava? Pod win-om sistem preuzima na sebe IRQ sharing, a drajver moze samo da se izjasni dal dozvoljava il ne da njegov IRQ bude sharable. Windows nekako zna odakle je realno dosao interrupt i poziva odgovarajuci handler.

 

[silverglider]

Hm, kolko se ja secam, poruke kao "General protection fault..." zbog brljanja po memoriji smo poceli da vidjamo tek sa pojavom DOS ekstendera koji su radili u protected modu i koji su zato mogli da iskoriste sve te fault mogucnosti 386 procesora. Mozda moze i drugacije da se odradi i/o fault ali nisam bas siguran kako.

Da, protected mod je imao exception handlere, za razliku od real moda. E sad, ja sam rekao da je greska mogla da se prijavi i na druge nacine. A kako su oni to odradili ..
Kao sto je poznato, CPU se sastoji od delova kao sto su ALU, FPU, itd. Izmedju toga su i dva unita koji se zovu Segmentation unit i Paging unit. Oni su ovde kljucni za real mod. Sama takva jedinica unutar procesora nije svesna da li se nalazi u real ili protected modu (najnoviji imaju valjda neki flag, ali nisam siguran) vec se samo vrednosti koje se u njima cuvaju drugacije tumace, u zavisnosti od moda. Na primer, u Segmentation unitu se drze base adresa, limit i atributi. Kada se radi o npr. V86 modu, base adresa se mnozi sa 16 po ucitavanju u segment registar, dok se ta ista vrednost u protected modu koristi kao index u globalnoj/lokalnoj descriptor tabeli. Elem, ukoliko se u real modu pokusa upis u read-only segment ili uzvan intervala base+limit, procesor okida int 13h, koji baca na stek instrukciju koja je prouzrokovala gresku. Ukoliko taj interapt nije handlovan, dolazi do zaglavljivanja. Int13h se koristi za obradu irq5 (po originalnom dizajnu, ne pitaj me zasto). Po okidanju iret iz irq5 handlera, ocekuje se da se sa steka pop-uje *sledeca* instrukcija, a donosi se ona instrukcija koju je int13h podmetnuo tamo - falicna - i ponovo izvrsava i tako se zavrte u krug i dolazi do zaglavljenja.

A ne vidim ni ja osnova zasto bi modem drajveru trebalo toliko vremena i max proiritet ali izgleda da mu treba.

Pa eto, rekose ljudi iz AT&T da je to u ovom slucaju zbog jeftinih komponenti. Tj. one prouzrokuju kurslus na relaciji drajver-kernel. Da znam jos detaljnije, zaradio bih pare na tome

Ne znam, sta se desava? Pod win-om sistem preuzima na sebe IRQ sharing, a drajver moze samo da se izjasni dal dozvoljava il ne da njegov IRQ bude sharable. Windows nekako zna odakle je realno dosao interrupt i poziva odgovarajuci handler.

Ne, nisam na to mislio - postoji tabela irqova na dva nivoa - niski (BIOS nivo) i visoki (OS nivo). Zato biosima ima opcija (otvorena ili skrivena) da li imas PnP OS i slicno. Ako se to iskljuci, raspodela irqova se koristi "as is" tj kako ih je bios rasporedio - inace se dozvoljava drajveru cipset bridzeva u saradnji sa OSom da se napravi "remapiranje" irq linija - tako je cesto u Win2k, na primer, prikazano kako je n uredjaja na irq9 liniji, na primer, iako su u biosu bili drugacije rasporedjeni. Jos vaznije - na taj nacin su grupisani i uredjaji koji ne podrzavaju irq sharing. Pri tome se misli ne na ove mapirane, nego one na nizem nivou - to je ono kada ti uredjaj ne radi, nego moras da promenis slot ili raspored irqova u biosu.

 

[mikis]

Jel imas mozda neku oznaku za bas te Agere drajvere koji idu na te Agere modeme koji se ne odazivaju na svoje Lucent poreklo ??? (RE: moj prethodni post )

Ne znam na koju oznaku mislis? Drajvere nemam instalirane jer nemam ni modem, ali sam sacuvao instalacioni CD U inf fajlu pise:

MONTBLANC.Modem="Agere Systems PCI Soft Modem"
FullProductName="Agere Systems Soft Modem"
ModemProvider="Agere"
ShortProductName="SoftModem"
Disk1Name="Agere Systems PCI Soft Modem Installation Disk"

Sam drajver se zove drugacije nego za Lucenta (agrsm.sys) a verzija koju ja imam je 2.1.6, datum 02/01/2002

 

[gojkos]

Pa eto, rekose ljudi iz AT&T da je to u ovom slucaju zbog jeftinih komponenti. Tj. one prouzrokuju kurslus na relaciji drajver-kernel.

OK, sa ovom (tu i tamo neodredjenom) dijagnozom mogu da se slozim (slozio bih se i u startu ).

Nego da batalimo mi ovu diskusiju. Za neke (mnoge) stvari bih morao da kopam po nekim knjigama ili po netu, sto me trenutno mrzi, a nemam bas ni vremena.

Uglavnom, ima sta od tebe pametno da se cuje i nauci. cheers