Date: Thu, 06 Nov 1997 12:48:05 +1030 From: Mike Smith <mike@smith.net.au> To: "Bill O'Hanlon" <wmo@hq.pro-ns.net> Cc: freebsd-mobile@freebsd.org Subject: Re: Some APM stuff Message-ID: <199711060218.MAA00734@word.smith.net.au> In-Reply-To: Your message of "Wed, 05 Nov 1997 13:39:06 MDT." <199711051939.NAA27274@hq.pro-ns.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> I'm somewhat interested in getting some of the APM stuff working > on my laptop, which is a Compaq Concerto. It's a little old, so > if this just isn't going to happen, it's no big deal. We can but try. Tell me, do you have the courage (and experience, and tools) necessary to open it up and eyeball the PCIC? Knowing what the hardware is can often help a great deal. > On the off chance that any of these observations help advance the > cause, I'm sending them. Feel free to ignore all of this -- I'm > just tinkering for the fun of it. Datapoints are always worthwhile. If nothing else, this is in the archive now, so if we're chasing it later, we have a reference. > There's a couple things I'll mention. First, I've got two PCMCIA > cards in it, and they both work fine. One's an Intel Faxmodem > 14.4, and the other is a Linksys Ethernet card. (Don't buy these, > by the way -- the dongle for the ethernet connection is loose and > fragile. I'm on my second dongle, and they're not cheap.) Aren't they all? > Nate, you mentioned a while back that some people have to use sio.c > with some of the probes commented out to get the modem card to > work. I'm one of them. So, if anyone wants to run that issue > down, I'd be happy to try your code. Since it works with the probes > (3, 5 and 6, if I recall correctly) commented out, I'm happy with > it the way it is. This sounds like interrupts aren't working at all. Or if they are, they work kinda strangely. In sio.c:sioprobe(), there are some delays that were inserted to deal with various slow modems; you might want to increase them (see where the failing tests are made and increase the delays before the tests are performed). If you have a chance to check the card in another laptop, it would be interesting to know if the problem(s) follow the card or stay with the machine. > First of all, here's the output from apm. Is that APM version > possible?? Maybe I'm too far back on this old machine to be able > to get this stuff working. > > APM version: 0.27 This looks pretty kinky, but the BIOS is claiming that the function is supported. > APM Managment: Enabled > AC Line status: on-line > Battery status: charging > Remaining battery life: 100% How do these correspond to reality? If you pull the AC power, does the status change to match? Is the battery actually charging (ie. not full?) > Oh, I suppose I should mention what doesn't work: if I do a > "zzz", I get a panic. The stack trace from DDB has a zillion > calls to "apm_processevent" and "apm_suspend" -- as if they're > calling each other in an infinite loop. Interestingly, the > machine DID suspend right after the debugger prompt > comes up -- so it's almost like the suspend would work if the > routines weren't calling each other to death. Resuming from > suspend brings it back up with the debugger active, so the resume > almost seems to work, too. It would be useful to know what the APM events in question are; I suspect that we are not dealing with a response that the BIOS is sending in the correct fashion. > If this helps anyone trying to get the APM stuff working in > a general fashion, great. If not, I'll just continue to > poke at it myself. > apm: APM BIOS version 0001 Interesting that this and the other message disagree. It looks like your BIOS might be prior to APM-1.0, and reporting different values in the initial presence check and subsequent connects. > apm: Code32 0xf00f0000, Code16 0xf00f0000, Data 0xf00f0000 > apm: Code entry 0x0000c505, Idling CPU disabled, Management enabled > apm: CS_limit=0x1f, DS_limit=0x655 > apm: found APM BIOS version 0.27 Hmm, very low CS limit makes it look like this does most of its work in 16-bit mode. Interesting that they have the 32-bit entry in such a (potentially) old version. Do you have Windows 95 on this box by any chance? > ppc0 at 0x3bc irq 7 on isa > ppc0: Generic chipset in EPP mode (EPP 1.9) > ppi0: <generic parallel i/o> on ppbus 0 You should be able to add the 'nlpt' driver if you want to be able to print on this box. 8) > PC-Card Cirrus Logic PD672X (5 mem & 2 I/O windows) > Add hook "Cirrus Logic PD672X" > Add hook "Cirrus Logic PD672X" > pcic: controller irq 3 Suspend/resume hooks for the first slot, then IRQ allocation > Add hook "Cirrus Logic PD672X" > Add hook "Cirrus Logic PD672X" Suspend/resume hooks for the second slot. > Add hook "Intel 82365" > Add hook "Intel 82365" Erk. Where the F* did that come from? It looks like pccard_alloc_slot got called with garbage. It would be educational to know the contents of the slot structure on each call, if you could swing that. In particular, it looks like something is showing up looking like a third slot, but not on the Cirrus-like pcic. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711060218.MAA00734>