On Thursday 14 June 2001 23:05, you wrote:
> On Thu, 14 Jun 2001, Roger Larsson wrote:
> > Hi,
> >
> > Wait a minute...
> >
> > Spinlocks on a embedded system? Is it _really_ SMP?
>
> The embedded system is not SMP. However, there is definite
> advantage
-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Roger Larsson
Skellefteå
Sweden
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
if the disk bandwidth isn't being used.
>
It does if you are running on a laptop. Then you do not want the pages
go out all the time. Disk has gone too sleep, needs to start to write a few
pages, stays idle for a while, goes to sleep, a few more pages, ...
/RogerL
--
Roger Larsson
Skell
for a while, goes to sleep, a few more pages, ...
/RogerL
--
Roger Larsson
Skellefteå
Sweden
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Roger Larsson
On Thursday 14 June 2001 23:05, you wrote:
On Thu, 14 Jun 2001, Roger Larsson wrote:
Hi,
Wait a minute...
Spinlocks on a embedded system? Is it _really_ SMP?
The embedded system is not SMP. However, there is definite
advantage to using an unmodified kernel that may/may-not
have
__alloc_pages)
if (z->free_pages >= z->pages_low) {
page = rmqueue(z, order);
if (page)
return page;
Hmm... a lot more than first meets the eye.
Note: >= matches < in another place, remov
);
if (page)
return page;
Hmm... a lot more than first meets the eye.
Note: = matches in another place, removing the = will leave the mm stuck...
/RogerL
--
Roger Larsson
Skellefteå
Sweden
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
after a process exit()s. What I want to do is
> reclaim swap space of pages which have been swapped in so
> we can use that swap space to swap something else out.
>
We could reclaim swap space for dirty pages. They have to be
rewritten anyway...
Or would the fragmentation risk be too high?
/
swapped in so
we can use that swap space to swap something else out.
We could reclaim swap space for dirty pages. They have to be
rewritten anyway...
Or would the fragmentation risk be too high?
/RogerL
--
Roger Larsson
Skellefteå
Sweden
-
To unsubscribe from this list: send the line
e that to determine requested accuracy...
Those who wait for seconds will probably not have a problem with up to (half)
a second longer wait - or...?
Those in range of the current jiffie should be able to handle up to one
jiffie longer...
Requesting a wait in ms gives yo ms accuracy...
/RogerL
a problem with up to (half)
a second longer wait - or...?
Those in range of the current jiffie should be able to handle up to one
jiffie longer...
Requesting a wait in ms gives yo ms accuracy...
/RogerL
--
Roger Larsson
Skellefte
Sweden
-
To unsubscribe from this list: send the line "unsubs
talks of.
A small cheap processor to do this with would be the ETRAX 100LX (LX = Linux)
Put an ETRAX100LX (integrated IDE, ethernet, and ...) on an IDE controller.
Telnet / SSH to your PCI boards :-)
Cheapest possible system might be one without a main CPU...
It would be possible to rebala
boards :-)
Cheapest possible system might be one without a main CPU...
It would be possible to rebalance where to create the interface over time.
/RogerL
--
Roger Larsson
Skellefte
Sweden
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
gt;
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Roger Larsson
Skellefteå
ohnson
Formally [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Hi,
One little readability thing I found.
The prev->state TASK_ value is mostly used as a plain value
but the new TASK_PREEMPTED is or:ed together with whatever was there.
Later when we switch to check the state it is checked against TASK_PREEMPTED
only. Since TASK_RUNNING is 0 it works OK
Hi,
One little readability thing I found.
The prev-state TASK_ value is mostly used as a plain value
but the new TASK_PREEMPTED is or:ed together with whatever was there.
Later when we switch to check the state it is checked against TASK_PREEMPTED
only. Since TASK_RUNNING is 0 it works OK but...
Hi,
Here is a link to some memory usage related test programs:
http://carpanta.dc.fi.udc.es/~quintela/memtest/
They have proven their value many times...
/RogerL
On Thursday 08 March 2001 21:57, Paul Larson wrote:
> Alan Cox <[EMAIL PROTECTED]> on 03/08/2001 02:06:06 PM
>
> To: Paul
Hi,
Here is a link to some memory usage related test programs:
http://carpanta.dc.fi.udc.es/~quintela/memtest/
They have proven their value many times...
/RogerL
On Thursday 08 March 2001 21:57, Paul Larson wrote:
Alan Cox [EMAIL PROTECTED] on 03/08/2001 02:06:06 PM
To: Paul
Hi,
This is interesting.
I have found out that my freezes most oftenly happen on cold boot.
At cold boot the locatedb is run...
I have added IKD...
/RogerL
On Thursday 01 March 2001 09:39, Uwe Bonnes wrote:
> Hallo,
>
> on two systems with 2.4.2. (actually the suse tree from Hubert mantel
Hi,
This is interesting.
I have found out that my freezes most oftenly happen on cold boot.
At cold boot the locatedb is run...
I have added IKD...
/RogerL
On Thursday 01 March 2001 09:39, Uwe Bonnes wrote:
Hallo,
on two systems with 2.4.2. (actually the suse tree from Hubert mantel at
hurt.
>
> But I don't see why this should cause numlock to
> stop working...
>
>
>
> Original Message
> Subject: [pre PATCH] freezes
> Date: Thu, 15 Feb 2001 15:29:12 +0100
> From: Roger Larsson <[EMAIL PROTECTED]>
> To: Linux Kernel Mailin
se numlock to
stop working...
Original Message
Subject: [pre PATCH] freezes
Date: Thu, 15 Feb 2001 15:29:12 +0100
From: Roger Larsson [EMAIL PROTECTED]
To: Linux Kernel Mailing List [EMAIL PROTECTED]
--Boundary-00=_OWYSLVSP7YK356P9A2LT
Content-Type:
On Tuesday 20 February 2001 22:21, Colonel wrote:
>From: "Tom Sightler" <[EMAIL PROTECTED]>
>Cc: <[EMAIL PROTECTED]>
>Date: Tue, 20 Feb 2001 14:43:07 -0500
>Content-Type: text/plain;
> charset="iso-8859-1"
>
>>> >I'm building a firewall on a P133 with 48 MB of
On Tuesday 20 February 2001 22:21, Colonel wrote:
From: "Tom Sightler" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Date: Tue, 20 Feb 2001 14:43:07 -0500
Content-Type: text/plain;
charset="iso-8859-1"
I'm building a firewall on a P133 with 48 MB of memory using RH
Hi,
I have had occasional freezes (complete NumLock won't work) for some time.
I blamed HW, irq conflicts, temperature problems, ...
But suddenly with 2.4.2-pre1 the problems disappeared!
Since 2.4.2-pre1 was rather short I took the time to try to find out what
could be the fix.
I found one
Hi,
I have had occasional freezes (complete NumLock won't work) for some time.
I blamed HW, irq conflicts, temperature problems, ...
But suddenly with 2.4.2-pre1 the problems disappeared!
Since 2.4.2-pre1 was rather short I took the time to try to find out what
could be the fix.
I found one
test
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
test
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
OK, you had to...
I have not seen any emails from linux-kernel for some days.
Even tried to resubscribe - Majordomo succeeded in sending me the Confirmation
But nothing...
So I have to try this...
/RogerL
(I am subscribed as [EMAIL PROTECTED])
--
Home page:
none currently
-
To
OK, you had to...
I have not seen any emails from linux-kernel for some days.
Even tried to resubscribe - Majordomo succeeded in sending me the Confirmation
But nothing...
So I have to try this...
/RogerL
(I am subscribed as [EMAIL PROTECTED])
--
Home page:
none currently
-
To
On Sunday 14 January 2001 01:06, george anzinger wrote:
> Nigel Gamble wrote:
> > On Sat, 13 Jan 2001, Roger Larsson wrote:
> > > A rethinking of the rescheduling strategy...
> >
> > Actually, I think you have more-or-less described how successful
> > p
On Friday 12 January 2001 10:33, Marcel Weber wrote:
> SuSE Linux 7.0, Kernel 2.4.0
>
> Adaptec 3950U2
> Adaptec 2940
>
>
> Although the kernel is complaining about the following things:
>
> kernel: scsi0: PCI error Interrupt at seqaddr= 0x4e
> kernel: scsi0: Data Parity
On Friday 12 January 2001 10:33, Marcel Weber wrote:
SuSE Linux 7.0, Kernel 2.4.0
Adaptec 3950U2
Adaptec 2940
Although the kernel is complaining about the following things:
kernel: scsi0: PCI error Interrupt at seqaddr= 0x4e
kernel: scsi0: Data Parity Error
On Sunday 14 January 2001 01:06, george anzinger wrote:
Nigel Gamble wrote:
On Sat, 13 Jan 2001, Roger Larsson wrote:
A rethinking of the rescheduling strategy...
Actually, I think you have more-or-less described how successful
preemptible kernels have already been developed, given
Hi,
A rethinking of the rescheduling strategy...
I have come to this conclusion.
A spinlock prevents other processes to enter that specific region.
But interrupts are allowed they might delay
execution of a spin locked
reqion for a undefined (small but anyway) time.
Code with critical
Hi,
A rethinking of the rescheduling strategy...
I have come to this conclusion.
A spinlock prevents other processes to enter that specific region.
But interrupts are allowed they might delay
execution of a spin locked
reqion for a undefined (small but anyway) time.
Code with critical
Hi,
Konqueror behaves really strange with the new kernel (compiled with 2.95.2 as
all my kernels for a very long time)
I have not seen this behaviour (to this extent) with earlier 2.4 kernels.
Included a strace... strange use of brk - or? [included /proc/pid/maps too]
It bugs out like this
On Tuesday 09 January 2001 12:08, Anton Blanchard wrote:
> > Where is the size defined, and is it easy to modify?
>
> Look in fs/buffer.c:buffer_init()
>
> > I noticed that /proc/sys/vm/freepages is not writable any more. Is there
> > any reason for this?
>
> I am not sure why.
>
It can
On Tuesday 09 January 2001 12:08, Anton Blanchard wrote:
Where is the size defined, and is it easy to modify?
Look in fs/buffer.c:buffer_init()
I noticed that /proc/sys/vm/freepages is not writable any more. Is there
any reason for this?
I am not sure why.
It can probably be made
Hi,
Konqueror behaves really strange with the new kernel (compiled with 2.95.2 as
all my kernels for a very long time)
I have not seen this behaviour (to this extent) with earlier 2.4 kernels.
Included a strace... strange use of brk - or? [included /proc/pid/maps too]
It bugs out like this
On Thursday 04 January 2001 09:43, ludovic fernandez wrote:
> Daniel Phillips wrote:
> > The key idea here is to disable preemption on spin lock and reenable on
> > spin unlock. That's a practical idea, highly compatible with the
> > current way of doing things. Its a fairly heavy hit on
Hi,
I have played around with this code previously.
This is my current understanding.
[yield problem?]
On Tuesday 02 January 2001 09:27, Mike Galbraith wrote:
> Hi,
>
> I am seeing (what I believe is;) severe process CPU starvation in
> 2.4.0-prerelease. At first, I attributed it to semaphore
Hi,
I have played around with this code previously.
This is my current understanding.
[yield problem?]
On Tuesday 02 January 2001 09:27, Mike Galbraith wrote:
Hi,
I am seeing (what I believe is;) severe process CPU starvation in
2.4.0-prerelease. At first, I attributed it to semaphore
Hi,
I am seeing something strange too, trying to reliably reproduce it
for a while - it is rare but irritating.
Most likely to happen on cold power on (first@evening)
--- X ---
XFree86 Version 3.3.6 / X Window System
(protocol Version 11, revision 0, vendor release 6300)
Release Date: January
Hi,
I am seeing something strange too, trying to reliably reproduce it
for a while - it is rare but irritating.
Most likely to happen on cold power on (first@evening)
--- X ---
XFree86 Version 3.3.6 / X Window System
(protocol Version 11, revision 0, vendor release 6300)
Release Date: January
On Saturday 25 November 2000 22:05, Roger Larsson wrote:
> On Saturday 25 November 2000 20:22, Philipp Rumpf wrote:
> > On Sat, Nov 25, 2000 at 08:03:49PM +0100, Roger Larsson wrote:
> > > > _trylock functions return 0 for success.
> > >
> > > Not spin_try
On Sunday 26 November 2000 19:36, Rik van Riel wrote:
> On Sun, 26 Nov 2000, Ingo Oeser wrote:
> > On Sun, Nov 26, 2000 at 10:49:50AM +1100, Andrew Morton wrote:
> > > You may also get some benefit from running:
> > >
> > > # echo "512 1024 1536" > /proc/sys/vm/freepages
> > >
> > > after
On Monday 27 November 2000 02:36, Mastoras wrote:
> Hello,
>
> I'm trying to use RTlinux to make a unix process wakeup
> periodicaly, in terms of "real time".
Have I understood correctly - you try to use a RTLinux process to get a
finer grained periodical wakeup than linux standard 10
On Sunday 26 November 2000 19:36, Rik van Riel wrote:
On Sun, 26 Nov 2000, Ingo Oeser wrote:
On Sun, Nov 26, 2000 at 10:49:50AM +1100, Andrew Morton wrote:
You may also get some benefit from running:
# echo "512 1024 1536" /proc/sys/vm/freepages
after booting.
... which is
On Saturday 25 November 2000 22:05, Roger Larsson wrote:
On Saturday 25 November 2000 20:22, Philipp Rumpf wrote:
On Sat, Nov 25, 2000 at 08:03:49PM +0100, Roger Larsson wrote:
_trylock functions return 0 for success.
Not spin_trylock
Argh, I missed the (recent ?) change
On Monday 27 November 2000 02:36, Mastoras wrote:
Hello,
I'm trying to use RTlinux to make a unix process wakeup
periodicaly, in terms of "real time".
Have I understood correctly - you try to use a RTLinux process to get a
finer grained periodical wakeup than linux standard 10 ms?
On Saturday 25 November 2000 20:22, Philipp Rumpf wrote:
> On Sat, Nov 25, 2000 at 08:03:49PM +0100, Roger Larsson wrote:
> > > _trylock functions return 0 for success.
> >
> > Not spin_trylock
>
> Argh, I missed the (recent ?) change to make x86 spinlocks use
On Saturday 25 November 2000 19:30, Philipp Rumpf wrote:
> On Sat, Nov 25, 2000 at 03:49:25PM -0200, Rik van Riel wrote:
> > On Sat, 25 Nov 2000, Roger Larsson wrote:
> > > Questions:
> > > What are _trylocks supposed to return?
> >
> > It depends on th
On Saturday 25 November 2000 18:49, Rik van Riel wrote:
> On Sat, 25 Nov 2000, Roger Larsson wrote:
> > Questions:
> > What are _trylocks supposed to return?
>
> It depends on the type of _trylock ;(
>
> > Does spin_trylock and down_trylock behave differently
Hi,
Background information:
compiled and tested a test11 with the Montavista preemptive patch.
After pressing Magic-SysRq-M all processes that tried to do IO hung in 'D'
Last message "Buffer memory ..."
Pressing Magic-SysRq-M again, all hung processes continued...
Checking the patch it
Hi,
Background information:
compiled and tested a test11 with the Montavista preemptive patch.
After pressing Magic-SysRq-M all processes that tried to do IO hung in 'D'
Last message "Buffer memory ..."
Pressing Magic-SysRq-M again, all hung processes continued...
Checking the patch it
On Saturday 25 November 2000 19:30, Philipp Rumpf wrote:
On Sat, Nov 25, 2000 at 03:49:25PM -0200, Rik van Riel wrote:
On Sat, 25 Nov 2000, Roger Larsson wrote:
Questions:
What are _trylocks supposed to return?
It depends on the type of _trylock ;(
Does spin_trylock
On Saturday 25 November 2000 20:22, Philipp Rumpf wrote:
On Sat, Nov 25, 2000 at 08:03:49PM +0100, Roger Larsson wrote:
_trylock functions return 0 for success.
Not spin_trylock
Argh, I missed the (recent ?) change to make x86 spinlocks use 1 to mean
unlocked. You're correct
Hi,
I got compilation errors due to use of START / STOP
definitions (zlib.c, ppp?)
This little additional patch should fix it. They were not
used in any other place of the patch...
I am still compiling...
/RogerL
--- spinlock.h.preemt Sat Nov 25 00:31:38 2000
+++ spinlock.h Sat Nov 25
Hi,
I got compilation errors due to use of START / STOP
definitions (zlib.c, ppp?)
This little additional patch should fix it. They were not
used in any other place of the patch...
I am still compiling...
/RogerL
--- spinlock.h.preemt Sat Nov 25 00:31:38 2000
+++ spinlock.h Sat Nov 25
Hi,
This comment is written in head of reschedule_idle, is it really
correct?
--
/*
* This is ugly, but reschedule_idle() is very timing-critical.
* We enter with the runqueue spinlock held, but we might end
* up unlocking it early, so the caller must not unlock the
Hi,
This comment is written in head of reschedule_idle, is it really
correct?
--
/*
* This is ugly, but reschedule_idle() is very timing-critical.
* We enter with the runqueue spinlock held, but we might end
* up unlocking it early, so the caller must not unlock the
On Sunday 12 November 2000 23:31, Erik Mouw wrote:
> On Sun, Nov 12, 2000 at 02:39:09PM -0500, [EMAIL PROTECTED] wrote:
> > * USB: system hang with USB audio driver {CRITICAL} (David
> >Woodhouse, Randy Dunlap, Narayan Desai) (Fixed with usb-uhci;
> >uhci-alt is unknown --
On Sunday 12 November 2000 23:31, Erik Mouw wrote:
On Sun, Nov 12, 2000 at 02:39:09PM -0500, [EMAIL PROTECTED] wrote:
* USB: system hang with USB audio driver {CRITICAL} (David
Woodhouse, Randy Dunlap, Narayan Desai) (Fixed with usb-uhci;
uhci-alt is unknown -- randy
"Jeff V. Merkey" wrote:
>
> David/Alan,
>
> Andre Hedrick is now the CTO of TRG and Chief Scientist over Linux
> Development. After talking
> to him, we are going to do our own ring 0 2.4 and 2.2.x code bases for
> the MANOS merge.
> the uClinux is interesting, but I agree is limited.
>
"Jeff V. Merkey" wrote:
David/Alan,
Andre Hedrick is now the CTO of TRG and Chief Scientist over Linux
Development. After talking
to him, we are going to do our own ring 0 2.4 and 2.2.x code bases for
the MANOS merge.
the uClinux is interesting, but I agree is limited.
Jeff,
What
Not.
It does not lock anything else...
This was not a problem.
/RogerL
Roger Larsson wrote:
>
> Hi again,
>
> Please ignore my patch suggestion from getblk -
> it will give problems later - in alloc...
>
> It is grow_buffers that might need to lock the
> other
Hi again,
Please ignore my patch suggestion from getblk -
it will give problems later - in alloc...
It is grow_buffers that might need to lock the
other ones too...
/RogerL
--
Home page:
http://www.norran.net/nra02596/
-
To unsubscribe from this list: send the line "unsubscribe
to refill_freelist before
releasing the locks - ok?
/RogerL
Roger Larsson wrote:
>
> Hi,
>
> I noted that even try_to_free_buffers locks lru_list_lock.
> Then it tries to lock some others - maybe one of the other treads
> got one of those (hash_table_lock, free_list[inde
Hi,
I noted that even try_to_free_buffers locks lru_list_lock.
Then it tries to lock some others - maybe one of the other treads
got one of those (hash_table_lock, free_list[index].lock)
It fits with that proc 4 it executes in the beginning of
try_to_free_buffers, does it move?
Or is it stuck at
Hi,
I noted that even try_to_free_buffers locks lru_list_lock.
Then it tries to lock some others - maybe one of the other treads
got one of those (hash_table_lock, free_list[index].lock)
It fits with that proc 4 it executes in the beginning of
try_to_free_buffers, does it move?
Or is it stuck at
to refill_freelist before
releasing the locks - ok?
/RogerL
Roger Larsson wrote:
Hi,
I noted that even try_to_free_buffers locks lru_list_lock.
Then it tries to lock some others - maybe one of the other treads
got one of those (hash_table_lock, free_list[index].lock)
It fits with that proc 4
Hi again,
Please ignore my patch suggestion from getblk -
it will give problems later - in alloc...
It is grow_buffers that might need to lock the
other ones too...
/RogerL
--
Home page:
http://www.norran.net/nra02596/
-
To unsubscribe from this list: send the line "unsubscribe
Not.
It does not lock anything else...
This was not a problem.
/RogerL
Roger Larsson wrote:
Hi again,
Please ignore my patch suggestion from getblk -
it will give problems later - in alloc...
It is grow_buffers that might need to lock the
other ones too...
/RogerL
--
Home
False alarm.
Rechecked my .config - it was strange
And remembered that I did a clean start...
Wrong config file - sorry...
/RogerL
Brian Gerst wrote:
>
> Roger Larsson wrote:
> >
> > Hi,
> >
> > This is the first test kernel that won't boot
> > for me.
>
Hi,
This is the first test kernel that won't boot
for me.
Last message "Ok, booting the kernel"
Then nothing...
PPro 180
96MB
440FX chip set
Saw something about PCI initializations earlier
on the list...
/RogerL
--
Home page:
http://www.norran.net/nra02596/
-
To unsubscribe from this
Hi,
This is the first test kernel that won't boot
for me.
Last message "Ok, booting the kernel"
Then nothing...
PPro 180
96MB
440FX chip set
Saw something about PCI initializations earlier
on the list...
/RogerL
--
Home page:
http://www.norran.net/nra02596/
-
To unsubscribe from this
False alarm.
Rechecked my .config - it was strange
And remembered that I did a clean start...
Wrong config file - sorry...
/RogerL
Brian Gerst wrote:
Roger Larsson wrote:
Hi,
This is the first test kernel that won't boot
for me.
Last message "Ok, booting the k
Jason Slagle wrote:
>
> Howdy! 2.4.0 is looking almost ready except 1 HY00GE problem I'm having.
>
> I'm SMP here 2 Celeron 300A's at 450 in an Abit BP6. 256M of RAM, all
> SCSI.
>
> System will run for a week no problems.
>
> Then I compile mozilla and all hell breaks loose.
>
> Compile
Jason Slagle wrote:
Howdy! 2.4.0 is looking almost ready except 1 HY00GE problem I'm having.
I'm SMP here 2 Celeron 300A's at 450 in an Abit BP6. 256M of RAM, all
SCSI.
System will run for a week no problems.
Then I compile mozilla and all hell breaks loose.
Compile will go for
Russell King wrote:
>
> Petr Vandrovec writes:
> > ... or from sys_exit() if you forget to unmap. Or from anywhere if
> > swapping code decides to swap such page. I'm trying to hunt it down
> > for more than month, but I have no idea what's wrong. In my case
> > way to trigger bug is:
>
> I
Russell King wrote:
Petr Vandrovec writes:
... or from sys_exit() if you forget to unmap. Or from anywhere if
swapping code decides to swap such page. I'm trying to hunt it down
for more than month, but I have no idea what's wrong. In my case
way to trigger bug is:
I actually think
Linus Torvalds wrote:
>
> On Tue, 17 Oct 2000, Alexander Viro wrote:
> >
> > > Trace; c014efde
> > > Trace; c014f240
> > > Trace; c014f6af
> > > Trace; c021e87e
> > Huh?
> > > Trace; c01523af
> >
> > The rest of trace is OK, but WTF is net/unix/*.c code is doing here?
>
> The traces always
Linus Torvalds wrote:
On Tue, 17 Oct 2000, Alexander Viro wrote:
Trace; c014efde read_inode_bitmap+3e/90
Trace; c014f240 load_inode_bitmap+210/230
Trace; c014f6af ext2_new_inode+29f/700
Trace; c021e87e unix_write_space+2e/50
Huh?
Trace; c01523af ext2_create+1f/c0
The
To the right linux-kernel list this time.
/RogerL
Roger Larsson wrote:
>
> Christoph Lameter wrote:
> >
> > Comparing CD contents with the original after burning showed mismatches 4
> > times in a row. Booted into linux 2.2.18 and everything is fine.
> >
To the right linux-kernel list this time.
/RogerL
Roger Larsson wrote:
Christoph Lameter wrote:
Comparing CD contents with the original after burning showed mismatches 4
times in a row. Booted into linux 2.2.18 and everything is fine.
Together with the events of freezing in pine I
Hi,
This is applicable on Riels latest addition.
(freepages v. zone->"limit")
That is probably not needed, and you should be able
to change your limits with this patch.
This patch adds equality check in several comparisons.
It is strictly only the one in __alloc_pages_limit
that is needed, it
Rik van Riel wrote:
>
> On Wed, 4 Oct 2000, Roger Larsson wrote:
> > Rik van Riel wrote:
> > > On Wed, 4 Oct 2000, Rik van Riel wrote:
> > >
> > > > > > First, you have MORE free memory than freepages.high. In this
> > > > &
Rik van Riel wrote:
>
> On Wed, 4 Oct 2000, Rik van Riel wrote:
>
> > > > First, you have MORE free memory than freepages.high. In this
> > > > case I really don't see why __alloc_pages() wouldn't give the
> > > > memory to your processes
> > >
> > > Hmm...
> > > Can't it be a zone
Rik van Riel wrote:
>
> On Wed, 4 Oct 2000, David Weinehall wrote:
>
> > Running the included program on a clean v2.4.0test9 kernel I can
> > hang the computer practically in no time.
>
> > What seems most strange is that the doesn't even get depleated.
> > The machine still answers to SysRq
Rik van Riel wrote:
On Wed, 4 Oct 2000, David Weinehall wrote:
Running the included program on a clean v2.4.0test9 kernel I can
hang the computer practically in no time.
What seems most strange is that the doesn't even get depleated.
The machine still answers to SysRq and ping, but
Rik van Riel wrote:
On Wed, 4 Oct 2000, Roger Larsson wrote:
Rik van Riel wrote:
On Wed, 4 Oct 2000, Rik van Riel wrote:
First, you have MORE free memory than freepages.high. In this
case I really don't see why __alloc_pages() wouldn't give the
memory to your
Hi,
This is applicable on Riels latest addition.
(freepages v. zone-"limit")
That is probably not needed, and you should be able
to change your limits with this patch.
This patch adds equality check in several comparisons.
It is strictly only the one in __alloc_pages_limit
that is needed, it
Hi,
I started a compile of kernel test9-final on a virtual console.
(make bzImage modules modules_install)
Then I started X on another one. Initial windows showed up fine.
But mouse was stuck. Tried magic - nothing. (early in compile,
should not be at modules_install for a long time)
I
Hi,
I started a compile of kernel test9-final on a virtual console.
(make bzImage modules modules_install)
Then I started X on another one. Initial windows showed up fine.
But mouse was stuck. Tried magic - nothing. (early in compile,
should not be at modules_install for a long time)
I
Hi,
Tried latest patch with the same result - freeze...
No extra patches added.
running from console as root
mmap002 from memtest-0.0.3
with RAMSIZE defined as 90 MB (I have 96MB)
after a while with heavy disk access (thrashing?) the drive
becomes silent - no more progress...
[if you can not
Hi,
Tried latest patch with the same result - freeze...
No extra patches added.
running from console as root
mmap002 from memtest-0.0.3
with RAMSIZE defined as 90 MB (I have 96MB)
after a while with heavy disk access (thrashing?) the drive
becomes silent - no more progress...
[if you can not
Hi,
What will happen in this scenario:
a process
* grabs a fs semaphore
* needs some buffers to do IO, calls __alloc_pages(GFP_BUFFER)
Suppose the system is MIN on free mem, has no inactive_clean pages.
We will end up around line 446 in pages_alloc.c and issue a
try_to_free_pages(...). Then goto
1 - 100 of 111 matches
Mail list logo
