Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 29 Aug 2004 15:11:50 +0200
From:      Bernd Walter <ticso@cicely12.cicely.de>
To:        Wilko Bulte <wb@freebie.xs4all.nl>
Cc:        freebsd-alpha@freebsd.org
Subject:   Re: 5.3-BETA1 for Alpha available
Message-ID:  <20040829131149.GA59909@cicely12.cicely.de>
In-Reply-To: <20040829095002.GA43484@freebie.xs4all.nl>
References:  <Pine.LNX.4.33.0408290044080.15329-100000@servww6.ww.uni-erlangen.de> <20040829095002.GA43484@freebie.xs4all.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 29, 2004 at 11:50:02AM +0200, Wilko Bulte wrote:
> On Sun, Aug 29, 2004 at 01:40:33AM +0200, Gheorghe Ardelean wrote..
> > 
> > Hi Wilko,
> > 
> > I have at home a PWS 433au (MX5 motherboard) with TGA2 graphic
> > card and I have the same problem with BETA1 (fatal kernel trap while tring
> > to initialize the tga0 device).
> 
> It seems that a TGA2 is the kiss of death these days.  Does it boot 
> if you take the TGA card out?
> 
> > I have tested also on AlphaPC64 (via serial console but with S3 Virge
> > DX/GX video card  installed): the fatal kernel trap occurs again.
> 
> That is strange, I do not see that happen on a PC164sx equipped with an
> S3 VGA.
> 
> > On the AlphaPC 64 the serial console is running very slowly after booting
> > the kernel (maybe 300bps insetad of 9600)!
> > sc0: <System console> on isa0
> > sc0: VGA <16 virtual consoles, flags=0x0>
> > 
> > fatal kernel trap:
> > 
> >     trap entry     = 0x3 (instruction fault)
> >     cpuid          = 0
> >     fault type     = gentrap
> >     pc             = 0xfffffc0000735b64
> >     ra             = 0xfffffc000070df5c
> >     sp             = 0xfffffc0000e09b10
> >     usp            = 0x0
> >     curthread      = 0xfffffc00008c5cc8
> >         pid = 0, comm = swapper
> > 
> > [thread 0]
> > Stopped at      Ldotrap+0x8:    br      zero,Lret_result        <zero=0x0>
> > db> trace
> > Ldotrap() at Ldotrap+0x8
> > --- root of call graph ---
> > 
> > On AXPpci33 it dies while testing sym0. Before this sym0 reports:
> > sym0: <810> port 0x10100-0x101ff mem 0x81854100-0x818541ff at device 6.0 on pci0
> > sym0: No NVRAM, ID 7, Fast-10, SE, parity checking
> > CACHE TEST FAILED: timeout.
> > sym0: CACHE INCORRECTLY CONFIGURED.
> > 
> > fatal kernel trap:
> > 
> >     trap entry     = 0x4 (unaligned access fault)
> >     cpuid          = 0
> >     faulting va    = 0xdeadc0dedeadc0de

Mmm - it's dereferencing nonsense.
Guess this bug is old and just triggered as a result of the timeout.
I'm missing an IRQ in the probe, so the timeout is reasonable.
Normaly we should see:
sym0: interrupting at ISA irq 11
A complete boot -v output would be interessting to see routing
decisions - sounds much like someone broke IRQ routing on alpha.
LCA based alphas are the only alphas so far that we have enabled
interrupt routing and possibly the only alphas that share ISA and PCI
interrupts.

> >     opcode         = 0x29
> >     register       = 0x1
> >     pc             = 0xfffffc0000438138
> >     ra             = 0xfffffc0000438234
> >     sp             = 0xfffffc0000e098c0
> >     usp            = 0x0
> >     curthread      = 0xfffffc00008c5cc8
> >         pid = 0, comm = swapper
> > 
> > [thread 0]
> > Stopped at      ___sym_mfree+0x58:      beq     t0,___sym_mfree+0x64    <t0=0x0>
> > 
> > db> trace
> > ___sym_mfree() at ___sym_mfree+0x58
> > --- root of call graph ---
> > 
> > ==
> > 
> > All this machines run without problems FreeBSD version 4.x ( 7<= x <=9 )!
> 
> I'm wondering if the new compiler in 5.x has any relation to this problem.

What exactly is an instruction fault?
If it's an unavailable opcode then maybe.
 
> I have installed that same PC164sx with an 810 driven CDROM drive
> without problems.

We don't have to do anything special with interrupts on PC164* systems.

> Hmm.... Both PC64 and AXPpci33 are EV4x machines..  Hmm.. all my test
> boxes are >= EV5

To be exact AXPpci33 is LCA with an 21066 CPU or LCA45 with an 21066A
CPU, which is very similar to EV4 and EV45.
It seems that those boards are sold with 21066 CPUs only and that
21066A only made it into Alphabooks and maybe some Multias.
But EV5 is just a different core without (AFAIK) any changes to the
opcodes.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd@bwct.de                                  info@bwct.de



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040829131149.GA59909>