alpha/50659: reboot causes SRM console to loop endless error
and needs to be restetted hard
Wilko Bulte
wkb at freebie.xs4all.nl
Thu Apr 10 14:09:07 PDT 2003
On Thu, Apr 10, 2003 at 12:33:03AM +0200, Jens Röder wrote:
> > That is a kernel panic, not a memory problem ;)
> >
> > Most Alphas, and your AS500 too, have ECC (error correction) memory. That allows
> > single bit memory errors to be corrected. The kernel will tell you if a
> > correction was applied, these are the processor correctable errors I
> > mentioned.
>
> Hm, sounds interesting, so that does mean for me that in the case of a
> hardware memory problem I would get a kernel-message and don't need to do
> any memory checks?
Yes. If there are multibit errors ECC won't be able to correct them. I
don't know what the kernel will tell you in such a case as I never had
such a problem ;-) But is will most likely crash after reporting
a machine check (see the the code is in /sys/alpha/alpha/interrupt.c)
> > Unaligned accesses in kernel mode are Bad(TM). Check the handbook on
> > creating more debug info on the crash please.
>
> I am not sure if I did the right thing, so there is a core file now
> available at:
>
> http://octopus.homeunix.net/jens@piero.ptch.nat.tu-bs.de.gz
> fatal kerneltrap:
>
> trapentry = 0x4 (unaligned access fault)
> cpuid = 0
> faulting va = 0xfffffc0031d12d0c
> opcode = 0x2d
> register = 0x9
> pc = 0xfffffe0004138bc0
> ra = 0xfffffe0004138bb4
> sp = 0xfffffe001da7db70
> usp = 0x11fff628
>
> curthread = 0xfffffc003e2c87c0
> pid 593, comm ipfw
> Stopped at ipfw_ctl+0x1c0; or zero, s0,t2
> <zero=0x0,s0=0xfffffc0031d12d0c,t2=0x2710>
Right.. looks like ipfw is not really up to snuff for the 64bit
Alpha ;)
> Again, when you use "ipfw show" on 5.0 on alpha, you get messages like
> this:
>
> ptchgate# ipfw show
> 00100 94 10410 allow ip from any to any via lo0
> 00200 0 0 deny ip from any to 127.0.0.0/8
> pid 585 (ipfw): unaligned access: va=0x1200a80b4 pc=0x120001780
> ra=0x120001764 op=ldq
> pid 585 (ipfw): unaligned access: va=0x1200a80bc pc=0x120001784
> ra=0x120001764 op=ldq
> 00300 0 0 deny ip from 127.0.0.0/8 to any
> 65000 921 89561 allow ip from any to any
> 65535 0 0 deny ip from any to any
>
>
> It gets more likely to crash, when my set of rules are specified and list
> the rule then.
I will give this ruleset a try on my AS500
> This does not occur on 5.0 for i386, what seems to run stable yet.
x86 is what ipfw was developed on, a 32bit CPU ;)
>
> Bus 00 Slot 12: Vendor: 10ec Device: 8139 Sub_id 813910ec
^-- is that a network card?
> Well, I hope, there was something productive for debugging in my mail. I
> am sorry if I appear to be very unexperienced in FreeBSD, but I am just
> getting started.
Sure, this helps. I will try to see if I can make my AS500 fail in the same
way.
--
| / o / /_ _ wilko at FreeBSD.org
|/|/ / / /( (_) Bulte
More information about the freebsd-alpha
mailing list