Mizejici LPT ve Windows 7

Je mozne, ze novsie systemy vedia pouzivat uz len APIC a tvoja doska nic take nema.

Ne to fakt mozne neni :)

No obidve metody naraz pouzivat nejdu. Tak jedine preinstalovat system, aby si instalacna procedura dotiahla ovladac na spravny hardware.
Takto je to spravne ?

S tym nema nic ovladac ani APIC, ide skor o chybu v ACPI implementacii SuperIO, v BIOSe tej dosky. Win7 interpretuje viac veci v ACPI jak XP, ptz WIn7 je podla ACPI 3.neco a XP podla 2.neco, preto tam moze byt rozdiel

Moze byt, akurat riadenie IRQ je na doskach uz aspon 5 rokov robene zasadne inak ako sme sa v ucili v skole a to vzhladom na multiprocessing.

Neexistuje ziadne "riadenie IRQ". Existuje PIC controller a APIC controller a konkretne u LPT medzi nimi neni ziaden rozdiel, preto som ti tu myslienku znegoval :)

Ja by som povedal, ze je tam rozdiel a to velmi podstatny.
Udalost nazyvana "prerusenie" uz neni prenasana jednotlivymi elektrickymi signalmi, ale ako sprava na “APIC bus-e”.
Kolko rokov si nestudoval vyvojove trendy hardwaru ?

ja tie veci vcetne ACPI a APIC veci programujem denne uz >10rokov a vzdy najnovsie chipsety :) Ja tu nevypisujem nejake studijne somariny. Aj o Message signalled interrupt viem, nemaj strach, ale u LPT neni ziadne message signalled a neni tam ziaden rozdiel z hladiska OS ani medzi PIC a APIC. Navyse keby bol problem s IRQ tak to nezmizne tzo spravcu. zariadenie zmizne zo spravcu vtedy ked ACPI metoda _STA vrati 0. A ta u LPT vrati 0 vtedy ked je v SIO registri patricne device vypnute (reg.30 = 0). A preco je vypnute lebo napr. cinan v _PS3 metode nastavil reg.30 na 0

Neni to cinan, ale nemec - ne ze by to byla nejaka vyhra :) To jsou ti, co vzdycky vyhazi z BIOSu polovinu veci a pak se divi, ze jim neco nefunguje. Jako posledne "nefunguje nam boot selection pred bootem" - ladim to dva dny a narazim na radek s nemeckym komentarem "odstranen boot selection pred bootem"

Ja uz som u jednej starsej FS dosky si urobil patchovanie ACPI kodu v MBR (IRQ routing u PEG bol blbo a zvukovka na grafike robila IRQ storm :D). Potom po roku som tu dosku vyhodil a kupil i3 :D

Vim, rikal's :)

Ted me napada, _STA na tyhle desce vraci 0, pokud je LPT port zakazanej - nemelo by to spis bejt 0x09 (present, disabled) - zkusim, co to udela. Mozna Win7 cvicne zakaze porty a pak by je i povolilo, ale kdyz mu _STA rika, ze tam neni...

To neries, ano mohlo by to byt tak ale potom by bol furt LPT vo Win vidiet aj ked ho uplne zakazes v BIOSe. Ked mozes modifikovat zdrojaky tak vyhod _PS3 a _DIS u LPT a nemas problem. Alebo len vo Win zakaz powermanagement.

Pocuvaj, na vychodniara ty si neni krepy (iba ze neviem ako sa tam u vas povie 'krepy', to je skor po stredoslovensky hadam).
Zakazat _DIS by mi asi neproslo u zakaznika, ale kdyz to aspon docasne vyhodim, mozna mi Windows neco rekne ohledne konfliktu nebo pripadnych problemu, proc tomu drbne.

Slusne sa to riesi tak ze STA metoda nepozera len na register 30, ale pozera aj na nejaku ACPI variable v tom dlhom NVAR bloku kde BIOS ulozi ze ci bol v setupe LPT port enabled alebo disabled. Potom aj ked powermanagementom vypnes dekodovanie v reg.30, tak v STA mozes stale vracat ze present ale not decoding. Ja ale by som cely power management poslal kamsi...

_PS3 jsem nezkousel, podle kodu to ani nebylo zapotrebi, ale ukazalo se, ze je zapotrebi, aby _STA vracelo 0x09 po _DIS, nikoliv 0. Podle vseho Win7 nejdriv zakazou LPT pres _DIS, a potom by ho i povolily, ale kdyz _STA vraci 0, cili not present, tak se na to vykaslou.
Zakaznik podle vseho pribastlil nulovani registru 0x60 pri _DIS, cimz zmatl jinak fungujici _STA :)
Ale navedl's me na spravnou cestu, dik :)

Ano STA po DIS nesmie vratit 00 ale nejake 0D ci kolko. Da sa to roznymi sposobmi napr. aj ze si v nejakej ACPi variable bude pamatat ze ci aspon raz uz bolo rozpoznane (reg 30=1) a ak ano tak vracat potom uz len 0D (ak reg 30=0) alebo 0F ak reg 30=1

Je mozne ze mas pravdu. IRQ pre LPT, je prenasany pravdepodobne este v mode legacy cez signal INTR do LAPIC. Resp. zrejme asi vsetko co je napojene na SuperIO, pretoze ten emuluje ISA. Ale zmenilo sa toho tak vela, ze nezostal kamen na kameni.
Je usmevne ze operacne systemy napriklad dodnes tvrdosijne pomenuvaju typy preruseni aj v rezime APIC ich povodnymi cislami IRQ – napriek tomu realne na zbernici PCI se tento koncept davno vyprazdnil a so zmiznutim zbernice ISA postrada akykolvek realny zaklad. Keby nebolo APIC, ktore prinieslo IRQ 16-24 (na 2 CPU až IRQ31, so 4 CPU az IRQ63), uzivatel by si ani nevsimol, ze je nieco inak, ked mu klavesnica stale visi na IRQ1, disketova jednotka na IRQ6 a koprocesor na IRQ13. Vyrobci operacnych systemov su si asi vedomi, ze uzivatel je rad balamuteny.

Neni nic usmevne. Cislo IRQ je jeho vektor a ten suhlasi s realitou. Neni tam nic legacy.
APIC aj PIC generuje z hladiska OS IRQ uplne stejne (vykonavanie skoci na nejaky vektor), akurat ma APIC viac vektorov, preto mas s APIC aj moznost mat IRQ mimo rozsahu 0-15, to ale neznamena ze teraz rozsah 0-15 je zakazany alebo nechapem o co ti furt ide. Tvoj problem je ze si si kdesi nieco precital co nechapes a nemas ponatia jak to funguje skutocne (co neni nic strasne, ponatia o tom ma len dost malo ludi na zemeguli a nikam to nevypisuju, a ani ja to nikam podrobnejsie vypisovat nebudem :).
HW APIC je nastaveny tak aby to fungovalo a generovalo tie vektory IRQ ktore to generuje, co sa deje v HW ta nezaujima. Pre OS to su IRQ s tymi cislami. Neni v tom ziaden problem.
Message signaled IRQ maju u Win7 zapornecisla, to je len ulet MS, inac tie cisla su nepodstatne.

Podla stupna pochopenia nastudovanych veci som toho nazoru, ze v chipsetoch by mali existovat dva rozne sposoby generovania a obsluhy preruseni.
Jeden by mal byt legacy s INTR signalom napojenym priamo na procesor a druhy je messaged IRQ. Ten prvy sa postupne vytraca, pretoze ho nieje mozne smerovat na rozne procesory. Vzdy je totiz zapojeny len na jeden CPU aj ked by ich boli v systeme miliony.
Druhy je, alebo velmi skoro bude preferovanym sposobom. Ovsem mas pravdu, z pohladu programatora sa zrejme nic nemeni, kedze routing moze zabezpecit samotny hardware.
O nic mi nejde :). Som rad, ze sa tu vyskytuje niekto, kto ma detailnejsi prehlad v hw a programovani systemovych veci.
Zrejme aj ty programujes ovladace rovnakym sposobo ako mnohi iny (napr.aj ja a cela Linux komunita), ze sa roky rokuce pozerame do registrov a vyvodzujeme z toho ako funguje hw, namiesto toho aby sme si za 20tis US$ kupili dokumentaciu k chipsetu.

Ja dokumentaciu k chipsetu mam :)
Ono je to v HW omnoho komplikovanejsie, nema ale zmysel to tu rozoberat, je toho moc vela. V skratke, v dnesnom PC ide vsetko cez APIC (nastavi ho BIOS a ciastocne aj OS). APIC je hlavny "uzol". Do neho ide milion veci zvonku a je komplikovanym sposobom napojeny na CPU Cores. 90% z tychto HW veci je al zo SW hladiska nezaujimave, 80% z nich ani nepotrebujem vediet takze mi to ani intel nepovie a ani nie su podstatne. Podstatne je jak sa to sprava z hladiska vonkajsich zariadeni a na SW urovni. (a LPT sa sprava uplne stejne s APIC aj s PIC)