On 18 Sep, Garrett Wollman wrote:
> < said:
>
>> 10. Upgraded to gcc3.2. I was seeing now some SIG11 during builds,
>> and - panics ! Softupdates and fs panics mostly. I turned off
>> softupdates. The panic was different, but all the time it was
>> in mmap.
>
> I'm not seeing panics,
On Wed, 18 Sep 2002, Martin Blapp wrote:
>
> Hi,
>
> > One thing you didn't mention was trying a different power supply. A
> > marginal power supply can cause strange errors. Increasing your memory
> > size from 512 MB to 1 GB might add just enough load to the supply to
> > push it over the edg
Hi,
> I'm not seeing panics, but I am seeing memory corruption causing about
> every third buildworld to fail. Usually this affects `cc1' or `ld',
> but last night I saw corruption in a source file.
Before new gcc3.2 import I also have not seen panics. Panics started after
latest 3.2.1 import.
< said:
> 10. Upgraded to gcc3.2. I was seeing now some SIG11 during builds,
> and - panics ! Softupdates and fs panics mostly. I turned off
> softupdates. The panic was different, but all the time it was
> in mmap.
I'm not seeing panics, but I am seeing memory corruption causing abo
Hi,
> Which Asus? Does it support ECC memory? Do you have ECC memory and
> have ECC enabled in the BIOS?
I used 3 boards:
1. ASUS P4B533-V 1GB DRAM 2100
2. Intel BG485 512MB DRAM 2100
3. Intel BG485 512MB DRAM 2100 ECC
>
> The thing that scared me about these reports was that I was under t
Martin Blapp writes:
> 8. I changed again the mobo. This time ASUS, but same I845 chipset.
> The system run fine.
Which Asus? Does it support ECC memory? Do you have ECC memory and
have ECC enabled in the BIOS?
The thing that scared me about these reports was that I was under the
impr
Hi,
> One thing you didn't mention was trying a different power supply. A
> marginal power supply can cause strange errors. Increasing your memory
> size from 512 MB to 1 GB might add just enough load to the supply to
> push it over the edge ...
Yes. I've replaced the power supply. But only o
On 18 Sep, Martin Blapp wrote:
>
> Hi Robert,
>
>> Chances are, if you change an important variable such as memory size, it
>> will change the failure mode for this bug. Carefully marking the memory
>
> Sigh.
>
> Looks like you are right. After running the system now for 8 hours,
> I got exac
Hi all,
To get always the same panic (not softupdate or ffs crashes) one
has to do the following:
- sysctl kern.sync_on_panic=0
- Disable softupdates on the filesystem in question.
The panics are more informative then.
To get the panics more often:
Set in loader.conf:
- hw.physmem=131072 or
Hi Robert,
> Chances are, if you change an important variable such as memory size, it
> will change the failure mode for this bug. Carefully marking the memory
Sigh.
Looks like you are right. After running the system now for 8 hours,
I got exactly the same crash as before. Again. It's the sam
On Tue, 17 Sep 2002, Martin Blapp wrote:
> If you don't beleave it or not. I've taken out again (I've already
> switched them once) one bank of 512M ram and since then I've not had any
> panics anymore.
>
> Can a ram error occur after a system has been fine one month ?
Chances are, if you ch
walt wrote:
> > This is the TLB problem we all keep talking about...
> > I just got the most recent IA-32 manuals from Intel in the mail,
> > and they still don't seem to be aware of the issue...
>
> Is this an Intel-specific problem, then?
No. AMD has it too.
-- Terry
To Unsubscribe: send ma
Terry Lambert wrote:
> Martin Blapp wrote:
>>Can a ram error occur after a system has been fine one month ?
>
>
> No.
>
> This is the TLB problem we all keep talking about...
> I just got the most recent IA-32 manuals from Intel in the mail,
> and they still don't seem to be aware of the issue
Terry Lambert wrote:
> Martin Blapp wrote:
> > If you don't beleave it or not. I've taken out again (I've already
> > switched them once) one bank of 512M ram and since then I've not
> > had any panics anymore.
> >
> > Can a ram error occur after a system has been fine one month ?
>
> No.
Let me
Martin Blapp wrote:
> If you don't beleave it or not. I've taken out again (I've already
> switched them once) one bank of 512M ram and since then I've not
> had any panics anymore.
>
> Can a ram error occur after a system has been fine one month ?
No.
This is the TLB problem we all keep talkin
Hi,
I see now another possibility. I've taken out at the same
time my Radeon 8500, which I'd also used in the previous
system.
I just noted that Michael Reifenberger, which has seen
the same corruption, has - oh wonder -
the same card inside. I'll try again with and without this
card, and with
On 17-Sep-2002 Martin Blapp wrote:
>
> Hi all,
>
> If you don't beleave it or not. I've taken out again (I've already
> switched them once) one bank of 512M ram and since then I've not
> had any panics anymore.
>
> Can a ram error occur after a system has been fine one month ?
Yes.
--
John
Hi all,
If you don't beleave it or not. I've taken out again (I've already
switched them once) one bank of 512M ram and since then I've not
had any panics anymore.
Can a ram error occur after a system has been fine one month ?
Martin
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
-
Terry Lambert wrote:
> Nate Lawson wrote:
> > > 0xc02fd315 is in pmap_remove_pages (/usr/src/sys/i386/i386/pmap.c:2941).
> > > 2936#ifdef PMAP_REMOVE_PAGES_CURPROC_ONLY
> > > 2937pte = vtopte(pv->pv_va);
> > > 2938#else
> > > 2939pte = pmap_pte_quick
Nate Lawson wrote:
> On Tue, 17 Sep 2002, Martin Blapp wrote:
> > Hope this helps people. After I've disabled the secondlevel
> > CPU cache, the panic is now always at the same place:
> >
> > 0xc02fd315 is in pmap_remove_pages (/usr/src/sys/i386/i386/pmap.c:2941).
> > 2936#ifdef PMAP_REMOVE_P
Nate Lawson wrote:
> > 0xc02fd315 is in pmap_remove_pages (/usr/src/sys/i386/i386/pmap.c:2941).
> > 2936#ifdef PMAP_REMOVE_PAGES_CURPROC_ONLY
> > 2937pte = vtopte(pv->pv_va);
> > 2938#else
> > 2939pte = pmap_pte_quick(pv->pv_pmap, pv->pv_va);
> > 294
Hi,
> Try building your kernel with "options PMAP_REMOVE_PAGES_CURPROC_ONLY" and
> see if the panic goes away. If that works, the problem is
> pmap_pte_quick().
I'll do ASAP. I'm at work at the moment, and the box in question is
at home :).
Thanks very much for looking into that !
> In looki
On Tue, 17 Sep 2002, Martin Blapp wrote:
> Hope this helps people. After I've disabled the secondlevel
> CPU cache, the panic is now always at the same place:
>
> 0xc02fd315 is in pmap_remove_pages (/usr/src/sys/i386/i386/pmap.c:2941).
> 2936#ifdef PMAP_REMOVE_PAGES_CURPROC_ONLY
> 2937
Hi all,
Hope this helps people. After I've disabled the secondlevel
CPU cache, the panic is now always at the same place:
0xc02fd315 is in pmap_remove_pages (/usr/src/sys/i386/i386/pmap.c:2941).
2936#ifdef PMAP_REMOVE_PAGES_CURPROC_ONLY
2937pte = vtopte(pv->pv_va);
2938
24 matches
Mail list logo
