>Well, I've found that VM-global patch before, of course. Until now, the
> last version was against pre18. Since I do not know the exact rules for
> including new things into Alan's tree, I thought that VM-global patch was
> already included in pre24. Sorry for my lack of experience. ;-)) I
> "I'm sure" meaning "I didn't test it" ?
absolutely, I believed that the driver was *exactly*
the same as the previous release which didn't boot and
needed the fix, but another fix has been applied and
corrected it. Now I think it will work with a clean
2.2.18pre25. Anyway, I left a kernel
> > Bad day, Alan? ;)
> Umm no but having people _keep_ sending you do
> nothing patches gets annoying after a while ;)
Please accept all my apologies, Alan. When I quickly
sent you the last patch, I didn't notice that some
other broken code had been removed, what I discovered
later back home
On Fri, 8 Dec 2000, Andrea Arcangeli wrote:
# On Fri, Dec 08, 2000 at 06:02:57PM +0100, Martin Kacer wrote:
# >Is there any chance to get rid of these VMM failures?
# You should apply this patch on top of 2.2.18pre25:
# ftp://.../VM-global-2.2.18pre25-7.bz2
Well, I've found that
On Fri, Dec 08, 2000 at 10:47:46AM +0100, Willy Tarreau wrote:
> |Bus 0, device 2, function 1:
> | Unknown class: Intel OEM MegaRAID Controller (rev 5).
> |Medium devsel. Fast back-to-back capable. BIST capable. IRQ 10. Master
> Capable. Latency=64.
> |Prefetchable 32 bit
On Fri, Dec 08, 2000 at 06:02:57PM +0100, Martin Kacer wrote:
>Is there any chance to get rid of these VMM failures?
You should apply this patch on top of 2.2.18pre25:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre25/VM-global-2.2.18pre25-7.bz2
>
On Fri, 8 Dec 2000, Alan Cox wrote:
# >Is there any chance to get rid of these VMM failures?
# By finding them.
:-) I am not so familiar with MM in Linux. :^(
And do not have enough time for intensive study...
Although I would probably like that work...
# Are you confident you are
>We aplied 2.2.18pre25 patch yesterday hoping it could solve it. The
> only difference is that the server reached several hours uptime instead of
> 40 minutes (with pre24). After two hours of load between 6.00 and 15.00
> the console was flooded with those unpopular messages ("VM: ..."). The
> > Some days I don't know why I bother
> Bad day, Alan? ;)
Umm no but having people _keep_ sending you do nothing patches gets
annoying after a while ;)
> reading the patch, it makes sense. It probably does about the same
> as Willy's patch, but the "right" way by using pci_resource_start()
>
> as soon as I can reboot it, I promise I will test the
> kernel with and without the patch to be really sure.
> but before that, if people who have problems with
> megaraid/netraid could give it a try, that would be
> cool. Also, it would be nice if people for which the
> normal megaraid driver
On Thu, 7 Dec 2000, Alan Cox wrote:
# Ok we believe the VM crash looping printing error messages is now fixed.
# Marcelo finally figured it out and my 8Mb 486 has been running 2.2.18pre
# with that fix and stably[1].
Unfortunately, I don't think it is fixed. We maintain a heavy loaded
> It doesnt even apply
sorry Alan, I think it's because I had to copy/paste
it
with my mouse under X into my browser (I don't have
smtp access here at work), and it applies here with a
-12 lines offset...
Here it is attached for 2.2.18pre25, but since the
raid
server is running now (under
> my server currently works with that patch, but I'm sure it won't boot anymore
> if I apply this 2.2.18pre25 alone.
Some days I don't know why I bother
> just in case, here it is again.
It doesnt even apply
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
> I asked people to explain why it was needed. I am still waiting. It is a
> patch that does nothing. I will not put random deep magic into the
> kernel.
Alan, I replied to you a few weeks ago (pre20 times) when you asked me why
I was sending you this patch. (perhaps you didn't receive my
I asked people to explain why it was needed. I am still waiting. It is a
patch that does nothing. I will not put random deep magic into the
kernel.
Alan, I replied to you a few weeks ago (pre20 times) when you asked me why
I was sending you this patch. (perhaps you didn't receive my email).
my server currently works with that patch, but I'm sure it won't boot anymore
if I apply this 2.2.18pre25 alone.
Some days I don't know why I bother
just in case, here it is again.
It doesnt even apply
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
It doesnt even apply
sorry Alan, I think it's because I had to copy/paste
it
with my mouse under X into my browser (I don't have
smtp access here at work), and it applies here with a
-12 lines offset...
Here it is attached for 2.2.18pre25, but since the
raid
server is running now (under
On Thu, 7 Dec 2000, Alan Cox wrote:
# Ok we believe the VM crash looping printing error messages is now fixed.
# Marcelo finally figured it out and my 8Mb 486 has been running 2.2.18pre
# with that fix and stably[1].
Unfortunately, I don't think it is fixed. We maintain a heavy loaded
as soon as I can reboot it, I promise I will test the
kernel with and without the patch to be really sure.
but before that, if people who have problems with
megaraid/netraid could give it a try, that would be
cool. Also, it would be nice if people for which the
normal megaraid driver works
Some days I don't know why I bother
Bad day, Alan? ;)
Umm no but having people _keep_ sending you do nothing patches gets
annoying after a while ;)
reading the patch, it makes sense. It probably does about the same
as Willy's patch, but the "right" way by using pci_resource_start()
which
We aplied 2.2.18pre25 patch yesterday hoping it could solve it. The
only difference is that the server reached several hours uptime instead of
40 minutes (with pre24). After two hours of load between 6.00 and 15.00
the console was flooded with those unpopular messages ("VM: ..."). The
On Fri, 8 Dec 2000, Alan Cox wrote:
# Is there any chance to get rid of these VMM failures?
# By finding them.
:-) I am not so familiar with MM in Linux. :^(
And do not have enough time for intensive study...
Although I would probably like that work...
# Are you confident you are
On Fri, Dec 08, 2000 at 06:02:57PM +0100, Martin Kacer wrote:
Is there any chance to get rid of these VMM failures?
You should apply this patch on top of 2.2.18pre25:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre25/VM-global-2.2.18pre25-7.bz2
It
On Fri, Dec 08, 2000 at 10:47:46AM +0100, Willy Tarreau wrote:
|Bus 0, device 2, function 1:
| Unknown class: Intel OEM MegaRAID Controller (rev 5).
|Medium devsel. Fast back-to-back capable. BIST capable. IRQ 10. Master
Capable. Latency=64.
|Prefetchable 32 bit memory at
Bad day, Alan? ;)
Umm no but having people _keep_ sending you do
nothing patches gets annoying after a while ;)
Please accept all my apologies, Alan. When I quickly
sent you the last patch, I didn't notice that some
other broken code had been removed, what I discovered
later back home and
"I'm sure" meaning "I didn't test it" ?
absolutely, I believed that the driver was *exactly*
the same as the previous release which didn't boot and
needed the fix, but another fix has been applied and
corrected it. Now I think it will work with a clean
2.2.18pre25. Anyway, I left a kernel
Well, I've found that VM-global patch before, of course. Until now, the
last version was against pre18. Since I do not know the exact rules for
including new things into Alan's tree, I thought that VM-global patch was
already included in pre24. Sorry for my lack of experience. ;-)) I
In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> wrote:
>
>Excellent. I've been trying to avoid VM fixes for 2.2.18 to stop stuff getting
>muddled together and hard to debug. Running with page aging convinces me that
>2.2.19 we need to sort some of the vm issues out badly, and make
> (note: the above is outdated so it's not anymore suggested for inclusion of
> course)
>
> I sumbitted most of the not-feature-oriented stuff at pre2 time and I plan to
> re-submit after 2.2.18 is released.
Excellent. I've been trying to avoid VM fixes for 2.2.18 to stop stuff getting
muddled
On Fri, Dec 08, 2000 at 12:27:58AM +, Alan Cox wrote:
> The problem is its hard to know which of your patches depend on what, and
> the complete set is large to say the least.
That's why I use a `proposed' directory that only contains patches that can be
applied to your tree, in this case it
> Such bug can't generate crashes. Did you ever reproduced crashes on your 8Mb
> 486 with 2.2.18pre24?
Yes. Every 20 minutes or so quite reliably. With that change it has yet to
crash (its actually running that + page aging + another minor tweak so it
doesnt return success on page aging until
On Thu, Dec 07, 2000 at 08:03:00PM +, Alan Cox wrote:
>
> Ok we believe the VM crash looping printing error messages is now fixed.
Such bug can't generate crashes. Did you ever reproduced crashes on your 8Mb
486 with 2.2.18pre24?
> Marcelo finally figured it out and my 8Mb 486 has been
> Megaraid still needs fixing. I sent you the patch twice, so have
> other people, but it still isn't fixed. The
I asked people to explain why it was needed. I am still waiting. It is a
patch that does nothing. I will not put random deep magic into the kernel.
I have no reason to believe the
In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> wrote:
>So I figure this is it for 2.2.18, subject to evidence to the contrary
Megaraid still needs fixing. I sent you the patch twice, so have
other people, but it still isn't fixed. The
megaBase &= PCI_BASE_ADDRESS_MEM_MASK;
...
Ok we believe the VM crash looping printing error messages is now fixed.
Marcelo finally figured it out and my 8Mb 486 has been running 2.2.18pre
with that fix and stably[1].
So I figure this is it for 2.2.18, subject to evidence to the contrary
Alan
2.2.18pre25
o Fix tight loop
Ok we believe the VM crash looping printing error messages is now fixed.
Marcelo finally figured it out and my 8Mb 486 has been running 2.2.18pre
with that fix and stably[1].
So I figure this is it for 2.2.18, subject to evidence to the contrary
Alan
2.2.18pre25
o Fix tight loop
In article [EMAIL PROTECTED],
Alan Cox [EMAIL PROTECTED] wrote:
So I figure this is it for 2.2.18, subject to evidence to the contrary
Megaraid still needs fixing. I sent you the patch twice, so have
other people, but it still isn't fixed. The
megaBase = PCI_BASE_ADDRESS_MEM_MASK;
...
Megaraid still needs fixing. I sent you the patch twice, so have
other people, but it still isn't fixed. The
I asked people to explain why it was needed. I am still waiting. It is a
patch that does nothing. I will not put random deep magic into the kernel.
I have no reason to believe the
On Thu, Dec 07, 2000 at 08:03:00PM +, Alan Cox wrote:
Ok we believe the VM crash looping printing error messages is now fixed.
Such bug can't generate crashes. Did you ever reproduced crashes on your 8Mb
486 with 2.2.18pre24?
Marcelo finally figured it out and my 8Mb 486 has been
Such bug can't generate crashes. Did you ever reproduced crashes on your 8Mb
486 with 2.2.18pre24?
Yes. Every 20 minutes or so quite reliably. With that change it has yet to
crash (its actually running that + page aging + another minor tweak so it
doesnt return success on page aging until we
On Fri, Dec 08, 2000 at 12:27:58AM +, Alan Cox wrote:
The problem is its hard to know which of your patches depend on what, and
the complete set is large to say the least.
That's why I use a `proposed' directory that only contains patches that can be
applied to your tree, in this case it
(note: the above is outdated so it's not anymore suggested for inclusion of
course)
I sumbitted most of the not-feature-oriented stuff at pre2 time and I plan to
re-submit after 2.2.18 is released.
Excellent. I've been trying to avoid VM fixes for 2.2.18 to stop stuff getting
muddled
In article [EMAIL PROTECTED],
Alan Cox [EMAIL PROTECTED] wrote:
Excellent. I've been trying to avoid VM fixes for 2.2.18 to stop stuff getting
muddled together and hard to debug. Running with page aging convinces me that
2.2.19 we need to sort some of the vm issues out badly, and make it faster
43 matches
Mail list logo
