On Mon, 2005-02-28 at 11:43 +0100, Giacomo A. Catenazzi wrote:
> Arjan van de Ven wrote:
>
> >>but what what's the
> >>penalty of preventing microcode from loading? a performance
> >>hit?
> >
> >
> > not even that; in theory a few cpu bugs may have been fixed. Nobody
> > really knows since there
Arjan van de Ven wrote:
but what what's the
penalty of preventing microcode from loading? a performance
hit?
not even that; in theory a few cpu bugs may have been fixed. Nobody
really knows since there's no changelog for the microcode..
You can see the processor bugs in intel website, i.e.:
ftp://
Hugh Dickins <[EMAIL PROTECTED]> said:
> On Wed, 23 Feb 2005, Ammar T. Al-Sayegh wrote:
> > I recently installed Fedora RC3 on a new server.
> > The kernel is 2.6.10-1.741_FC3smp.
> I can't really speak for Fedora RC3 kernels,
> perhaps there's some special patch in there that happens to
> trigger
On Wed, 23 Feb 2005, Nick Warne wrote:
>
> I upgraded memory - all 4 sticks - over Christmas, and after a few weeks
> uptime, tried 2.4.10 again.
>
> I have had no problems since - so perhaps I did have bad memory (it was old).
> But all tests never showed anything untoward.
>
> I was always su
> I guess I can no longer monitor the processor temperature and
> such after preventing i2c from loading,
yup
> but what what's the
> penalty of preventing microcode from loading? a performance
> hit?
not even that; in theory a few cpu bugs may have been fixed. Nobody
really knows since there'
really; it was supposed to do that already
>
>> i2c_dev13249 0
>> i2c_core 24513 1 i2c_dev
>
> try for fun to not use i2c for a while
>
>> microcode 11489 0
> same for microcode... try removing that so that the microcode of your
> system doesn't g
> really; it was supposed to do that already
> >
> >> i2c_dev13249 0
> >> i2c_core 24513 1 i2c_dev
> >
> > try for fun to not use i2c for a while
> >
> >> microcode 11489 0
> > same for microcode... try removing that so that the microcode of your
On Wed, 23 Feb 2005, Ammar T. Al-Sayegh wrote:
> - Original Message - From: "Hugh Dickins" <[EMAIL PROTECTED]>
> > though quite possibly you cannot afford
> > such experiments on this server, and will revert to 2.4 for now.
>
> The problem is that my server is already in production
> mode.
- Original Message -
From: "Arjan van de Ven" <[EMAIL PROTECTED]>
To: "Ammar T. Al-Sayegh" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, February 23, 2005 5:01 PM
Subject: Re: kernel BUG at mm/rmap.c:483!
On Wed, 2005-02-23 at 16:45 -0500, Ammar T. Al-Sayeg
- Original Message -
From: "Hugh Dickins" <[EMAIL PROTECTED]>
To: "Ammar T. Al-Sayegh" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, February 23, 2005 4:31 PM
Subject: Re: kernel BUG at mm/rmap.c:483!
On Wed, 23 Feb 2005, Ammar T. Al-Sayegh wrote:
Any sug
> But not all cases could be accounted in that way. If you
> report back that memtest86 ran cleanly...
Hugh,
Nothing to do with the 'problem' in this thread, but an aside that is perhaps
relevant.
On my main gateway, I couldn't get any kernel greater than 2.6.4 to run
without an 'oops' after
gt;> crashes every few days. When I examine /var/log/messages,
> >> I find the following line just before the crash:
> >>
> >> Feb 22 23:50:35 hostname kernel: ------------[ cut here ]
> >> Feb 22 23:50:35 hostname kernel: kernel BUG at mm/rma
kernel: [ cut here ]
Feb 22 23:50:35 hostname kernel: kernel BUG at mm/rmap.c:483!
No further debug lines are given to diagnose the
source of the
no oops at all?
No. Is there a way to enable the kernel to give more
diagnostic debug output next time this error happens?
Is there
> Feb 22 23:50:35 hostname kernel: kernel BUG at mm/rmap.c:483!
>
> No further debug lines are given to diagnose the
> source of the problem.
It's odd that you get no more lines, but it doesn't really
matter in this case. Sadly, the debug info accompanying this
BUG has done
sh:
>
> Feb 22 23:50:35 hostname kernel: [ cut here ]
> Feb 22 23:50:35 hostname kernel: kernel BUG at mm/rmap.c:483!
>
> No further debug lines are given to diagnose the
> source of the
no oops at all?
which modules are you using?
-
To unsub
hostname kernel: kernel BUG at mm/rmap.c:483!
No further debug lines are given to diagnose the
source of the problem.
I have been using kernel 2.4 for few years now without
any problem. This is the first time I see this problem
with kernel 2.6. I'm not sure if this is related to
the kernel itself
On Wed, 16 Feb 2005 08:07:11 + (GMT)
Hugh Dickins <[EMAIL PROTECTED]> wrote:
> Yes, I believe /dev/mem handling on 2.4 and 2.6 is much the same,
> but the rmap.c BUG you're hitting in 2.6 had no equivalent in 2.4 -
> maybe the 2.4 case has actually been unsafe too, or maybe not.
OK, that make
on the console:
>
> kernel BUG at mm/rmap.c:483!
> EIP is at page_remove_rmap+0x26/0x40
> [] zap_pte_range+0x138/0x250 ...
> [] sys_munmap+0x40/0x70
>
> Is there anything I have missed? Does /dev/mem on a 2.6
> kerel behave the same way as on a 2.4 kernel?
Yes, I believe /dev/
ernel. On 2.6.10 I get this on the console:
[ cut here ]
kernel BUG at mm/rmap.c:483!
invalid operand: [#1]
Modules linked in:
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010286 (2.6.10)
EIP is at page_remove_rmap+0x26/0x40
eax: ebx: 3000
19 matches
Mail list logo
