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
=F7 Thu, 22.08.2002, =D7 15:23, Terry Lambert =CE=C1=D0=C9=D3=C1=CC:
> 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 everyt=
hing
> > > > for KT fit in?
> >=20
> > It looks indeed like it is a 'winner'. The buildworld is still running =
but
> > getting further already than the previous 10.
>=20
> Ugh! Wait until it seems to work for a statistically significant
> sample size, and for more than one person before calling it "happy"!
>=20
> 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.
>=20
>=20
> > > Coincidentally. It's hard to trigger the bug, so it's easy to
> > > work around it accidently.
> >=20
> > Thats very true indeed. I can take that as a good 'explanation'.
> >=20
> > 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 the=
y
> > improve performance don't they?
>=20
> 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.=20
I have experience problem like this, after successful boot my notebook=20
(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 =3D 0x28
fault code =3D supervisor read, page not present
instruction pointer =3D 0x8:0xc015099f
stack pointer =3D 0x10:0xcd509c7c
frame pointer =3D 0x10:0xcd509c94
code segment =3D base 0x0, limit 0xfffff, type 0x1b
=3D DPL 0, pres 1, def32 1, gran 1
processor eflags =3D interrupt enabled, resume, IOPL =3D 0
current process =3D 23 (irq14: ata0)
kernel: type 12 trap, code=3D0
Stopped at ata_dmadone+0xf: movl 0x4(%edi),%edx
db> tr=20
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>=20
=20
> -- Terry
=20
--=20
Vladimir B. Grebenschikov
vova@sw.ru, SWsoft, Inc.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" 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>