Date: Wed, 26 Jan 2000 11:03:55 +0100 From: "Jose M. Alcaide" <jose@we.lc.ehu.es> To: freebsd-hardware@FreeBSD.ORG Subject: Re: RTC (stat clock) does not generate interrupts ?!?! Message-ID: <388EC68B.7CEC90AC@we.lc.ehu.es> References: <388C6882.F0F83BD0@we.lc.ehu.es>
next in thread | previous in thread | raw e-mail | index | archive | help
"Jose M. Alcaide" wrote: > > Hello, > > I have a bizarre problem with my new computer: a Dell Inspiron 3700 laptop. > I am posting to -hardware instead of -mobile because this problem is > related to the RTC (statistical clock), and I need a larger audience :-) > > This is the problem: under some circumstances, the RTC does not > generate interrupts (IRQ 8) after the system is started or rebooted. > These circumstances are: > > 1. The system is rebooted, while being powered by AC or battery. > > 2. The system is turned off and on, while being powered by AC. > > And this is astonishing: when I turn the laptop off, disconnect it from > AC, wait a couple of seconds, reconnect to AC, and turn it on again, > the RTC _does_ work. > > I used "vmstat -i" to see when IRQ 8 is being generated by the RTC. > However, in order to have a direct proof, I modified the rtcintr() > handler in sys/i386/isa/clock.c for displaying a message every > 128 interrupts (one second). Using this little trick I confirmed > that "vmstat -i" is not lying. > > And there is another interesting fact: if I suspend the system when > the RTC is not working, after resuming the RTC works! I suspect that > the cause is that i8254_restore() is called from apm_default_resume() > in sys/i386/apm/apm.c. > > I suspect a BIOS bug, but anyway I would love to have any explanation > for this strange phenomenom. I am willing to try any modifications to > sys/i386/isa/clock.c, but I do not know anything about i8254 programming, > so I would be very very thankful for any idea or advice. > I post this message for future reference in the mail archives :-) Definitely, the Dell Inspiron 3700 C433GT is one of those machines that have a broken statclock. I would like to know what does this mean, but, anyway, these are the facts. Rats. Then, for "solving" the suspend problems, the apm device must be compiled with flags 0x20, as stated in LINT. I don't know what are the consequences of the missing statclock for the system. I suppose that profiling won't work, but... any more effects? -- JMA ----------------------------------------------------------------------- José Mª Alcaide | mailto:jose@we.lc.ehu.es Universidad del País Vasco | mailto:jmas@FreeBSD.org Dpto. de Electricidad y Electrónica | http://www.we.lc.ehu.es/~jose Facultad de Ciencias - Campus de Lejona | Tel.: +34-946012479 48940 Lejona (Vizcaya) - SPAIN | Fax: +34-946013071 ----------------------------------------------------------------------- "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?388EC68B.7CEC90AC>