On Mon, 9 Oct 2000, Ingo Molnar wrote:
> On Mon, 9 Oct 2000, Rik van Riel wrote:
>
> > Would this complexity /really/ be worth it for the twice-yearly OOM
> > situation?
>
> the only reason i suggested this was the init=/bin/bash, 4MB
> RAM, no swap emergency-bootup case. We must not kill init i
On Mon, Oct 09, 2000 at 10:28:38PM +0100, Alan Cox wrote:
> > Sounds like one needs in addition some mechanism for servers to "charge" clients
>for
> > consumption. X certainly knows on behalf of which connection resources
> > are created; the OS could then transfer this back to the appropriate c
On Mon, 9 Oct 2000, David Ford wrote:
> Not if "init" is a particular program running on a router floppy for
> example. The system may be designed to be a router and the userland
> monitor/control program is the only thing that runs and consumes 90% of the
> memory. If a forked or spawned proce
On Mon, 9 Oct 2000, Rik van Riel wrote:
> Would this complexity /really/ be worth it for the twice-yearly OOM
> situation?
the only reason i suggested this was the init=/bin/bash, 4MB RAM, no swap
emergency-bootup case. We must not kill init in that case - if the current
code doesnt then great
> Sounds like one needs in addition some mechanism for servers to "charge" clients for
> consumption. X certainly knows on behalf of which connection resources
> are created; the OS could then transfer this back to the appropriate client
> (at least when on machine).
Definitely - and this is pres
On Mon, 9 Oct 2000, Ingo Molnar wrote:
> On Mon, 9 Oct 2000, Alan Cox wrote:
>
> > Lets kill a 6 week long typical background compute job because
> > netscape exploded (and yes netscape has a child process)
>
> in the paragraph you didnt quote i pointed this out and
> suggested adding all parent
On Mon, Oct 09 2000, Rick Haines wrote:
> I'm having real trouble mounting a dvd (udf filesystem) in my Pioneer
> 104S drive. It usually failes with:
> mount: wrong fs type, bad option, bad superblock on /dev/dvd,
>or too many mounted file systems
> but it succeeds sometimes. For a while
> Sender: [EMAIL PROTECTED]
> From: "Andi Kleen" <[EMAIL PROTECTED]>
> Date: Mon, 9 Oct 2000 22:58:22 +0200
> To: Linus Torvalds <[EMAIL PROTECTED]>
> Cc: Andi Kleen <[EMAIL PROTECTED]>, Ingo Molnar <[EMAIL PROTECTED]>,
> Andrea Arcangeli <[EMAIL PROTECTED]>,
> Rik van Rie
> (to alan)
>
> Alan Cox wrote:
>
> > > Then spam the console loudly with printk, but don't destroy the whole machine.
> > > Init should only get killed if it REALLY is taking a lot of memory. On a 4 or
>8meg
> >
> > If init dies the kernel hangs solid anyway
>
> yes, i retracted that in my next
> > it's set to mps 1.1. linux has issues with 1.4?
>
> The USB code didn't like it for some SMP motherboards a while ago. This
> should be cured now, but is a good place to start if you are having
> problems.
Linux handles 1.1 and 1.4. Some 1.4 setups were buggy with respect to USB
interrupt
[EMAIL PROTECTED] (Frank de Lange) wrote..
> Subject says it all... If I select 'Winchip 2' or 'Winchip 2A/Winchip 3'
> for 'Processor Family' and try to boot the kernel on an iopener with a
> Winchip 2A, the show stops right after the 'decompressing the
> kernel...' line is displayed. Nothin
On Sun, Oct 08, 2000 at 09:27:09PM +0100, Kenn Humborg wrote:
> I'm working on the VAX port and the reason I ask is that the
> VAX has separate stack pointers for user, kernel and interrupt
> contexts. Therefore, the current = (SP & ~8192) hack will give
> completely bogus results when handling
On Mon, 9 Oct 2000, Alan Cox wrote:
> Lets kill a 6 week long typical background compute job because
> netscape exploded (and yes netscape has a child process)
in the paragraph you didnt quote i pointed this out and suggested adding
all parent's badness value to children as well - so we'd end u
On Sun, Oct 08, 2000 at 05:05:45PM -0600, [EMAIL PROTECTED] wrote:
> > > BTW: there is an implicit reference to "current" in smp_processor_id.
> >
> > Yes, on architectures that use current->processor that is an exception
> > to the rule. After all, you know for sure that you're still on the
On Sun, Oct 08, 2000 at 04:19:01PM -0700, Mitchell Blank Jr wrote:
> Some do (look at asm-sparc/smp.h). However, linux does everything possible
> to make dereferencing "current" as fast as possible, so actually just
> looping it up there is pretty damn efficient. We need to keep track of the
>
On Sun, Oct 08, 2000 at 04:36:09PM -0600, [EMAIL PROTECTED] wrote:
> Looking at the code, I don't see any places where "current" is not valid.
> Got some examples?
More a design principle than a real problem.
> BTW: there is an implicit reference to "current" in smp_processor_id.
Which is v
> So, as far as I can see, there are no conflicts between aha1542
> and aha1740 in the sense that the former would try to handle the latter.
> Conversely, that aha1740 also seems to test that it has the right card
> in aha1740_test_port().
> Maybe there is no ordering restriction?
For 1542/1740 I
On Sat, Sep 16, 2000 at 07:22:38PM +0200, Alain Knaff wrote:
> The following patch (against 2.4.0-test8) restores floppy ioctl functionality,
> which has been broken in 2.4.0-test6-pre7. It now tests for fake
> ioctl's, so their should be no interaction with read-only mounts:
Still not in test9:
> i think the OOM algorithm should not kill processes that have
> child-processes, it should first kill child-less 'leaves'. Killing a
> process that has child processes likely results in unexpected behavior of
> those child-processes. (and equals to effective killing of those
> child-processes as
> Then spam the console loudly with printk, but don't destroy the whole machine.
> Init should only get killed if it REALLY is taking a lot of memory. On a 4 or 8meg
If init dies the kernel hangs solid anyway
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Mon, 9 Oct 2000, Linus Torvalds wrote:
> On Mon, 9 Oct 2000, Andi Kleen wrote:
> >
> > netscape usually has child processes: the dns helper.
>
> Yeah.
>
> One thing we _can_ (and probably should do) is to do a per-user
> memory pressure thing - we have easy access to the "struct
> user_stru
On Mon, Oct 09, 2000 at 01:52:21PM -0700, Linus Torvalds wrote:
> One thing we _can_ (and probably should do) is to do a per-user memory
> pressure thing - we have easy access to the "struct user_struct" (every
> process has a direct pointer to it), and it should not be too bad to
> maintain a per
Hi!
While working on vgacon I noticed their are 2 cli() in vga_vesa_blank
that are excuted one after another. Is their are a reason for this or
shoudl it be just one cli()?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Mon, 9 Oct 2000, Andi Kleen wrote:
>
> netscape usually has child processes: the dns helper.
Yeah.
One thing we _can_ (and probably should do) is to do a per-user memory
pressure thing - we have easy access to the "struct user_struct" (every
process has a direct pointer to it), and it sho
On Mon, 9 Oct 2000, Linus Torvalds wrote:
> I disagree - if we start adding these kinds of heuristics to it, it
> wil just be a way for people to try to confuse the OOM code. Imagine
> some bad guy that does 15 fork()'s and then tries to OOM...
yep.
Ingo
-
To unsubscribe from this lis
On Mon, 9 Oct 2000, Linus Torvalds wrote:
> On Mon, 9 Oct 2000, Ingo Molnar wrote:
> >
> > i think the OOM algorithm should not kill processes that have
> > child-processes, it should first kill child-less 'leaves'. Killing a
> > process that has child processes likely results in unexpected behav
Rik van Riel wrote:
> > How about SIGTERM a bit before SIGKILL then re-evaluate the OOM
> > N usecs later?
>
> And run the risk of having to kill /another/ process as well ?
>
> I really don't know if that would be a wise thing to do
> (but feel free to do some tests to see if your idea would
> w
On Mon, Oct 09, 2000 at 09:38:08PM +0100, James Sutherland wrote:
> Shouldn't the runtime factor handle this, making sure the new process is
The runtime factor in the algorithm will make the first difference
only after lots lots of time (and the run_time can as well be wrong
because of jiffies wr
On Mon, 9 Oct 2000, James Sutherland wrote:
> On Mon, 9 Oct 2000, Ingo Molnar wrote:
> > On Mon, 9 Oct 2000, Rik van Riel wrote:
> >
> > > > so dns helper is killed first, then netscape. (my idea might not
> > > > make sense though.)
> > >
> > > It makes some sense, but I don't think OOM is some
See out website
http://resourcemanagement.unixsolutions.hp.com/WaRM/schedpolicy.html
for this month's updates to Plug-in Schedulers for Linux.
Check out the new "constant" time scheduler!
change summary :
1. new module: const_sched.c
2. new xconfig buttons to conditionally build each scheduler
On Mon, 9 Oct 2000, Ingo Molnar wrote:
>
> i think the OOM algorithm should not kill processes that have
> child-processes, it should first kill child-less 'leaves'. Killing a
> process that has child processes likely results in unexpected behavior of
> those child-processes. (and equals to eff
On Mon, 9 Oct 2000, Ingo Molnar wrote:
> On Mon, 9 Oct 2000, Rik van Riel wrote:
>
> > > so dns helper is killed first, then netscape. (my idea might not
> > > make sense though.)
> >
> > It makes some sense, but I don't think OOM is something that
> > occurs often enough to care about it /that
On Mon, Oct 09 2000, Alan Cox wrote:
> > > You have to do Buslogic and AHA17xx before AHA15xx or you get a wrong driver
> > > and in the 17xx case data corruption risks
> >
> > Hmm.. The current order is the same as in 2.2.x, and puts aha17xx _after_
> > the other ones. Or did that change in th
> I'm still trying to read physical sectors in some partitioning code in
> linux/fs/partitions, and have made progress. Thanks for the pointers on
> set_blocksize(), that helps.
>
My ultimate goal is to read blocks 1, 2-34, n, n-32..n-1, where n is the
number of hardware sectors on the disk. Ho
On Mon, 9 Oct 2000, David Ford wrote:
> Ingo Molnar wrote:
>
> > > a good idea to have SIGKILL delivery speeded up for every SIGKILL ...
> >
> > yep.
>
> How about SIGTERM a bit before SIGKILL then re-evaluate the OOM
> N usecs later?
And run the risk of having to kill /another/ process as well
On Mon, Oct 09, 2000 at 01:59:23PM -0400, Pete Toscano wrote:
> anyway, i don't recall all of the usb errors, but i think there was
> "breadth" in it, it had about four lines of error message produced and
> they kept repeating until i unplugged all usb devices, and there were
> timeouts. useful,
Ingo Molnar wrote:
> > a good idea to have SIGKILL delivery speeded up for every SIGKILL ...
>
> yep.
How about SIGTERM a bit before SIGKILL then re-evaluate the OOM N usecs
later?
-d
--
"There is a natural aristocracy among men. The grounds of this are
virtue and talents", Thomas
Rik van Riel wrote:
> On Mon, 9 Oct 2000, Andrea Arcangeli wrote:
> > On Mon, Oct 09, 2000 at 04:07:32PM -0300, Rik van Riel wrote:
> > > No. It's only needed if your OOM algorithm is so crappy that
> > > it might end up killing init by mistake.
> >
> > The algorithm you posted on the list in thi
Hi,
> "Ivan" == Ivan Passos <[EMAIL PROTECTED]> writes:
Ivan> Hello,
Ivan> I have a customer who's getting tons of this msg in his
Ivan> LOGs:
Ivan> kernel: protocol 0008 is buggy, dev hdlc0
Ivan> The msg comes from net/core/dev.c, and this device is using
Ivan> t
I was looking through the current versions of the kernel, was re-reading
through some past "TODO before release" sort of messages, and was wondering,
could these TODO type of items be included in an actual TODO file at the
source top level (or in the Documentation if this would be more appropriate
On Mon, Oct 09, 2000 at 05:06:48PM -0300, Rik van Riel wrote:
> On Mon, 9 Oct 2000, Andrea Arcangeli wrote:
> > On Mon, Oct 09, 2000 at 04:07:32PM -0300, Rik van Riel wrote:
> > > No. It's only needed if your OOM algorithm is so crappy that
> > > it might end up killing init by mistake.
> >
> > T
On Mon, 9 Oct 2000, Ingo Molnar wrote:
> On Mon, 9 Oct 2000, Rik van Riel wrote:
>
> > > so dns helper is killed first, then netscape. (my idea might not
> > > make sense though.)
> >
> > It makes some sense, but I don't think OOM is something that
> > occurs often enough to care about it /that/
On Mon, 9 Oct 2000, Andrea Arcangeli wrote:
> On Mon, Oct 09, 2000 at 10:06:02PM +0200, Ingo Molnar wrote:
> > i think the OOM algorithm should not kill processes that have
> > process that has child processes likely results in unexpected behavior of
>
> You just know what I think about those heu
On Mon, Oct 09, 2000 at 07:24:03PM +0100, Alan Cox wrote:
> > > You have to do Buslogic and AHA17xx before AHA15xx or you get a wrong driver
> > > and in the 17xx case data corruption risks
> >
> > Hmm.. The current order is the same as in 2.2.x, and puts aha17xx _after_
> > the other ones. Or
J Sloan wrote:
> Haven't see any hangs, but have messages like these:
>
> eth1: Abnormal interrupt, status 0002.
> eth1: Abnormal interrupt, status 0002.
You can ignore this message. Since this message is logged at KERN_DEBUG
level (a.k.a. the least priority), you might consider raising
On Mon, 9 Oct 2000, Rik van Riel wrote:
> > so dns helper is killed first, then netscape. (my idea might not
> > make sense though.)
>
> It makes some sense, but I don't think OOM is something that
> occurs often enough to care about it /that/ much...
i'm trying to handle Andrea's case, the in
Andrea Arcangeli wrote:
> On Mon, Oct 09, 2000 at 12:30:20PM -0700, David Ford wrote:
> > Init should only get killed if it REALLY is taking a lot of memory. On a 4 or 8meg
>
> Init should never get killed. Killing init can be compared to destroy the TCP
> stack. Some app can keep to run right f
On Mon, 9 Oct 2000, Rik van Riel wrote:
> Note that the OOM killer already has this code built-in, but it may be
oops, i didnt notice (really!). One comment: 5*HZ in your code is way too
much for counter, and it might break the scheduler in the future. (right
now those counter values are unused
On Mon, 9 Oct 2000, Ingo Molnar wrote:
> On Mon, 9 Oct 2000, Andi Kleen wrote:
>
> > netscape usually has child processes: the dns helper.
>
> so dns helper is killed first, then netscape. (my idea might not
> make sense though.)
It makes some sense, but I don't think OOM is something that
occu
On Mon, Oct 09, 2000 at 10:06:02PM +0200, Ingo Molnar wrote:
> i think the OOM algorithm should not kill processes that have
> process that has child processes likely results in unexpected behavior of
You just know what I think about those heuristics. I think all we need is a
per-task pagefault/a
On Mon, 9 Oct 2000, Ingo Molnar wrote:
> what do you think about the attached patch? It increases the effective
> priority of a (kernel-) killed process, and initiates a reschedule, so
> that it gets selected ASAP. (except if there are RT processes around.)
> This should make OOM decisions 'visib
On Mon, 9 Oct 2000, Andi Kleen wrote:
> netscape usually has child processes: the dns helper.
so dns helper is killed first, then netscape. (my idea might not make
sense though.)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Mon, 9 Oct 2000, Andrea Arcangeli wrote:
> On Mon, Oct 09, 2000 at 04:07:32PM -0300, Rik van Riel wrote:
> > No. It's only needed if your OOM algorithm is so crappy that
> > it might end up killing init by mistake.
>
> The algorithm you posted on the list in this thread will kill
> init if on
On Mon, 9 Oct 2000, David Ford wrote:
> Then spam the console loudly with printk, but don't destroy the
> whole machine. Init should only get killed if it REALLY is
> taking a lot of memory. On a 4 or 8meg machine tho, the
> probability of init getting killed is simply too high for
> comfort. I
On Mon, Oct 09, 2000 at 10:06:02PM +0200, Ingo Molnar wrote:
>
> On Mon, 9 Oct 2000, Andrea Arcangeli wrote:
>
> > > No. It's only needed if your OOM algorithm is so crappy that
> > > it might end up killing init by mistake.
> >
> > The algorithm you posted on the list in this thread will kill
Rik,
what do you think about the attached patch? It increases the effective
priority of a (kernel-) killed process, and initiates a reschedule, so
that it gets selected ASAP. (except if there are RT processes around.)
This should make OOM decisions 'visible' much more quickly.
Ingo
--
Andre,
Where's the patch for the CD RW/DVD fix you did over the weekend. I
need to grab it and see if I can get this drive working on speed=8 on
2.4.0.
Jeff
Andre Hedrick wrote:
>
> On Mon, 9 Oct 2000, Rick Haines wrote:
>
> > I'm having real trouble mounting a dvd (udf filesystem) in my Pi
Ted,
Here are some corrections to the published list.
I'm working on new additions now.
~Randy
> 6. In Progress
>
> * USB: hotplug (PNP) and module autoloader support
+ Move to "1. Should Be Fixed". We want more testing of it, of course.
> 9. To Do
>
> * USB: OHCI root-hub-timer
Ditto here -
Running 8139too drivers on 2.4.0-test9:
8139too Fast Ethernet driver 0.9.10 loaded
eth0: RealTek RTL8139 Fast Ethernet at 0xd1834000, 00:e0:7d:7b:5a:16,
IRQ 10
eth0: Identified 8139 chip type 'RTL-8139A'
eth1: RealTek RTL8139 Fast Ethernet at 0xd1836000, 00:e0:7d:7b:5a:1d,
IRQ 10
e
On Mon, Oct 09, 2000 at 12:30:20PM -0700, David Ford wrote:
> Init should only get killed if it REALLY is taking a lot of memory. On a 4 or 8meg
Init should never get killed. Killing init can be compared to destroy the TCP
stack. Some app can keep to run right for some minute until they run sock
On Mon, 9 Oct 2000, Andrea Arcangeli wrote:
> > No. It's only needed if your OOM algorithm is so crappy that
> > it might end up killing init by mistake.
>
> The algorithm you posted on the list in this thread will kill init if
> on 4Mbyte machine without swap init is large 3 Mbytes and you exe
On Mon, Oct 09, 2000 at 04:07:32PM -0300, Rik van Riel wrote:
> No. It's only needed if your OOM algorithm is so crappy that
> it might end up killing init by mistake.
The algorithm you posted on the list in this thread will kill init if on 4Mbyte
machine without swap init is large 3 Mbytes and y
On Mon, 9 Oct 2000, Rik van Riel wrote:
> On Mon, 9 Oct 2000, Marco Colombo wrote:
> > On Fri, 6 Oct 2000, Rik van Riel wrote:
> >
> > [...]
> > > They are niced because the user thinks them a bit less
> > > important.
> >
> > Please don't, this assumption is quite wrong. I use nice just to
>
[EMAIL PROTECTED] (BERNARD Sebastien) wrote..
> Near the test3-4 kernel, I was not able to reach www.linuxtoday.com.
> After some debug, I find that is because my linux box is emitting syn
> packet with some really strange options (description of packet follows).
> Can anyone tell me if this beh
Then spam the console loudly with printk, but don't destroy the whole machine.
Init should only get killed if it REALLY is taking a lot of memory. On a 4 or 8meg
machine tho, the probability of init getting killed is simply too high for
comfort. I have never ever seen init start consuming memory
On Mon, 9 Oct 2000, Rick Haines wrote:
> I'm having real trouble mounting a dvd (udf filesystem) in my Pioneer
> 104S drive. It usually failes with:
> mount: wrong fs type, bad option, bad superblock on /dev/dvd,
>or too many mounted file systems
I suspect that it is a UDF issue and not
8139too Fast Ethernet driver 0.9.10 loaded
eth0: RealTek RTL8139 Fast Ethernet at 0xc8859000, 00:c0:df:04:7f:9b, IRQ 11
eth0: Identified 8139 chip type 'RTL-8139B'
I routinely (several times an hour) get messages like this:
eth0: Abnormal interrupt, status 0002
2.4.0-test9, x86, UP
AMD Duro
Here's an idea, farfetched as it may be.
Page the entire process out to disk into a user defined area, SIGHALT it and use
printk or a kthread/userproc to notify the user that something was kicked out of
the sandbox for playing bad. The user can add more swap if desired, then use a
userland tool
Hiya,
Subject says it all... If I select 'Winchip 2' or 'Winchip 2A/Winchip 3' for
'Processor Family' and try to boot the kernel on an iopener with a Winchip 2A,
the show stops right after the 'decompressing the kernel...' line is
displayed. Nothing happens. It just freezes...
Cheers//Frank
[EMAIL PROTECTED] wrote..
> linux/arch/i386/kernel/setup.c:
> Isn't here an "else" or "break" missing? Otherwise
> ``x86_cap_flags[16] = "pat"'' is always the case
Good spotting!
There should be an else there, as there is in 2.4
Regards,
Dave.
--- setup.c~Mon Oct 9 20:18:59 2000
+++ set
Rik van Riel wrote:
> On Mon, 9 Oct 2000, Marco Colombo wrote:
> > On Fri, 6 Oct 2000, Rik van Riel wrote:
> >
> > [...]
> > > They are niced because the user thinks them a bit less
> > > important.
> >
> > Please don't, this assumption is quite wrong. I use nice just to
> > be 'nice' to other us
On Mon, 9 Oct 2000, Rik van Riel wrote:
> > yes. Please remove the above part.
>
> OK, done.
thanks - i think all the other heuristics are 'fair': processes with more
CPU and run time used are likely to be more important, superuser processes
and direct-hw-access processes ditto.
Ingo
Meelis Roos writes:
> 2.4.0-test9
> modules.dep reports that pppox needs pppoe and pppoe needs pppox.
> modprobe pppo(e|x) segfaults (out of memory???).
>
A fix has been submitted. If you need a quick fix, do not compile as
a module, or remove line 158 of pppox.c.
Michal Ostrowski
[EMAIL P
2.4.0-test9
modules.dep reports that pppox needs pppoe and pppoe needs pppox.
modprobe pppo(e|x) segfaults (out of memory???).
---
Meelis Roos ([EMAIL PROTECTED])
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read t
On Mon, 9 Oct 2000, Andrea Arcangeli wrote:
> On Mon, Oct 09, 2000 at 08:42:26PM +0200, Ingo Molnar wrote:
> > ignoring the kill would just preserve those bugs artificially.
>
> If the oom killer kills a thing like init by mistake
That only happens in the "random" OOM killer 2.2 has ...
> So yo
Rik van Riel wrote:
> On Mon, 9 Oct 2000, Marco Colombo wrote:
> > On Fri, 6 Oct 2000, Rik van Riel wrote:
> >
> > [...]
> > > They are niced because the user thinks them a bit less
> > > important.
> >
> > Please don't, this assumption is quite wrong. I use nice just to
> > be 'nice' to other us
On Mon, Oct 09, 2000 at 08:42:26PM +0200, Ingo Molnar wrote:
> ignoring the kill would just preserve those bugs artificially.
If the oom killer kills a thing like init by mistake or init has a memleak
you'll notice both problems regardless of having a magic for init in a _very_
slow path so I don
Known FAQ, not a problem.
You compiled ECN into your kernel and a lot of sites out on the internet have a
broken stack implementation.
echo 0 > /proc/sys/net/ipv4/tcp_ecn
-d
BERNARD Sebastien wrote:
> Near the test3-4 kernel, I was not able to reach www.linuxtoday.com.
> After some debug, I f
(to alan)
Alan Cox wrote:
> cs46xx should 'just work'. You might need to add some pci ids
it does, i believe it was my fault the first two times around, not sure
why, but the last time i compiled, it was as a module and it worked
correctly.
-d
--
"There is a natural aristocracy among me
On Mon, 9 Oct 2000, Ingo Molnar wrote:
> > If you have a better algorithm, feel free to send patches.
>
> yes. Please remove the above part.
OK, done.
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http:/
On Mon, Oct 09, 2000 at 08:37:55PM +0200, Mikael Pettersson wrote:
> We could also do the following:
>
> 1. Move the error_code block from divide_error to page_fault;
>this removes one jump from the page_fault path.
It is not clear that it is worth it. You want to align error_code and
page_f
On Wed, 04 Oct 2000, Brian Gerst wrote:
>Mikulas Patocka wrote:
>>
>> Hi.
>>
>> arch/i386/kernel/entry.S
>> xchgl %eax, ORIG_EAX(%esp) # orig_eax (get the error code. )
>> movl %esp,%edx
>> xchgl %ecx, ES(%esp)# get the address and save es.
>> pu
> Excellent. But Alan, you wrote earlier that i2o needed to be the last host
> adapter and _before_ the upper layers. This is what made me start this
> patch.
Sorry. Then I was unclear and I sent you off doing un-needed work.
Apologies
-
To unsubscribe from this list: send the line "unsubscrib
On Mon, 9 Oct 2000, Rik van Riel wrote:
> In that case the time the process has been running and the
> CPU time used will save the process if it's been running for
> a long time.
'importance' is not something we can measure reliably within the kernel.
And assuming that a niced, not long-running
On Mon, Oct 09 2000, Alan Cox wrote:
> > Yes, that can be done pretty easy, but Then I2O will link
> >
> > core - hosts - upper - I2O and I'm not sure this is okay.
>
> Thats fine. I2O scsi is the last scsi driver anyway, the rest of i2o registers
> devices on different majors with no ordering
I'm having real trouble mounting a dvd (udf filesystem) in my Pioneer
104S drive. It usually failes with:
mount: wrong fs type, bad option, bad superblock on /dev/dvd,
or too many mounted file systems
but it succeeds sometimes. For a while I've been inserting the dvd,
waiting until the dri
On Mon, 9 Oct 2000, Andrea Arcangeli wrote:
> On Fri, Oct 06, 2000 at 04:19:55PM -0400, Byron Stanoszek wrote:
> > In the OOM killer, shouldn't there be a check for PID 1 just to enforce that
>
> Init can't be killed in 2.2.x latest, the same bugfix should be forward
> ported to 2.4.x.
I belie
On Fri, Oct 06, 2000 at 04:19:55PM -0400, Byron Stanoszek wrote:
> In the OOM killer, shouldn't there be a check for PID 1 just to enforce that
Init can't be killed in 2.2.x latest, the same bugfix should be forward
ported to 2.4.x.
> Can you give me your rationale for selecting 'nice' processe
> Yes, that can be done pretty easy, but Then I2O will link
>
> core - hosts - upper - I2O and I'm not sure this is okay.
Thats fine. I2O scsi is the last scsi driver anyway, the rest of i2o registers
devices on different majors with no ordering issues
-
To unsubscribe from this list: send the
Kurt Garloff wrote:
> I could not agree more. Normally, you'd better kill a foreground task
> (running nice 0) than selecting one of those background jobs for some
> reasons:
> * The foreground job can be restarted by the interactive user
> (Most likely, it will be only netscape anyway)
> * The
On Mon, Oct 09 2000, Linus Torvalds wrote:
>
>
> On Mon, 9 Oct 2000, Torben Mathiasen wrote:
> >
> > My point exactly. The ordering of driver in drivers/scsi is done now,
> > but I don't see a clean way of doing I2O without moving upperlayers
> > into a seperate dir.
>
> Why?
>
I was referrin
> > You have to do Buslogic and AHA17xx before AHA15xx or you get a wrong driver
> > and in the 17xx case data corruption risks
>
> Hmm.. The current order is the same as in 2.2.x, and puts aha17xx _after_
> the other ones. Or did that change in the later 2.2.x series?
I will double check th
> Also, we should really finalise the host order thing in scsi/Makefile. If
> it's true that aha17xx must come before aha1542, it's wrong as it stands
> now. Any other gotchas that were caught in 2.2.x?
Those are the only ones I know
Buslogic cards and AHA174x cards both emulate an aha1542 but h
For what it's worth, the system was called "Jackdaw" and was written by
Mike Challis. It was in extensive use on the University's MVT/MVS/MVSXA
mainframe for many years as the database for holding user information. The
document Alain's got is probably Computer Laboratory Technical Report no.
On Mon, 9 Oct 2000, Marco Colombo wrote:
> On Fri, 6 Oct 2000, Rik van Riel wrote:
>
> [...]
> > They are niced because the user thinks them a bit less
> > important.
>
> Please don't, this assumption is quite wrong. I use nice just to
> be 'nice' to other users. I can run my *important* CPU ho
Alan Cox wrote:
>
> > 4. Boot Time Failures
> >
> > * IBM Thinkpad 390 won't boot since 2.3.11 (See Decklin Foster for
> >more info)
>
> Add Palmax PD1100 hangs during boot since 2.4.0-test9
My Asus P55TP4 (i430FX)/AMD K5 PC also crashes after "Booting the
kernel..."
and before pri
> > Sigh... Do a search on Brook's Law, will you?
> You lose because the project isn't late yet ;-)
Brooks' law has certain assumptions in it that are not applicable to a low
communication cost, highly parallel environments
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel
In article <[EMAIL PROTECTED]>,
Kenn Humborg <[EMAIL PROTECTED]> wrote:
>
>I'd just like to confirm that it's illegal to call current()
>from interrupt-handling code.
It's not categorically forbidden.
It does indeed happen, think about things like cross-CPU interrupts for
TLB invalidations etc.
On Sun, 8 Oct 2000, Linus Torvalds wrote:
> On Wed, 4 Oct 2000, Rik van Riel wrote:
> >
> > The potential for this bug has been around since 2.3.51, when
> > different balance_ratios for different zones became possible.
> You must NOT depend on some global "freepages" thing.
> Don't do this pat
greg,
machine's at home and in a bit of a wedged state, so i can't get this
info to you right away, but i will if you think it'll help debug the
issue. from what you say, the people on the linux-usb-devel list
already have patches for these things, so i'm wondering if it'll be
useful.
anyway, i
101 - 200 of 288 matches
Mail list logo
