Date: 23 Aug 2002 15:09:59 +0400 From: "Vladimir B. " Grebenschikov <vova@sw.ru> To: Terry Lambert <tlambert2@mindspring.com> Cc: Mark Santcroos <marks@ripe.net>, Soeren Schmidt <sos@freebsd.dk>, Martin Blapp <mb@imp.ch>, Don Lewis <dl-freebsd@catspoiler.org>, ktsin@acm.org, freebsd-current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Memory corruption in CURRENT Message-ID: <1030100999.888.18.camel@vbook.express.ru> In-Reply-To: <3D64C9C2.30A37BF8@mindspring.com> References: <200208220909.g7M99NcS077303@freebsd.dk> <3D64B005.6657A3B5@mindspring.com> <20020822100014.GA17143@ripe.net> <3D64BA1F.B3C8C8E0@mindspring.com> <20020822102553.GA17453@ripe.net> <3D64C9C2.30A37BF8@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
χ Thu, 22.08.2002, Χ 15:23, Terry Lambert ΞΑΠΙΣΑΜ:
> Mark Santcroos wrote:
> > On Thu, Aug 22, 2002 at 03:17:03AM -0700, Terry Lambert wrote:
> > > Mark Santcroos wrote:
> > > > On Thu, Aug 22, 2002 at 02:33:57AM -0700, Terry Lambert wrote:
> > > > > options DISABLE_PSE
> > > > > options DISABLE_PG_G
> > > >
> > > > Coming up next in this theater :-)
> > > >
> > > > btw, how does the report that using the other compiler fixed everything
> > > > for KT fit in?
> >
> > It looks indeed like it is a 'winner'. The buildworld is still running but
> > getting further already than the previous 10.
>
> Ugh! Wait until it seems to work for a statistically significant
> sample size, and for more than one person before calling it "happy"!
>
> Also, I'm not sure looking at the code whether or not the PG_G is
> truly significant, or just preterbs the workaround. The problem
> I've referred to in my "hunch" here is actually related solely to
> the PSE, but with the recent code reorganization in locore.s, etc.,
> it could have become more significant.
>
>
> > > Coincidentally. It's hard to trigger the bug, so it's easy to
> > > work around it accidently.
> >
> > Thats very true indeed. I can take that as a good 'explanation'.
> >
> > I remember you talking about this PSE problems earlier and more often. Is
> > it fixable? I assume we would like to turn these options back on as they
> > improve performance don't they?
>
> Yes and yes, but it could be pretty ugly. It would be better to
> get more data from people who are seeing the problem. It may be
> that it's just similar symptoms and more than one proot cause,
> etc., so I'm pretty loathe to make any assumptions.
I have experience problem like this, after successful boot my notebook
(SONY VAIO z505s) can panic in more or less random place under heavy
load, often while gdm login (gnome startup not easy task).
One of backtraces below, I have more or less stable panic (aprox. 2 of 3
tries - panic). I don't run buildworld on netebook often.
I will try DISABLE_PSE and DISABLE_PG_G
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x28
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc015099f
stack pointer = 0x10:0xcd509c7c
frame pointer = 0x10:0xcd509c94
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 23 (irq14: ata0)
kernel: type 12 trap, code=0
Stopped at ata_dmadone+0xf: movl 0x4(%edi),%edx
db> tr
ata_dmadone(0,e289b5aa,0,cd509cc8,c38ba200) at ata_dmadone+0xf
ad_interrupt(c3ed88c0,c38b5200,cd509d04,c01c2ace,c38ba200) at
ad_interrupt+0x40d
ata_intr(c38ba200,0,0,0,c0d6a540) at ata_intr+0x146
ithread_loop(c38ba100,cd509d48,255f,0,3d638da4) at ithread_loop+0xbe
fork_exit(c01c2a10,c38ba100,cd509d48) at fork_exit+0x87
fork_trampoline() at fork_trampoline+0x1a
db>
> -- Terry
--
Vladimir B. Grebenschikov
vova@sw.ru, SWsoft, Inc.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1030100999.888.18.camel>