On Sun, 2021-05-02 at 07:30 +1000, Paul Szabo wrote:
> I no longer use 32-bit kernels (but use the 64-bit amd64 kernel, even on
> my few last remaining 32-bt machines): that seems a suitable workaround
> or upgrade path. Should I try to test whether the issue with PAE
> remains?
I don't think
I no longer use 32-bit kernels (but use the 64-bit amd64 kernel, even on
my few last remaining 32-bt machines): that seems a suitable workaround
or upgrade path. Should I try to test whether the issue with PAE
remains?
Cheers, Paul
--
Paul Szabo p...@maths.usyd.edu.au
Control: tags -1 + moreinfo
I guess this usse can be considered resolved?
Regards,
Salvatore
Dear Ben,
Please read Documentation/SubmittingPatches, use scripts/checkpatch.pl
and try to provide a patch that is suitable for upstream inclusion.
Also, your name belongs in the patch header, not in the code.
I changed the proposed patch accordingly, scripts/checkpatch.pl produces
just a
tags 695182 - moreinfo
thanks
Dear Ben,
I suggest the following patch, which seems to solve the problem.
Two attachments: minimal.patch just to show the simplicity, and
complete.patch with comments and enhancements.
Cheers, Paul
Paul Szabo p...@maths.usyd.edu.au
Dear Ben,
I tried to send
tags 695182 - moreinfo
to cont...@bugs.debian.org but it came back with:
You have been specifically excluded from using the control interface.
I guess that has something to do with bug#299007. Would you please be
able to have those settings corrected?
Thanks, Paul
On Wed, 2013-01-02 at 08:33 +1100, Paul Szabo wrote:
tags 695182 - moreinfo
thanks
Dear Ben,
I suggest the following patch, which seems to solve the problem.
Two attachments: minimal.patch just to show the simplicity, and
complete.patch with comments and enhancements.
Please read
Dear Ben,
In the OOM message in my initial bug report, I see
Normal ... slab_reclaimable:261528kB ... all_unreclaimable? yes
Is that a contradiction? Should not that slab have been reclaimed?
Original line:
[ 744.754369] Normal free:43788kB min:44112kB low:55140kB high:66168kB
active_anon:0kB
Dear Ben,
In response to your comments: x seems to be in the range [-1,1]. The
returned pos_ratio would be within [0,2] if not for the final *8.
---
[Funny: taking difference of unsigned ints and expect the result to be
negative in some sense. Seems the problem was not with large memory but
On Mon, 2012-12-17 at 13:09 +1100, paul.sz...@sydney.edu.au wrote:
Dear Ben,
In response to your comments: x seems to be in the range [-1,1]. The
returned pos_ratio would be within [0,2] if not for the final *8.
---
[Funny: taking difference of unsigned ints and expect the result to be
Dear Ben,
It's not a crash, though that's kind of an academic distinction.
What would you like me to call it instead? The machine seemed to
hang... do not know if rebooted spontaneously or in response to a
shutdown -r now that I had typed into an un-responsive xterm.
Perhaps you could add
Seems to me that the bug is in function
bdi_position_ratio()
within file
mm/page-writeback.c
The internal variable declaration is
long long pos_ratio;
and calculation of it overflows. - Maybe, changing the declaration to
u64 would help. But also, pos_ratio is used without any bounds checks
Control: tag -1 patch
On Sun, 2012-12-16 at 07:21 +1100, paul.sz...@sydney.edu.au wrote:
Seems to me that the bug is in function
bdi_position_ratio()
within file
mm/page-writeback.c
The internal variable declaration is
long long pos_ratio;
and calculation of it overflows.
You seem
Dear Ben,
... I think the initial overflow occurs when calculating x
...
setpoint and dirty are numbers of pages and are declared as long, so on
a system with enough memory they can presumably differ by 2^21 or more
(2^21 pages = 8 GB). Shifting left by RATELIMIT_CALC_SHIFT = 10 can
then
On Sun, 2012-12-16 at 11:14 +1100, paul.sz...@sydney.edu.au wrote:
Dear Ben,
... I think the initial overflow occurs when calculating x
...
setpoint and dirty are numbers of pages and are declared as long, so on
a system with enough memory they can presumably differ by 2^21 or more
Dear Ben,
Although PAE supports up to 64 GB RAM ... The use of such a large
amount of high memory is problematic ...
Or you can test ... by restricting what the kernel uses with the
'mem' parameter, e.g. mem=16G.
Trying various mem=XX values, no OOM was observed with mem=32G or less,
but a
On Wed, 2012-12-05 at 12:19 +1100, Paul Szabo wrote:
Subject: linux-image-3.2.0-4-686-pae: Write couple of 1GB files for OOM crash
Package: src:linux
Version: 3.2.32-1
Severity: normal
Writing a few large files, causes an OOM crash.
This happens on a fresh install from the
An observation that may help in solving this issue. Using
while :; do free -lm; sleep 5; done
while writing the files, I see the buffers and cached values
increasing; then buffers start decreasing, eventually down to zero;
then soon after, OOM starts. The free or low or high values do not
seem
Dear Ben,
Although PAE supports up to 64 GB RAM, everything the kernel accesses
must be mapped into 1 GB of virtual address space (about 880 MB of
persistently mapped 'normal memory', plus temporary mappings of the
remaining 'high memory'). The use of such a large amount of high memory
is
On Wed, 2012-12-05 at 22:36 +1100, paul.sz...@sydney.edu.au wrote:
Dear Ben,
Although PAE supports up to 64 GB RAM, everything the kernel accesses
must be mapped into 1 GB of virtual address space (about 880 MB of
persistently mapped 'normal memory', plus temporary mappings of the
20 matches
Mail list logo
