Date: Tue, 28 Nov 2000 01:40:38 +0100 From: Bernd Walter <ticso@cicely8.cicely.de> To: Wilko Bulte <wkb@freebie.demon.nl> Cc: Mike Eldridge <diz@cafes.net>, freebsd-current@freebsd.org Subject: Re: Patch for current on LCA based alphas Message-ID: <20001128014038.A44759@cicely8.cicely.de> In-Reply-To: <20001127224321.F1846@freebie.demon.nl>; from wkb@freebie.demon.nl on Mon, Nov 27, 2000 at 10:43:21PM %2B0100 References: <20001125193430.A40717@cicely8.cicely.de> <Pine.LNX.4.10.10011271439450.21970-100000@mail.cafes.net> <20001127224321.F1846@freebie.demon.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 27, 2000 at 10:43:21PM +0100, Wilko Bulte wrote:
> On Mon, Nov 27, 2000 at 02:42:52PM -0600, Mike Eldridge wrote:
> > On Sat, 25 Nov 2000, Bernd Walter wrote:
> > > LCA systems doesn't like probing after PCI slot 19.
> > > Probing slot 20 panics the system.
> > > The following patch made it into single user mode on my AXPpci33.
> > > I asume it will also work on multias.
> > > I can't tell more as the tested system is a 4.1-RELEASE and I need
> > > to update the world before further testing.
> >
> > Hmm, what exactly happens when slot 20 is probed? I remember my problems
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #0: Wed Nov 22 00:53:48 CET 2000
root@cicely9.cicely.de:/var/d8/src-2000-11-20/src/sys/compile/CICELY10
DEC AXPpci
Alpha PC AXPpci33, 166MHz
8192 byte page size, 1 processor.
CPU: LCA Family major=4 minor=2
OSF PAL rev: 0x100090002012d
real memory = 31481856 (30744K bytes)
avail memory = 24354816 (23784K bytes)
Preloaded elf kernel "kernel.ko" at 0xfffffc00006c2000.
lca0: <21066 Core Logic chipset>
fatal kernel trap:
trap entry = 0x2 (memory management fault)
a0 = 0xfffffbf1e0000018
a1 = 0x1
a2 = 0x0
pc = 0xfffffc0000557a10
ra = 0xfffffc000055791c
curproc = 0xfffffc000062f118
pid = 0, comm = swapper
Stopped at badaddr_read+0xd0: ldl t0,0(a0) <0xfffffbf1e0000018> <t0=0x1,a0=0xfffffbf1e0000018>
db> trace
badaddr_read() at badaddr_read+0xd0
badaddr() at badaddr+0x1c
lca_pcib_read_config() at lca_pcib_read_config+0x300
pci_read_device() at pci_read_device+0xb0
pci_add_children() at pci_add_children+0xe4
pci_probe() at pci_probe+0x1a0
device_probe_child() at device_probe_child+0x13c
device_probe_and_attach() at device_probe_and_attach+0x54
bus_generic_attach() at bus_generic_attach+0x28
device_probe_and_attach() at device_probe_and_attach+0xcc
bus_generic_attach() at bus_generic_attach+0x28
lca_attach() at lca_attach+0xa0
device_probe_and_attach() at device_probe_and_attach+0xcc
root_bus_configure() at root_bus_configure+0x38
configure() at configure+0x40
mi_startup() at mi_startup+0xf4
locorestart() at locorestart+0x6c
That's a problem I mentionend month ago on -alpha and the problems
mentioned for multias on the alpha list looks identic.
lca_pcib_read_config() is called with s=20 for existence probing here.
With this patch my host is running current without any problems.
> > with my Multia were related to PCI interrupts. It would spit out
> > "dec_axppci_33_intr_map: bad interrupt pin 192" about 50 or so times and
> > then panic.
I remember that I had read this.
Was this with current or stable?
If current you should try my patch otherwise check 4.2 first and tell us
about the result.
I can build you a boot disk if you need.
> I don't quite understand why my Multias ran without a hitch on 4.2RC1?
I'm running current.
I can can't say anything about stable beside that 4.1 worked fine on my
system.
--
B.Walter COSMO-Project http://www.cosmo-project.de
ticso@cicely.de Usergroup info@cosmo-project.de
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?20001128014038.A44759>