Hi
I have a Compaq Armada E500 and the apm support doesnt work. It seems that
the kernel doesnt find the apm controller just that it is on the pci bus. I
am using freebsd 5.0-20001112-current and have tried with both the generic
kernel and my custom kernel. in the kernel configuration I have just
< said:
[I wrote:]
> : And designs based on the Intel PIIX4 will generate SMI# interrupts for
> : whichever activities are programmed in the BIOS, completely bypassing
> : the traditional interrupt mechanism.
> So does that mean if we do disable them at the PIC level we'll be OK?
No, it means i
> In message <[EMAIL PROTECTED]> Mike Smith writes:
> : It's reasonable to assume this, yes. However it's also worth bearing
> : in mind that since the BIOS isn't using these interrupts to _detect_
> : activity, turning them off is pretty pointless.
>
> Then why does the key up event cause the
> In message <[EMAIL PROTECTED]> Garrett
> Wollman writes:
> : And designs based on the Intel PIIX4 will generate SMI# interrupts for
> : whichever activities are programmed in the BIOS, completely bypassing
> : the traditional interrupt mechanism.
>
> So does that mean if we do disable them at
In message <[EMAIL PROTECTED]> Mike Smith writes:
: It's reasonable to assume this, yes. However it's also worth bearing
: in mind that since the BIOS isn't using these interrupts to _detect_
: activity, turning them off is pretty pointless.
Then why does the key up event cause the suspend to
In message <[EMAIL PROTECTED]> Garrett
Wollman writes:
: And designs based on the Intel PIIX4 will generate SMI# interrupts for
: whichever activities are programmed in the BIOS, completely bypassing
: the traditional interrupt mechanism.
So does that mean if we do disable them at the PIC level
In message <[EMAIL PROTECTED]>, Mike Smith writes:
>> In message <[EMAIL PROTECTED]>, Garrett Wollman writes:
>> >< said:
>> >
>> >> Actually, that's almost entirely system-dependant. The BIOS may well
>> >> poll the keyboard controller/USB controller, for example.
>> >
>> >And designs based on
> In message <[EMAIL PROTECTED]>, Garrett Wollman writes:
> >< said:
> >
> >> Actually, that's almost entirely system-dependant. The BIOS may well
> >> poll the keyboard controller/USB controller, for example.
> >
> >And designs based on the Intel PIIX4 will generate SMI# interrupts for
> >which
In message <[EMAIL PROTECTED]>, Garrett Wollman writes:
>< said:
>
>> Actually, that's almost entirely system-dependant. The BIOS may well
>> poll the keyboard controller/USB controller, for example.
>
>And designs based on the Intel PIIX4 will generate SMI# interrupts for
>whichever activities
< said:
> Actually, that's almost entirely system-dependant. The BIOS may well
> poll the keyboard controller/USB controller, for example.
And designs based on the Intel PIIX4 will generate SMI# interrupts for
whichever activities are programmed in the BIOS, completely bypassing
the traditiona
> In message <[EMAIL PROTECTED]> Nate Williams writes:
> : > I think we need to set the interrupt mask to 0 in the PIC.
> :
> : I don't think makes any difference, since the APM Bios is in charge of
> : what happens at this point, and the BIOS is below the level of the OS.
> :
>
> The theory is
In message <[EMAIL PROTECTED]> Nate Williams writes:
: > I think we need to set the interrupt mask to 0 in the PIC.
:
: I don't think makes any difference, since the APM Bios is in charge of
: what happens at this point, and the BIOS is below the level of the OS.
:
The theory is that no more in
> : And it seems there still are other devices which wake your PC up in
> : 2-3 mins time.
> : Hmmm, anyone has ideas?
>
> I think we need to set the interrupt mask to 0 in the PIC.
I don't think makes any difference, since the APM Bios is in charge of
what happens at this point, and the BIOS is
In message <[EMAIL PROTECTED]> Mitsuru IWASAKI writes:
: And it seems there still are other devices which wake your PC up in
: 2-3 mins time.
: Hmmm, anyone has ideas?
I think we need to set the interrupt mask to 0 in the PIC. Or at
least disable the interrupts that we know about from a driver p
Kazutaka YOKOTA wrote:
> The PS/2 mouse generates interrupt when /dev/psm0 is open and
> the user moves the mouse.
>
> If you are running moused or X when you suspend the system, /dev/psm0
> is left open and might generate interrupts. I think modern motherboard
> BIOSes have a setup menu that l
>> OK. Probably `slept 00:00:00 - 00:00:40' problem was caused by PS/2
>> mouse, I think. Do we need something to do with psm on suspending as
>> well as resuming?
>
>Im not sure anything needs to be done for PS/2.. check out these
>results..
The PS/2 mouse generates interrupt when /dev/psm0 is
Mitsuru IWASAKI wrote:
> OK. Probably `slept 00:00:00 - 00:00:40' problem was caused by PS/2
> mouse, I think. Do we need something to do with psm on suspending as
> well as resuming?
Im not sure anything needs to be done for PS/2.. check out these
results..
> > > > ed1: irq 3 at device 9.0
[ CC'ed current again.]
> > I suspect some devices generate interrupt during suspending state,
> > especially PS/2 mouse. Disabling the device driver or disconnecting
> > the device from PC might solve the problem. Could you try one by one?
> >
> > > psm0: irq 12 on atkbdc0
>
> > I had the s
Hi,
I'd like to have full output of dmesg to investigate hardware
interference in apm. Could you send me it later?
> 'apm -Z' for standby jumps into standby mode for like.. an instant, then
> comes right back out (while playing mp3)
[snip]
> 'zzz' or 'apm -z' for suspend jumps into suspend mode
Yeh, i just got all the latest sources (as of 24th August) and made em:
$Id: apm.c,v 1.103 1999/08/23 20:58:36 phk Exp $
So yes i do have that recent version, but my problems persist. :(
Nick Hibma wrote:
>
> Are you running CURRENT?
>
> Could you check whether you have at least rev. 101 of
>
all for suspend/standby now should be issued with delay.
- Delay for suspend/standby can be adjusted by using sysctl(8) interface
(eg. sysctl -w machdep.apm_suspend_delay=3).
On Tue, 24 Aug 1999, Mike Muir wrote:
> Ive been following the apm problems and changes in apm threads in hope
>
Ive been following the apm problems and changes in apm threads in hope
that I would fix the problems that I too am having.
I am using the latest sources for apm, apmconf and apmd, as well as the
kernel. (as of 23/8/99, NZST, which is yesterday evening)
dmesg is:
apm0: on motherboard
apm: APM
Mitsuru IWASAKI wrote:
> Ah, If you want to reject the standby request from BIOS while the
> system is active, then apmd would be useful. You can configure it like
> this:
> in /etc/apmd.conf:
> apm_event PMEV_STANDBYREQ {
> reject;
Thanks.
> I guess your disks are still in a SLEEP aft
Hi, sorry to late.
> > 1. Standby by PM timer in BIOS setting fails with the system activity.
>
> If by fails you mean enters standby mode, then yes the computer enters
> standby mode while the system is active, after the period of time set in
> the bios, as long as no keys have been pressed on
> Hi,
>
> My understanding on your problems is:
> 1. Standby by PM timer in BIOS setting fails with the system activity.
If by fails you mean enters standby mode, then yes the computer enters
standby mode while the system is active, after the period of time set in
the bios, as long as no keys hav
Hi,
My understanding on your problems is:
1. Standby by PM timer in BIOS setting fails with the system activity.
2. No new process can be started after resume.
Is it correct?
1. My laptops also fails if the console or window is updating by the
output from running commands. But standby on oth
Hi,
Apm does not seem to be behaving correctly on my computer (running
yesterday's CURRENT)
eg: with a make world running, the following happens after about 15 mins
of not touching the keyboard.
Received APM Event: PMEV_STANDBYREQ
Execute APM hook "pcm suspend handler"
Called APM sound suspend
27 matches
Mail list logo
