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 sche
"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
"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 righ
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)...
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 ca
"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
"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
"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
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 t
"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 s
"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 sc
"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 proce
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 ACP
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
"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
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 singleus
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
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 wit
"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
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
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 polli
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 char
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 c
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
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 e
Specifically, this part:
@@ -2324,11 +2309,17 @@
sense.ascq == 0x04)
return CDS_DISC_OK;
+
+ /*
+* If not using Mt Fuji extended media tray reports,
+* just return TRAY_OPEN since ATAPI doesn't provide
+
Jens Axboe <[EMAIL PROTECTED]> writes:
[...]
> > You know all about this stuff, so probably I am mistaken.
> > However, my copy of SFF8020-r2.6 everywhere has
> > "Sense 02 ASC 3A: Medium not present" without giving
> > subcodes to distinguish Tray Open from No Disc.
> > So, it seems to me that
Unfortunately, the APM maintainer, Stephen Rothwell, seems to have
gone into hibernation (pun) and is not responding to emails.
bradley mclain <[EMAIL PROTECTED]> writes:
> apm --suspend causes my system to hang under 2.4.2 and 2.4.2ac1. it
> was working fine under 2.4.1ac19. looking at syslog
"Michael Johnson" <[EMAIL PROTECTED]> writes:
> >> You know all about this stuff, so probably I am mistaken.
> >> However, my copy of SFF8020-r2.6 everywhere has
> >> "Sense 02 ASC 3A: Medium not present" without giving
> >> subcodes to distinguish Tray Open from No Disc.
> >> So, it seems to me
Alan Cox <[EMAIL PROTECTED]> writes:
> > the sound card is a yamaha YMF-744B. i hadn't been
> > compiling with sound support (i dont care about sound
> > on my laptop), but when i got 2.4.2 i decided to try,
> > and now i'm pretty sure that was the problem.
>
> The Yamaha sound driver doesnt h
Alan Cox <[EMAIL PROTECTED]> writes:
> > Why not use kernel/pm.c:pm_register? Then you can either refuse
> > suspend or have a proper workaround.
>
> Feel free to provide code.
You have me there - I should have realised who I was writing to ;-)
[...]
> I dont have the hardware
I neither.
Boris Dragovic <[EMAIL PROTECTED]> writes:
> i have compaq presario 1245 and kernel 2.4.2 does not do power off on
> shutdown although all necessary kernel options are compiled in..
Go hassle Stephen Rothwell <[EMAIL PROTECTED]> about this. He loves
feedback.
[...]
--
http://www.pe
Daniel Stutz <[EMAIL PROTECTED]> writes:
> APM support for Lifebook C 6185 is broken since 2.4.1-ac1.
> While trying to go in suspend mode the system hangs.
Go hassle Stephen Rothwell <[EMAIL PROTECTED]> about this. He likes
feedback.
[...]
--
http://www.penguinpowered.com/~vii
-
T
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 PROTEC
nagement on module unload.
+ * --- Modified to support new pm_event API (John Fremlin
+ * <[EMAIL PROTECTED]>)
*
* APM 1.1 Reference:
*
@@ -884,30 +886,65 @@
#endif
}
+static int soft_suspend()
+{
+ struct pm_event pe;
+ memset(&pe,0,sizeof pe);
+
+ pe.pe_state = PM_STATE_S
Hi!
Andrew Morton <[EMAIL PROTECTED]> writes:
> Could you please use call_usermodehelper() in this patch
> rather than exec_usermodehelper()? I want to kill
> exec_usermodehelper() sometime.
The reason I used exec_usermodehelper is that I wanted to waitpid on
the process to see how it exited
"Albert D. Cahalan" <[EMAIL PROTECTED]> writes:
> > 1) top (procps-2.0.7) gives me the messages :
> > 'bad data in /proc/uptime'
> > 'bad data in /proc/loadavg'
> > cat /proc/uptime
> > 1435.30 904.74
> > cat /proc/loadavg
> > 0.01 0.21 0.29 1/17 19444
> > What is wrong ?
You probably have loc
Against 2.4.0.
--- linux/include/linux/rtc.h~ Tue Jul 11 19:18:53 2000
+++ linux/include/linux/rtc.h Sun Jan 21 16:06:53 2001
@@ -6,7 +6,7 @@
* Copyright (C) 1999 Hewlett-Packard Co.
* Copyright (C) 1999 Stephane Eranian <[EMAIL PROTECTED]>
*/
-#ifndef _LINUX_RTC_H
+#ifndef _LINUX_RTC_H
"Adam J. Richter" <[EMAIL PROTECTED]> writes:
> linux-2.4.1-pre9/include/linux/acpi.h contains declares the routine
> acpi_get_rsdp_ptr returning the kernel-only type "u64", without
> bracketing the declaration in "#ifdef __KERNEL__...#endif".
> Consequently, a user level program that attempts t
y force option. (Jan 5, 1999)
* Christoph Hellwig Adapted to module_init/module_exit (Mar 4, 2000)
- *
+ * John FremlinDo ISA PnP (Oct 27, 2000)
*/
#include
#include
#include
+#include
+
#include "sound_config.h"
#include "ad1848.h"
@@ -92
Steven Cole <[EMAIL PROTECTED]> writes:
[...]
> In each case, the task and the tools used are the same. The only
> difference was the kernel used. In both cases, 2.2.18 won by 3%.
> Its comparing apples to apples and oranges to oranges. Granted 3%
> isn't very much, but I would have guessed th
John Summerfield <[EMAIL PROTECTED]> writes:
[...]
> 3) When I then switch back to a virtual console, the screen blanks
> and switches to power-saving mode.
Which powersave mode? There are three, IIRC. You can tell them apart
by the color of or whether the light blinks on some monitors.
If th
Jogchem de Groot <[EMAIL PROTECTED]> writes:
[...]
> 1: Kernel panics on sending large ping packets using 'ping'
Not for me.
[...]
> 4: Linux version 2.4.0-test12
Linux 2.4.0-test13-pre4-tosatti
[...]
> 6: #!/bin/sh
> ping -s 6 127.0.0.1
Ping from netkit-combo-0.17:
# ping -s 60
On Tue Apr 04 2000 - 23:19:12 EDT, Stephen Rothwell posted a patch to linux-kernel.
See http://boudicca.tux.org/hypermail/linux-kernel/2000week15/0481.html
To quote:
This patch (against 2.3.99pre4-4) does the following:
Allow user mode programs to reject standby and suspend operations.
ule unload/load.
* Enable and 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]>.
+ *
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
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.
>
>
Enable and 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 P
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 both
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
[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 ac
When the IP address of an interface changes, TCP connections with the
old source address are useless. Applications are not notified of this
and time out ordinarily, just as if nothing had happened. This is
behaviour isn't very helpful when you have a dynamic IP and know
you're probably not going t
"Albert D. Cahalan" <[EMAIL PROTECTED]> writes:
[...]
> > I patched userspace ppp-2.4.0 to use this functionality. It would be
> > better if SIOCKILLADDR were not used until we are sure that the new IP
> > is in fact different from the old one, but pppd in demand mode would
>
> I get the same IP
Jamie Lokier <[EMAIL PROTECTED]> writes:
[...]
> The important thing is that the tunnel is destroyed and recreated
> (it has to be, it is over different underlying link addresses). I
> do not want that to destroy the connections from the tunnelled
> address.
No connections at all will be destr
Robert Kaiser <[EMAIL PROTECTED]> writes:
> On Die, 06 Feb 2001 you wrote:
> > But paring down the startup scripts is a good idea. For something like an embedded
> > device, you might even want to go with a custom init,
Plug: How about jinit (my init) ;-)
http://www.penguinpowered.co
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?
[...]
--
http:
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 i
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.
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 do
"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 r
ce that can output 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 DECLA
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
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:
>
> Event Time PID Length Description
>
>
> Trap entry 991,29
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
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
> FILE
[...]
> 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
>
>
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 be
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
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?
> > >
>
[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
Disengage power 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
#in
"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 ;-)
> - per
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 a
74 matches
Mail list logo
