Suspend linux-szal. - 5. resz (bar hosszu, szerintem erdekes)

Jajj, nagyon hosszu lett. De szerintem tanulsagos es erdekes. Nem mondom el mi a vegeredmeny, tessek izgulni.

Tegnap reggel (volt az del is) nekialltam ujra a suspenddel szorakozni, mert megvan a szamgephalo alairasom, hat gondoltam, legalabb arra nem kell tanulni, van annal fontosabb is.

(Ha valaki uj lenne a hegesszunk gilgamesre suspend-ficsort projektemben, annak: 1 2 3 4)

Tehat. Azt vettem eszre, hogy furamod, a fujitsun - amin megy a suspend - es a Clevokon futtatott lspci kimenete - talan - fontos elterest mutat:


[kmarc][gilgamesh][~/DEBUG][$] cat lspci_fujitsu | grep Serial\ ATA
00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller AHCI (rev 02)
[kmarc][gilgamesh][~/DEBUG][$] lspci | grep Serial\ ATA
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 02)

Igen, jol latszik, nalam valami SATA-IDE parositas van. Azt hiszem "intel combined mode"-kent hivatkoznak ra. Nos akkor, rebootoltam, es latom is, hogy - ez eddig elkerulte a figyelmem - ATAPI CD-ROM-kent ismeri fel a DVD-irot. Nosza rajta, kiprobaltam, amiket a libATA oldalan a faq-ban ajanlanak; libata.atapi_enabled, meg irqpoll, noapic, acpi=force, minden, ami az ICH7-nel gond szokott lenni. Termeszetesen semmi valtozas, ugyanaz tortenik: Ha hosszabb ideig suspendben van a gep (mondjuk ugy egy percig), akkor masodszor nem tud elmenni aludni.

Tovabba, ne menjunk el a teny mellett, hogy amikor nem megy el susendbe, a vinyot kikapcsolja (hallom, ahogy spindown), de a DVD-meghajto hangot ad ki, olyat, amilyet POST soran szokott. Tehat, ott valami megszakitaskerelmes dolog lesz. No de hat mi van, ha nincs is CD-meghajto. Hajra.

Eloszor csak kiszedtem a BIOSban a meghajto felismereset. Nem volt eleg, hat szetszereltem a gepet. Eltavolitottam a meghajtot. Ez utan sem mukodott. Hmm... talan ki kellene huzni az alaplapbol. Ugy neztem, hogy a cucc mindenfele kabelek nelkul csatlakozik az alapaphoz, szoval a vezerlo szerintem minden esetben kap aramot. Francba.

Hat, de megis ez miert van. Tokeletesen mukodik n-szer, de n+1-edszer nem. Es mar tudom, hogy lehet eloidezni a dolgot. Nyilvan az a gond, hogy valami idozito lejar/tulcsordul akarmi, merthat megis, hogy lehet az, hogy ha tobb, mint x masodpercig alszik, akkor tobbe nem tud? Es egyaltalan, mi ez az X? A kovetkezo blogbejegyzesemben mar arrol fogok irni, hogy megtalaltam a kritikus idomennyiseget, csak most nincs idom probalgatni. De addig is, tippeljuk meg.


Reszlet a /usr/src/linux-source-2.6.20/drivers/ide/ide-io.c fajlbol
static void ide_check_pm_state(ide_drive_t *drive, struct request *rq)
{
        struct request_pm_state *pm = rq->data;

        if (blk_pm_suspend_request(rq) &&
            pm->pm_step == ide_pm_state_start_suspend)
                /* Mark drive blocked when starting the suspend sequence. */
                drive->blocked = 1;
        else if (blk_pm_resume_request(rq) &&
                 pm->pm_step == ide_pm_state_start_resume) {
                /* 
                 * The first thing we do on wakeup is to wait for BSY bit to
                 * go away (with a looong timeout) as a drive on this hwif may
                 * just be POSTing itself.
                 * We do that before even selecting as the "other" device on
                 * the bus may be broken enough to walk on our toes at this
                 * point.
                 */
                int rc;
#ifdef DEBUG_PM
                printk("%s: Wakeup request inited, waiting for !BSY...\n", drive->name);
#endif
                rc = ide_wait_not_busy(HWIF(drive), 35000);
                if (rc)
                        printk(KERN_WARNING "%s: bus not ready on wakeup\n", drive->name);
                SELECT_DRIVE(drive);
                HWIF(drive)->OUTB(8, HWIF(drive)->io_ports[IDE_CONTROL_OFFSET]);
                rc = ide_wait_not_busy(HWIF(drive), 100000);
                if (rc)
                        printk(KERN_WARNING "%s: drive not ready on wakeup\n", drive->name);
        }
}

Oppa, van itt az ide-io-kezelesert, annak allapotanak lekerdezeseert felelos fuggveny, benne ket ertekkel: egy 35.000-essel, es egy 100.000-essel. Remelem, ezek millimasodpercben ertendok. Hat, mivel nem kellett soha 1p 40mp-et varni suspendben, szerintem az elso szam lesz az en szamom. Ja, es ott van egy, a POST-ra utalo mondat is. Na mar bocsanat, de minden kis szalmaszalba megprobalok belekapaszkodni. :)

Mivel egyelore csak tesztadatokkal szeretnek szolgalni a kernelfejlesztoknek, igy nem turkalok a kodban (mi kozom is nekem hozza?), hanem inkabb probalgatok, es belovom azt az idomennyiseget, ami utan tenyleg nem tud visszajonni. Remenyeim szerint ez 35mp lesz.

Hat, ahogy mar kaptam batoritast sakic-tol, tovabbra is probalkozom, majd jelentkezem az eredmenyekkel.