to use 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...
/R
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/
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 c
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 memo
an't 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: Linu
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
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 spinloc
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
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 for
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 maximum
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 Er
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 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 -- ran
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,
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 looks
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
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 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 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.
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 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?
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 00:
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 8
Hi,
I too tested to stress the new VM
Quintelas mmap002 "deadlocks" for me.
PPro, 96 MB, UP
active: 22337 (I think this varies, have too lock a 2nd time)
inactive_dirty: 324 varies
inactive_clean: 0
free: 288
... 1x 512 = 512 kB
... 2 x 16 + 1 x 32 + 1 x 64 = 640 kB
My feeling when looking at
"Juan J. Quintela" wrote:
>
> Hi
> while I am running mmap002 in test9-pre4 I got the computer
> frozen, it don't answer to my open windows anymore, it answers
> only to pings. I have got the attached traces. The machine
> is SMP with IDE disks.
I run from comma
Hi,
Trying to find out why test9-pre4 freezes with mmap002
I added a counter for try_again loops.
... __alloc_pages(...)
int direct_reclaim = 0;
unsigned int gfp_mask = zonelist->gfp_mask;
struct page * page = NULL;
+ int try_again_loops = 0;
- - -
+ pri
Rik van Riel wrote:
>
> On Wed, 20 Sep 2000, Roger Larsson wrote:
>
> > I added a counter for try_again loops.
> >
> > ... __alloc_pages(...)
> >
> > int direct_reclaim = 0;
> > unsigned int gfp_mask = zonelist->gfp_mask;
> &
Hi,
Tried your patch on 2.2.4-test9-pre4
with the included debug patch applied.
Rebooted, started mmap002
After a while it starts outputting (magic did not work
this time - usually does):
- - -
"VM: try_to_free_pages (result: 1) try_again # 12345"
"VM: try_to_free_pages (result: 1) try_again #
fails...
/RogerL
Roger Larsson wrote:
>
> Hi,
>
> Tried your patch on 2.2.4-test9-pre4
> with the included debug patch applied.
>
> Rebooted, started mmap002
>
> After a while it starts outputting (magic did not work
> this time - usually does):
>
> - - -
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
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 actu
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 wi
Hi,
Trying to compile the current kernel (test10-pre4) with:
> make clean
> make -j 2 bzImages modules modules_install
will try to install the modules before they are built...
This has previously been working (at least in early testX kernels).
make --version
GNU Make version 3.79.1, by Rich
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 list:
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,
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
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)
&
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 linux-kernel"
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
"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,
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 t
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 re
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 noticed
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 an
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 problem?
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
> > > > >
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 i
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.
> >
&
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
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 Lars
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...
> -
> 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å
locking cliff" McVoy 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 p
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 unsubscribe
tion __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,
sn't make sense 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
ribe 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å
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/
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
d 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 hig
59 matches
Mail list logo
