Date: Tue, 21 Jul 1998 17:57:43 -0700 From: Mike Smith <mike@smith.net.au> To: Brian Somers <brian@Awfulhak.org> Cc: Mike Smith <mike@smith.net.au>, Bruce Evans <bde@zeta.org.au>, jak@cetlink.net, freebsd-mobile@FreeBSD.ORG Subject: Re: tickadj -t not changing tick Message-ID: <199807220057.RAA03130@dingo.cdrom.com> In-Reply-To: Your message of "Wed, 22 Jul 1998 01:30:09 BST." <199807220030.BAA02246@awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > >The laptop: > > > > > > > > > >: FreeBSD 3.0-CURRENT #10: Tue Jul 14 10:02:00 BST 1998 > > > > >: brian@woof.lan.awfulhak.org:/usr/src/sys/compile/WOOF > > > > >: Timecounter "i8254" frequency 1193182 Hz cost 1296 ns > > > > >: CPU: Cyrix GXm (17.09-MHz 586-class CPU) > > > > This isn't actually a Cyrix "MediaGX" processor, is it? If so *all* > > bets on its behaviour are off. The MediaGX emulates some of the system > > hardware using SMI traps, and the quality and accuracy of this > > emulation seems to vary widely with BIOS implementor. > > Hmm, it says ``Cyrix MediaGX MMX'' in large friendly letters on the > box. I guess it's going back to the shop. Such a shame - but I > should have realized there was a catch. Yecch. The MediaGX is a truly disgusting device, and returning it just as fast as you can is a very good idea. Just to give you an idea; I was playing with a MediaGX based system a few months back. Due to bugs in the SMI BIOS, it generated spurious interrupts and integer divide faults at apparently random times. FreeBSD was unusable on this system, because it takes these faults seriously. Linux ignores them (no surprises there), but running 'top' with a 1-second update consumed 30% of the CPU doing nothing but maintaining an 80x25 text screen. (The issue here is that every time you write to video memory the CPU takes a trap into SMI mode, the character is drawn into the display bitmap and then you return...) > > The PCCARD controller is polled as well as handled by an interrupt, but > > that doesn't sound like your problem. > > The controller seems fine, but I thought (this is probably wrong) > that the controller passed the card irqs onto the bus.... The controller has one IRQ output for itself, and then one for each card. The pccard code polls the controller, so that even if its interrupt is not being seen, we still get controller events. However, drivers often depend on IRQ activity from their hardware, so the card interrupts do have to be seen to work. > I guess I should be grateful that the CD & sound card work. I knew I > shouldn't have bought Compaq - they have a tendency to do produce > these sort of surprises. It hurts to say it, but basically you're really just better off getting rid of this unit. It's going to take someone seriously dedicated a lot of work to make the sort of hardware the GX seems to encourage work well for us, and I doubt that's what you want. Try something from Dell or Digital or perhaps Toshiba instead if you want a name-brand "it works" solution, or any of the many taiwanese units based on the 430TX chipset. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807220057.RAA03130>