Date: Mon, 1 Sep 2008 18:18:50 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Gavin Atkinson <gavin@FreeBSD.org>, gibbs@FreeBSD.org Cc: freebsd-sparc64@FreeBSD.org Subject: Re: HEAD panic with ofw_pcibus.c 1.21 on Blade 100 Message-ID: <20080901161850.GE80839@alchemy.franken.de> In-Reply-To: <1220278827.70590.35.camel@buffy.york.ac.uk> References: <1220278827.70590.35.camel@buffy.york.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 01, 2008 at 03:20:27PM +0100, Gavin Atkinson wrote:
> Hi all,
>
> My Blade 100 now panics on boot with HEAD, and I've tracked it down to
> sys/sparc64/pci/ofw_pcibus.c 1.21 (SVN r182108) by marius@.
> Specifically, this version now configures bridges differently, and not
> setting "Master Abort Mode" prevents the panic:
>
> Index: src/sys/sparc64/pci/ofw_pcibus.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/sparc64/pci/ofw_pcibus.c,v
> retrieving revision 1.21
> diff -u -r1.21 ofw_pcibus.c
> --- src/sys/sparc64/pci/ofw_pcibus.c 24 Aug 2008 15:05:46 -0000 1.21
> +++ src/sys/sparc64/pci/ofw_pcibus.c 1 Sep 2008 14:09:27 -0000
> @@ -140,7 +140,7 @@
> PCIM_HDRTYPE) == PCIM_HDRTYPE_BRIDGE) {
> reg = PCIB_READ_CONFIG(bridge, busno, slot, func,
> PCIR_BRIDGECTL_1, 1);
> - reg |= PCIB_BCR_MASTER_ABORT_MODE | PCIB_BCR_SERR_ENABLE |
> + reg |= /* PCIB_BCR_MASTER_ABORT_MODE | */ PCIB_BCR_SERR_ENABLE |
> PCIB_BCR_PERR_ENABLE;
> #ifdef OFW_PCI_DEBUG
> device_printf(bridge,
>
>
>
> My Blade 100 (dmesg and panic backtrace attached) has three extra ATI
> graphics cards installed (Official Sun ones, PN 370-4362), it doesn't
> panic with these removed. Removing them and throwing a generic fxp(4)
> card into one of the slots also gives the panic, so I suspect having
> anything in at least one of the slots will cause a panic for me.
>
> I'm pretty sure the panic is not hardware related, as the machine will
> happily run Solaris 10.
>
> Any suggestions? Are we missing some code necessary to support master
> mode aborts? I'm happy to test anything necessary. This code was also
> MFC'd, so I'm concerned about seeing 7.1 also have this issue.
>
<...>
> machfb0: <ATI Rage XL> port 0xb00-0xbff mem 0x3000000-0x3ffffff,0x426000-0x426fff at device 19.0 on pci0
> machfb0: 16 MB aperture at 0xd5906000, 1 KB registers at 0x037ffc00
> machfb0: 8188 KB SDRAM 114.992 MHz, maximum RAMDAC clock 230 MHz, DSP
> machfb0: resolution 1152x900 at 8 bpp
> pcib1: <OFW PCI-PCI bridge> at device 5.0 on pci0
> pci1: <OFW PCI bus> on pcib1
> pcib1: device 1/0/0: latency timer 64 -> 64
> pcib1: device 1/1/0: latency timer 64 -> 64
> pcib1: device 1/2/0: latency timer 64 -> 64
> machfb1: <ATI Rage XL> port 0x1000-0x10ff mem 0x4000000-0x4ffffff,0x5000000-0x5000fff at device 0.0 on pci1
> machfb1: 16 MB aperture at 0xd6908000, 1 KB registers at 0x047ffc00
> machfb1: 8188 KB SGRAM 114.992 MHz, maximum RAMDAC clock 230 MHz, DSP
> machfb1: resolution 1152x900 at 8 bpp
> machfb2: <ATI Rage XL> port 0x1100-0x11ff mem 0x6000000-0x6ffffff,0x5002000-0x5002fff at device 1.0 on pci1
> machfb2: 16 MB aperture at 0xd790a000, 1 KB registers at 0x067ffc00
> machfb2: 8188 KB SGRAM 114.992 MHz, maximum RAMDAC clock 230 MHz, DSP
> machfb2: resolution 1152x900 at 8 bpp
> machfb3: <ATI Rage XL> port 0x1200-0x12ff mem 0x7000000-0x7ffffff,0x5004000-0x5004fff at device 2.0 on pci1
> machfb3: 16 MB aperture at 0xd890c000, 1 KB registers at 0x077ffc00
> machfb3: 8188 KB SGRAM 114.992 MHz, maximum RAMDAC clock 230 MHz, DSP
> machfb3: resolution 1152x900 at 8 bpp
> syscons0: <System console> on nexus0
> syscons0: Unknown <16 virtual consoles, flags=0x100>
> panic: pcib: PCI bus A error AFAR 0x1fe02001c80 AFSR 0x4000000100000000
> cpuid = 0
> KDB: enter: panic
> [thread pid 0 tid 100000 ]
> Stopped at kdb_enter+0x80: ta %xcc, 1
> db> tr
> Tracing pid 0 tid 100000 td 0xc07d2e70
> panic() at panic+0x208
> psycho_pci_bus() at psycho_pci_bus+0x88
> intr_event_handle() at intr_event_handle+0x5c
> intr_execute_handlers() at intr_execute_handlers+0x14
> intr_fast() at intr_fast+0x68
> -- interrupt level=0xd pil=0 %o7=0xc02ea55c --
> -- data access error %o7=0xc0c1757c --
> ahc_isa_find_device() at ahc_isa_find_device+0x50
> ahc_isa_identify() at ahc_isa_identify+0xd8
> bus_generic_probe() at bus_generic_probe+0x64
> isa_probe_children() at isa_probe_children+0x4
> configure() at configure+0x2c
> mi_startup() at mi_startup+0x18c
> btext() at btext+0x34
> db>
>
The most likely reason for this is a buggy driver. In this
case the culprit appears to be the ISA front-end of ahc(4),
which assumes that it can do bus space reads and writes at
addresses that may in fact be assigned to a non-ahc(4)-
compatible device or none at all. While writing something
at an address that may no belong to the expected device
probably is a bad idea in generally, reading to and writing
from unassigned addresses may also trigger exceptions on
sparc64. I'm unsure how to really fix ahc(4) regarding this,
I think it should be okay though to only do it on i386 where
the address range in question probably is reserved for such
purposes (and which also is the only architecture FreeBSD
currently runs on where a machine might have an ISA-slot
and thus can use that front-end at all).
Justin, do you approve the below patch?
Marius
Index: ahc_isa.c
===================================================================
--- ahc_isa.c (revision 182474)
+++ ahc_isa.c (working copy)
@@ -82,6 +82,12 @@ ahc_isa_identify(driver_t *driver, device_t parent
int slot;
int max_slot;
+#if !defined(__i386__)
+ /*
+ * Don't assume we can get away with the blind bus space
+ * reads and writes which ahc_isa_find_device() does.
+ */
+#endif
max_slot = 14;
for (slot = 0; slot <= max_slot; slot++) {
struct aic7770_identity *entry;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080901161850.GE80839>