Christopher Smith <[EMAIL PROTECTED]> writes:
[...]
> >Signals are a pretty dopey API anyway - so instead of trying to
> >patch them up, why not think of something better for AIO?
>
> You assume that this issue only comes up when you're doing AIO. If
> we do something that makes signals work
Christopher Smith [EMAIL PROTECTED] writes:
[...]
Signals are a pretty dopey API anyway - so instead of trying to
patch them up, why not think of something better for AIO?
You assume that this issue only comes up when you're doing AIO. If
we do something that makes signals work better, we
[...]
> immediate: RAM, on-chip cache, etc.
> fast: Flash reads, ROMs, etc.
> medium:Hard drives, CD-ROMs, 100Mb ethernet, etc.
> slow: Flash writes, floppy disks, CD-WR burners
> packeted: Reads/write should be in as large a packet as possible
>
Stefan Hoffmeister <[EMAIL PROTECTED]> writes:
[...]
> Windows NT/2000 has flags that can be for each CreateFile operation
> ("open" in Unix terms), for instance
>
> FILE_ATTRIBUTE_TEMPORARY
>
> FILE_FLAG_WRITE_THROUGH
> FILE_FLAG_NO_BUFFERING
> FILE_FLAG_RANDOM_ACCESS
>
Dan Kegel <[EMAIL PROTECTED]> writes:
[...]
>A signal number cannot be opened more than once concurrently;
>sigopen() thus provides a way to avoid signal usage clashes
>in large programs.
Signals are a pretty dopey API anyway - so instead of trying to patch
them
Dan Kegel [EMAIL PROTECTED] writes:
[...]
A signal number cannot be opened more than once concurrently;
sigopen() thus provides a way to avoid signal usage clashes
in large programs.
Signals are a pretty dopey API anyway - so instead of trying to patch
them up,
Stefan Hoffmeister [EMAIL PROTECTED] writes:
[...]
Windows NT/2000 has flags that can be for each CreateFile operation
(open in Unix terms), for instance
FILE_ATTRIBUTE_TEMPORARY
FILE_FLAG_WRITE_THROUGH
FILE_FLAG_NO_BUFFERING
FILE_FLAG_RANDOM_ACCESS
[...]
immediate: RAM, on-chip cache, etc.
fast: Flash reads, ROMs, etc.
medium:Hard drives, CD-ROMs, 100Mb ethernet, etc.
slow: Flash writes, floppy disks, CD-WR burners
packeted: Reads/write should be in as large a packet as possible
Marcelo Tosatti <[EMAIL PROTECTED]> writes:
>
> Event Time PID Length Description
>
>
> Trap entry
Marcelo Tosatti <[EMAIL PROTECTED]> writes:
> On 25 Jun 2001, John Fremlin wrote:
>
> >
> > Last year I had the idea of tracing the memory accesses of the system
> > to improve the VM - the traces could be used to test algorithms in
> > userspace. The diffi
Marcelo Tosatti [EMAIL PROTECTED] writes:
On 25 Jun 2001, John Fremlin wrote:
Last year I had the idea of tracing the memory accesses of the system
to improve the VM - the traces could be used to test algorithms in
userspace. The difficulty is of course making all memory accesses
Marcelo Tosatti [EMAIL PROTECTED] writes:
Event Time PID Length Description
Trap entry
Rik van Riel <[EMAIL PROTECTED]> writes:
> On 25 Jun 2001, John Fremlin wrote:
>
> > Last year I had the idea of tracing the memory accesses of the
> > system to improve the VM - the traces could be used to test
> > algorithms in userspace. The difficulty is o
put large amounts of data from
+ * the kernel to userspace
+ *
+ * (c) 2001 John Fremlin released under GPL
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BUFFER_SIZE (1024*1024*1)
+
+char buffer[BUFFER_SIZE];
+
+static DECLARE_WAIT_QUEUE_H
large amounts of data from
+ * the kernel to userspace
+ *
+ * (c) 2001 John Fremlin released under GPL
+ */
+
+#include linux/slab.h
+#include linux/init.h
+#include linux/miscdevice.h
+#include linux/spinlock.h
+#include linux/wait.h
+#include asm/uaccess.h
+#include linux/mm.h
+#include linux
Rik van Riel [EMAIL PROTECTED] writes:
On 25 Jun 2001, John Fremlin wrote:
Last year I had the idea of tracing the memory accesses of the
system to improve the VM - the traces could be used to test
algorithms in userspace. The difficulty is of course making all
memory accesses fault
"David Flynn" <[EMAIL PROTECTED]> writes:
[...]
> ive done the badblock test, and compiled a list of 2302 bad blocks on this
> disk ... however, when running mke2fs -l badblocfile /dev/hdc1
>
> i got this interesting errormessage for every one of the bad blocks :
>
> Bad block 1006290 out of
David Flynn [EMAIL PROTECTED] writes:
[...]
ive done the badblock test, and compiled a list of 2302 bad blocks on this
disk ... however, when running mke2fs -l badblocfile /dev/hdc1
i got this interesting errormessage for every one of the bad blocks :
Bad block 1006290 out of range;
setuid(2) differs from the OpenBSD setuid(2) in that -EPERM is
returned by the syscall even if the euid of the process matches the
uid passed to it.
Either I am non compos or the thing is very wrong. The docs
(man-pages-1.35) say
ERRORS
EPERM The user is not the super-user, and uid
setuid(2) differs from the OpenBSD setuid(2) in that -EPERM is
returned by the syscall even if the euid of the process matches the
uid passed to it.
Either I am non compos or the thing is very wrong. The docs
(man-pages-1.35) say
ERRORS
EPERM The user is not the super-user, and uid
Jeff Golds <[EMAIL PROTECTED]> writes:
[...]
> Please let me know if this is correct, I can provide a simple patch
> if needed. What I am really desiring to know is if there are any
> devices that depend on the apm::send_event(APM_NORMAL_RESUME)
> happening while interrupts are
Jeff Golds [EMAIL PROTECTED] writes:
[...]
Please let me know if this is correct, I can provide a simple patch
if needed. What I am really desiring to know is if there are any
devices that depend on the apm::send_event(APM_NORMAL_RESUME)
happening while interrupts are disabled.
Hi!
Robin Cull and I have OPL3-SA2 isapnp cards. Sometimes we get assigned
the wrong resource set. These cards do not take kindly to Alternate
resources 0:1 Priority acceptable, in fact they are completely broke,
so it is important to us that they get their first choice ;-)
The trouble is that
Hi!
Robin Cull and I have OPL3-SA2 isapnp cards. Sometimes we get assigned
the wrong resource set. These cards do not take kindly to Alternate
resources 0:1 Priority acceptable, in fact they are completely broke,
so it is important to us that they get their first choice ;-)
The trouble is that
Alexander Viro <[EMAIL PROTECTED]> writes:
[...]
> We have ~180 first-order ioctl() methods. Several (my guess would be
Hehe. I suppose you already know about the way strace (@sourceforge)
kind of automatically tries to figure out the args for the common
ones?
[...]
--
Alexander Viro [EMAIL PROTECTED] writes:
[...]
We have ~180 first-order ioctl() methods. Several (my guess would be
Hehe. I suppose you already know about the way strace (@sourceforge)
kind of automatically tries to figure out the args for the common
ones?
[...]
--
Linus Torvalds <[EMAIL PROTECTED]> writes:
[...]
> Nobody really uses it because it would require you to add a line or
> two to your init scripts to pick up the major number from
> /proc/devices, and that's obviously too hard. Much better to just
> hardcode randome numbers, right?
And thereby
"Grover, Andrew" <[EMAIL PROTECTED]> writes:
[...]
> - It's probably easier to put the "event" file in proc, instead of
> dev. This is what the acpi interface does, and eliminates the mknod
> step.
Is this kernel policy? I mean, you could apply the same argument to
all device nodes ;-)
> -
Grover, Andrew [EMAIL PROTECTED] writes:
[...]
- It's probably easier to put the event file in proc, instead of
dev. This is what the acpi interface does, and eliminates the mknod
step.
Is this kernel policy? I mean, you could apply the same argument to
all device nodes ;-)
- perhaps
r management on module unload.
+ * 1.15: Move most of the /dev/apm_bios stuff to drivers/char/boxevent.c
+ * Reject all events by default
+ * (John Fremlin <[EMAIL PROTECTED]>)
*
* APM 1.1 Reference:
*
@@ -186,6 +189,7 @@
#include
#include
#include
+#include
[Stuff about NetBSD pipes snipped]
I'm testing out Manfred's patch for zero copy pipes, and haven't
crashed it yet.
My hardware is a AMD K6-2 (stepping 1) on an ALi M1541 with 320 Mb -
one quite slow 64 Mb stick and one fast 256 Mb stick.
The lmbench bw_pipe showed a performance improvement
[Stuff about NetBSD pipes snipped]
I'm testing out Manfred's patch for zero copy pipes, and haven't
crashed it yet.
My hardware is a AMD K6-2 (stepping 1) on an ALi M1541 with 320 Mb -
one quite slow 64 Mb stick and one fast 256 Mb stick.
The lmbench bw_pipe showed a performance improvement
of the /dev/apm_bios stuff to drivers/char/boxevent.c
+ * Reject all events by default
+ * (John Fremlin [EMAIL PROTECTED])
*
* APM 1.1 Reference:
*
@@ -186,6 +189,7 @@
#include linux/pm.h
#include linux/kernel.h
#include linux/smp_lock.h
+#include linux/boxevent.h
#include asm
Pavel Machek <[EMAIL PROTECTED]> writes:
> > > > I'm wondering if that veto business is really needed. Why not reject
> > > > *all* APM rejectable events, and then let the userspace event handler
> > > > send the system to sleep or turn it off? Anybody au fait with the APM
> > > > spec?
> > >
>
Pavel Machek [EMAIL PROTECTED] writes:
I'm wondering if that veto business is really needed. Why not reject
*all* APM rejectable events, and then let the userspace event handler
send the system to sleep or turn it off? Anybody au fait with the APM
spec?
Because apmd is
This is an attempt at a generic PM event interface for the kernel.
The design is more or less obvious and was laid out in a previous
message. Comments appreciated.
Alan Cox <[EMAIL PROTECTED]> writes:
> > > The entire PM layer for the embedded board I worked on was
> > > 3Kbytes. How small
This is an attempt at a generic PM event interface for the kernel.
The design is more or less obvious and was laid out in a previous
message. Comments appreciated.
Alan Cox [EMAIL PROTECTED] writes:
The entire PM layer for the embedded board I worked on was
3Kbytes. How small will yours
Jamie Lokier <[EMAIL PROTECTED]> writes:
[...]
> Are you sure? A suspend takes about 5-10 seconds on my laptop.
You mean when you tell the apm driver from userspace to suspend?
> (It was noticably faster with 2.3 kernels, btw. Now it spends a second
> or two apparently not noticing the APM
Jamie Lokier [EMAIL PROTECTED] writes:
[...]
Are you sure? A suspend takes about 5-10 seconds on my laptop.
You mean when you tell the apm driver from userspace to suspend?
(It was noticably faster with 2.3 kernels, btw. Now it spends a second
or two apparently not noticing the APM event
Pavel Machek <[EMAIL PROTECTED]> writes:
[...]
> > I'm wondering if that veto business is really needed. Why not reject
> > *all* APM rejectable events, and then let the userspace event handler
> > send the system to sleep or turn it off? Anybody au fait with the APM
> > spec?
>
> My thinkpad
Pavel Machek [EMAIL PROTECTED] writes:
[...]
I'm wondering if that veto business is really needed. Why not reject
*all* APM rejectable events, and then let the userspace event handler
send the system to sleep or turn it off? Anybody au fait with the APM
spec?
My thinkpad actually
Patrick Mochel <[EMAIL PROTECTED]> writes:
[...]
> > > I can see at least two types of events - (forgive the lack of colorful
> > > terminology) passive and active. Passive events are simply providing
> > > status updates, much like the events described above. These are simply so
> > > some UI
Patrick Mochel <[EMAIL PROTECTED]> writes:
[...]
> > Solution. Have a special procfs or dev node that any number of people
> > can select(2) or read(2). Protocol text. Syntax:
> >
> >
> >
> > Where is one of the strings
> > OFF,SLEEP,WAKE,EMERGENCY,POWERCHANGE, is a space
Patrick Mochel <[EMAIL PROTECTED]> writes:
> > > IMHO the pm interface should be split up as following:
> >
> > Nobody has disagreed: therefore this separation must be perfect ;-)
>
> I once heard that patience is a virtue. :)
>
> > > (1) Battery status, power status, UPS status
Patrick Mochel [EMAIL PROTECTED] writes:
IMHO the pm interface should be split up as following:
Nobody has disagreed: therefore this separation must be perfect ;-)
I once heard that patience is a virtue. :)
(1) Battery status, power status, UPS status polling. It
Patrick Mochel [EMAIL PROTECTED] writes:
[...]
Solution. Have a special procfs or dev node that any number of people
can select(2) or read(2). Protocol text. Syntax:
event WS subsystem WS description LF
Where event is one of the strings
Patrick Mochel [EMAIL PROTECTED] writes:
[...]
I can see at least two types of events - (forgive the lack of colorful
terminology) passive and active. Passive events are simply providing
status updates, much like the events described above. These are simply so
some UI can notify the
John Fremlin <[EMAIL PROTECTED]> writes:
[...]
> IMHO the pm interface should be split up as following:
Nobody has disagreed: therefore this separation must be perfect ;-)
> (1) Battery status, power status, UPS status polling. It
> should be possible for lo
"Grover, Andrew" <[EMAIL PROTECTED]> writes:
[...]
> > ACPI != PM. I don't see why ACPI details should be exposed to PM
> > interface at all.
>
> ACPI has by far the richest set of capabilities. It is a superset of
> APM. Therefore a combined APM/ACPI interface is going to look a lot
> like
Avery Pennarun <[EMAIL PROTECTED]> writes:
> On Wed, Apr 18, 2001 at 09:10:37PM +0100, Alan Cox wrote:
>
> > > willing to exercise this power. We would not break compatibility with
> > > any std kernel by instead having a apmd send a "reject all" ioctl
> > > instead, and so deal with events
Alan Cox <[EMAIL PROTECTED]> writes:
> > willing to exercise this power. We would not break compatibility
> > with any std kernel by instead having a apmd send a "reject all"
> > ioctl instead, and so deal with events without having the pressure
> > of having to reject or accept them, and let us
Simon Richter <[EMAIL PROTECTED]> writes:
[...]
> Yes, that will be a separate daemon that will also get the
> events. But I think it's a good idea to have a simple interface that
> allows the user to run arbitrary commands when ACPI events occur,
> even without acpid running (think of
"Grover, Andrew" <[EMAIL PROTECTED]> writes:
[...]
> Fair enough. I don't think I would be out of line to say that our
> resources are focused on enabling full ACPI functionality for Linux,
> including a full-featured PM policy daemon. That said, I don't think
> there's anything precluding the
Alan Cox <[EMAIL PROTECTED]> writes:
> > I'm wondering if that veto business is really needed. Why not reject
> > *all* APM rejectable events, and then let the userspace event handler
> > send the system to sleep or turn it off? Anybody au fait with the APM
> > spec?
>
> Because apmd is
Alan Cox [EMAIL PROTECTED] writes:
I'm wondering if that veto business is really needed. Why not reject
*all* APM rejectable events, and then let the userspace event handler
send the system to sleep or turn it off? Anybody au fait with the APM
spec?
Because apmd is optional
The veto
"Grover, Andrew" [EMAIL PROTECTED] writes:
[...]
Fair enough. I don't think I would be out of line to say that our
resources are focused on enabling full ACPI functionality for Linux,
including a full-featured PM policy daemon. That said, I don't think
there's anything precluding the use
Simon Richter [EMAIL PROTECTED] writes:
[...]
Yes, that will be a separate daemon that will also get the
events. But I think it's a good idea to have a simple interface that
allows the user to run arbitrary commands when ACPI events occur,
even without acpid running (think of singleuser
Alan Cox [EMAIL PROTECTED] writes:
willing to exercise this power. We would not break compatibility
with any std kernel by instead having a apmd send a "reject all"
ioctl instead, and so deal with events without having the pressure
of having to reject or accept them, and let us remove
Avery Pennarun [EMAIL PROTECTED] writes:
On Wed, Apr 18, 2001 at 09:10:37PM +0100, Alan Cox wrote:
willing to exercise this power. We would not break compatibility with
any std kernel by instead having a apmd send a "reject all" ioctl
instead, and so deal with events without having
"Grover, Andrew" [EMAIL PROTECTED] writes:
[...]
ACPI != PM. I don't see why ACPI details should be exposed to PM
interface at all.
ACPI has by far the richest set of capabilities. It is a superset of
APM. Therefore a combined APM/ACPI interface is going to look a lot
like an ACPI
John Fremlin [EMAIL PROTECTED] writes:
[...]
IMHO the pm interface should be split up as following:
Nobody has disagreed: therefore this separation must be perfect ;-)
(1) Battery status, power status, UPS status polling. It
should be possible for lots of processes to do
Alan Cox <[EMAIL PROTECTED]> writes:
[...]
> I would tend to agree here. If you want to wire it to init the fine
> but pm is basically message passing kernel->user and possibly
> message reply to allow veto/approve. APM provides a good API for
> this and there is a definite incentive to make
"Grover, Andrew" <[EMAIL PROTECTED]> writes:
> [do we want to move this to linux-power?]
I'm happy to as long as I'm cc'd.
[...]
IMHO the pm interface should be split up as following:
(1) Battery status, power status, UPS status polling. It
should be possible for lots of
"Grover, Andrew" <[EMAIL PROTECTED]> writes:
> Hi Pavel,
>
> I think init is doing a perfect job WRT UPSs because this is a
> trivial application of power management. init wasn't really meant
> for this. According to its man page:
>
> "init...it's primary role is to create processes from a
"Grover, Andrew" <[EMAIL PROTECTED]> writes:
> > From: Pavel Machek [mailto:[EMAIL PROTECTED]]
> > There are 32 signals, and signals can carry more information, if
> > required. I really think doing it way UPS-es are done is right
> > approach.
> I would think that it would make sense to keep
"Grover, Andrew" [EMAIL PROTECTED] writes:
From: Pavel Machek [mailto:[EMAIL PROTECTED]]
There are 32 signals, and signals can carry more information, if
required. I really think doing it way UPS-es are done is right
approach.
I would think that it would make sense to keep shutdown
"Grover, Andrew" [EMAIL PROTECTED] writes:
Hi Pavel,
I think init is doing a perfect job WRT UPSs because this is a
trivial application of power management. init wasn't really meant
for this. According to its man page:
"init...it's primary role is to create processes from a script in
"Grover, Andrew" [EMAIL PROTECTED] writes:
[do we want to move this to linux-power?]
I'm happy to as long as I'm cc'd.
[...]
IMHO the pm interface should be split up as following:
(1) Battery status, power status, UPS status polling. It
should be possible for lots of
Alan Cox [EMAIL PROTECTED] writes:
[...]
I would tend to agree here. If you want to wire it to init the fine
but pm is basically message passing kernel-user and possibly
message reply to allow veto/approve. APM provides a good API for
this and there is a definite incentive to make ACPI use
Andrew Morton <[EMAIL PROTECTED]> writes:
[...]
> None of these will work. The problems with globally setting
> exit_signal to SIGCHLD are that
>
> a) If the parent does waitpid(pid, status, __WCLONE), the
>waitpid will fail. request_module() does this. I don't
>know _why_ it does
Andrew Morton [EMAIL PROTECTED] writes:
[...]
None of these will work. The problems with globally setting
exit_signal to SIGCHLD are that
a) If the parent does waitpid(pid, status, __WCLONE), the
waitpid will fail. request_module() does this. I don't
know _why_ it does this.
"Adam J. Richter" <[EMAIL PROTECTED]> writes:
> "John Fremlin" <[EMAIL PROTECTED]> writes:
> > "Adam J. Richter" <[EMAIL PROTECTED]> writes:
> >>Guess why you're seeing this email. That's right. Linux-2.4.3's
> >&g
"Adam J. Richter" <[EMAIL PROTECTED]> writes:
[...]
> It turned out that the particular unix-like system on which
> these benchmarks were taken had a version of fork that did not run
> the child first. As it was explained to me then, most of the time,
> the child process from a fork
"Adam J. Richter" [EMAIL PROTECTED] writes:
[...]
It turned out that the particular unix-like system on which
these benchmarks were taken had a version of fork that did not run
the child first. As it was explained to me then, most of the time,
the child process from a fork will do
"Adam J. Richter" [EMAIL PROTECTED] writes:
"John Fremlin" [EMAIL PROTECTED] writes:
"Adam J. Richter" [EMAIL PROTECTED] writes:
Guess why you're seeing this email. That's right. Linux-2.4.3's
fork() does not run the child first.
[...] If an app want
"Grover, Andrew" <[EMAIL PROTECTED]> writes:
[...]
> > > > + printk ("acpi: Power button pressed!\n");
> >
> > [...]
> >
> > > > + printk("acpi: Sleep button pressed!\n");
> >
> > Do you think you could keep the above part of the patch? It would be
> > nice to
Pavel Machek <[EMAIL PROTECTED]> writes:
> Hi!
>
> > This is not correct, because we want the power button to be
> > configurable. The user should be able to redefine the power
> > button's action, perhaps to only sleep the system. We currently
> > surface button events to acpid, which then
John R Lenton <[EMAIL PROTECTED]> writes:
[...]
> Just today a friend saw my box shutdown via the powerbutton and
> wondered if he coudln't set his up to trigger a different event
> (actually two: he wanted his sister - the guilty party - zapped, and
> a webcam shot of her face to prove it)...
"Grover, Andrew" <[EMAIL PROTECTED]> writes:
> This is not correct, because we want the power button to be
> configurable. The user should be able to redefine the power
> button's action, perhaps to only sleep the system. We currently
> surface button events to acpid, which then can do the
"Grover, Andrew" [EMAIL PROTECTED] writes:
This is not correct, because we want the power button to be
configurable. The user should be able to redefine the power
button's action, perhaps to only sleep the system. We currently
surface button events to acpid, which then can do the right
John R Lenton [EMAIL PROTECTED] writes:
[...]
Just today a friend saw my box shutdown via the powerbutton and
wondered if he coudln't set his up to trigger a different event
(actually two: he wanted his sister - the guilty party - zapped, and
a webcam shot of her face to prove it)...
That
Pavel Machek [EMAIL PROTECTED] writes:
Hi!
This is not correct, because we want the power button to be
configurable. The user should be able to redefine the power
button's action, perhaps to only sleep the system. We currently
surface button events to acpid, which then can do the
"Grover, Andrew" [EMAIL PROTECTED] writes:
[...]
+ printk ("acpi: Power button pressed!\n");
[...]
+ printk("acpi: Sleep button pressed!\n");
Do you think you could keep the above part of the patch? It would be
nice to know how much of ACPI was
"Richard B. Johnson" <[EMAIL PROTECTED]> writes:
> On 4 Apr 2001, John Fremlin wrote:
> >
> > Hi Oliver!
> >
> > Oliver Neukum <[EMAIL PROTECTED]> writes:
> >
> > > is there a way to let all other runable tasks run until they bl
"Richard B. Johnson" [EMAIL PROTECTED] writes:
On 4 Apr 2001, John Fremlin wrote:
Hi Oliver!
Oliver Neukum [EMAIL PROTECTED] writes:
is there a way to let all other runable tasks run until they block
or return to user space, before the task wishing to do so is ru
Hi Oliver!
Oliver Neukum <[EMAIL PROTECTED]> writes:
> is there a way to let all other runable tasks run until they block
> or return to user space, before the task wishing to do so is run
> again ?
Are you trying to do this in kernel or something? From userspace you
can use nice(2) then
Hi Oliver!
Oliver Neukum [EMAIL PROTECTED] writes:
is there a way to let all other runable tasks run until they block
or return to user space, before the task wishing to do so is run
again ?
Are you trying to do this in kernel or something? From userspace you
can use nice(2) then
[EMAIL PROTECTED] writes:
[...]
> > AFAICS. I hacked together the following patch for it a while ago,
> > which updated APM_IOC_REJECT for slightly more recent kernels (be
> > warned, I think I made some mistakes)
>
> Thanks for this, I will review it and post a patch based on it (with
> due
[EMAIL PROTECTED] writes:
[...]
AFAICS. I hacked together the following patch for it a while ago,
which updated APM_IOC_REJECT for slightly more recent kernels (be
warned, I think I made some mistakes)
Thanks for this, I will review it and post a patch based on it (with
due
David Balazic <[EMAIL PROTECTED]> writes:
> John Fremlin wrote:
[...]
> > > To implement off-button you only need the APM_IOC_REJECT ioctl and
> >
> > The problem on my computer with my (re)implementation of
> > APM_IOC_REJECT is that the screen
David Balazic [EMAIL PROTECTED] writes:
John Fremlin wrote:
[...]
To implement off-button you only need the APM_IOC_REJECT ioctl and
The problem on my computer with my (re)implementation of
APM_IOC_REJECT is that the screen goes into powersaving when the user
suspend is received
David Balazic <[EMAIL PROTECTED]> writes:
> John Fremlin wrote:
> >
> > David Balazic <[EMAIL PROTECTED]> writes:
[...]
> > The maintainer hasn't the time to do it. He promised me he would in
> > February, when I telephone, but hasn't bothered to do
David Balazic [EMAIL PROTECTED] writes:
John Fremlin wrote:
David Balazic [EMAIL PROTECTED] writes:
[...]
The maintainer hasn't the time to do it. He promised me he would in
February, when I telephone, but hasn't bothered to do anything
AFAICS. I hacked together the following
nd engage power management earlier.
* Disengage power management on module unload.
+ * 1.15: Add APM_IOC_REJECT ioctl, based on a patch from Stephen
+ * Rothwell but apparently written by Craig Markwardt
+ * <[EMAIL PROTECTED]>.
+ * John Fremlin <[EMAIL PROTECTED]>
gage power management on module unload.
+ * 1.15: Add APM_IOC_REJECT ioctl, based on a patch from Stephen
+ * Rothwell but apparently written by Craig Markwardt
+ * [EMAIL PROTECTED].
+ * John Fremlin [EMAIL PROTECTED]
*
* APM 1.1 Reference:
*
@@ -301,6 +306,
Jeff Garzik <[EMAIL PROTECTED]> writes:
> John Fremlin wrote:
> > Why not set up the device driver to handle PM events itself. See
> > Documentation/pm.txt under Driver Interface.
>
> For PCI drivers, you implement the ::suspend and ::remove hooks.
>
Thomas Hood <[EMAIL PROTECTED]> writes:
> Sometimes modules need to be reloaded in order
> to cause some sort of reinitialization (of the
> driver or of the hardware) to occur.
Why not set up the device driver to handle PM events itself. See
Documentation/pm.txt under Driver Interface.
I have
Thomas Hood [EMAIL PROTECTED] writes:
Sometimes modules need to be reloaded in order
to cause some sort of reinitialization (of the
driver or of the hardware) to occur.
Why not set up the device driver to handle PM events itself. See
Documentation/pm.txt under Driver Interface.
I have a
Jeff Garzik [EMAIL PROTECTED] writes:
John Fremlin wrote:
Why not set up the device driver to handle PM events itself. See
Documentation/pm.txt under Driver Interface.
For PCI drivers, you implement the ::suspend and ::remove hooks.
I have a race free version of pm_send_all if you
Joseph Pingenot <[EMAIL PROTECTED]> writes:
> When suspending my laptop (Toshiba Satellite 1605CDS; BIOS set to
> suspend to disk) with Debian 2.2r2's 'apm -s', the screen blanks and
> then the system locks up hard (not even the power button works). In
Go hassle Stephen Rothwell <[EMAIL
1 - 100 of 141 matches
Mail list logo
