< 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
>
Are you running CURRENT?
Could you check whether you have at least rev. 101 of
src/sys/i386/apm/apm.c
Nick
1.101 Sun Aug 22 14:48:00 1999 UTC by iwasaki
Diffs to 1.100
Fix `key release event prevent suspend' problem. We don't need
`sleep 1; zzz' trick now.
- APM BIOS Call for suspend/stan
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 B
21 matches
Mail list logo
