From bugmaster at FreeBSD.org Mon Sep 1 11:07:03 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 1 11:08:59 2008 Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org Message-ID: <200809011107.m81B72Qa068572@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC o sparc/80410 sparc64 [netgraph] netgraph is causing crash with mpd on sparc o sparc/80890 sparc64 [panic] kmem_malloc(73728): kmem_map too small running o sparc/95297 sparc64 vt100 term does not work in install o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 f sparc/105607 sparc64 [modules] modules on sparc64 don't work with >= 4GB f sparc/106251 sparc64 [libmalloc] malloc fails > for large allocations s sparc/107087 sparc64 system is hinged during boot from CD o sparc/109908 sparc64 apache22 mod_perl issue on sparc64 o sparc/113556 sparc64 panic: trap: memory address not aligned; Rebooting... o sparc/118932 sparc64 7.0-BETA4/sparc-64 kernel panic in rip_output o sparc/119017 sparc64 7.0 Beta won't install on U60 s sparc/119239 sparc64 gdb coredumps on sparc64 o sparc/119244 sparc64 X11Forwarding to X11 server on sparc crashes Xorg 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f sparc/105157 sparc64 No reply to ping on Sparc64 f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 o sparc/119240 sparc64 top has WCPU over 100% on UP system 3 problems total. From gavin at FreeBSD.org Mon Sep 1 14:39:46 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Mon Sep 1 14:39:53 2008 Subject: HEAD panic with ofw_pcibus.c 1.21 on Blade 100 Message-ID: <1220278827.70590.35.camel@buffy.york.ac.uk> 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. Thanks, Gavin -------------- next part -------------- jumping to kernel entry at 0xc0078000. GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2008 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #10: Mon Sep 1 12:25:27 BST 2008 root@violet.york.ac.uk:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "tick" frequency 502000000 Hz quality 1000 real memory = 536870912 (512 MB) avail memory = 506454016 (482 MB) cpu0: Sun Microsystems UltraSparc-IIe Processor (502.00 MHz CPU) registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set kbd0 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413, REGOPS_FUNC) nexus0: pcib0: mem 0x1fe00000000-0x1fe0000ffff,0x1fe01000000-0x1fe010000ff irq 2032,2030,2031,2021 on nexus0 pcib0: Hummingbird compatible, impl 0, version 0, IGN 0x1f, bus A pcib0: [FILTER] pcib0: [FILTER] pcib0: [GIANT-LOCKED] pcib0: [ITHREAD] pcib0: DVMA map: 0xc0000000 to 0xc3ffffff pcib0: [FILTER] pci0: on pcib0 pcib0: device 0/12/0: latency timer 64 -> 80 pcib0: device 0/7/0: latency timer 0 -> 64 pcib0: device 0/12/1: latency timer 64 -> 80 pcib0: device 0/12/2: latency timer 64 -> 80 pcib0: device 0/12/3: latency timer 64 -> 80 pcib0: device 0/3/0: latency timer 0 -> 64 pcib0: device 0/8/0: latency timer 64 -> 16 pcib0: device 0/13/0: latency timer 64 -> 16 pcib0: device 0/19/0: latency timer 64 -> 64 pcib0: bridge 0/5/0: control 0x0 -> 0x23 pcib0: bridge 0/5/0: latency timer 0 -> 64 pcib0: device 0/5/0: latency timer 64 -> 64 ebus0: mem 0xf0000000-0xf0ffffff,0xf1000000-0xf17fffff at device 12.0 on pci0 ebus0: : incomplete ebus0: addr 0-0xfffff (no driver attached) eeprom0: addr 0x100000000-0x100001fff on ebus0 eeprom0: model mk48t59 isab0: at device 7.0 on pci0 isa0: on isab0 gem0: mem 0x400000-0x41ffff at device 12.1 on pci0 miibus0: on gem0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto gem0: 2kB RX FIFO, 2kB TX FIFO gem0: Ethernet address: 00:03:ba:1d:8d:7f gem0: [ITHREAD] fwohci0: mem 0x420000-0x4207ff,0x422000-0x4227ff at device 12.2 on pci0 fwohci0: [FILTER] fwohci0: OHCI version 1.0 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:03:ba:ff:fe:1d:8d:7f fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0xc1128000 fwip0: on firewire0 fwip0: Firewire address: 00:03:ba:ff:fe:1d:8d:7f @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:03:ba:1d:8d:7f fwe0: Ethernet address: 02:03:ba:1d:8d:7f fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode ohci0: mem 0x2000000-0x2007fff at device 12.3 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: <(0x108e) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0 uhub0: 4 ports with 4 removable, self powered pci0: at device 3.0 (no driver attached) pci0: at device 8.0 (no driver attached) atapci0: port 0xa00-0xa07,0xa18-0xa1b,0xa10-0xa17,0xa08-0xa0b,0xa20-0xa2f at device 13.0 on pci0 atapci0: [ITHREAD] atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug, expect reduced performance ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] machfb0: 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: at device 5.0 on pci0 pci1: 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: 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: 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: 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: 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> Next lines to be printed if the panic didn't occur: uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 43 on isa0 uart0: [FILTER] uart0: console (9600,n,8,1) uart1: <16550 or compatible> at port 0x2e8-0x2ef irq 43 on isa0 uart1: [FILTER] Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ad0: 19092MB at ata2-master UDMA66 acd0: CDRW at ata2-slave UDMA33 WARNING: WITNESS option enabled, expect reduced performance. From gavin at FreeBSD.org Mon Sep 1 16:20:46 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Mon Sep 1 16:20:52 2008 Subject: HEAD panic with ofw_pcibus.c 1.21 on Blade 100 In-Reply-To: <1220278827.70590.35.camel@buffy.york.ac.uk> References: <1220278827.70590.35.camel@buffy.york.ac.uk> Message-ID: <1220286044.70590.43.camel@buffy.york.ac.uk> On Mon, 2008-09-01 at 15:20 +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, [snip] > Any suggestions? Are we missing some code necessary to support master > mode aborts? After further research (mainly involving eyeballing pci_pbm_err_handler() in OpenSolaris), it looks like we are indeed missing code to handle them. Therefore, until this code is written, I suspect the patch above is actually correct. Gavin From gavin at FreeBSD.org Mon Sep 1 16:42:11 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Mon Sep 1 16:42:17 2008 Subject: HEAD panic with ofw_pcibus.c 1.21 on Blade 100 In-Reply-To: <20080901161850.GE80839@alchemy.franken.de> References: <1220278827.70590.35.camel@buffy.york.ac.uk> <20080901161850.GE80839@alchemy.franken.de> Message-ID: <1220287328.70590.46.camel@buffy.york.ac.uk> On Mon, 2008-09-01 at 18:18 +0200, Marius Strobl wrote: > 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@. > 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; This patch (with the addition of a "return;" inside the #ifdef which I'm assuming was forgotten!) gets me booting again with stock ofw_pcibus.c. Thanks! Gavin -------------- next part -------------- A non-text attachment was scrubbed... Name: aic-noisa.diff Type: text/x-patch Size: 665 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20080901/97e8bce9/aic-noisa.bin From marius at alchemy.franken.de Mon Sep 1 16:56:24 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Mon Sep 1 16:56:31 2008 Subject: HEAD panic with ofw_pcibus.c 1.21 on Blade 100 In-Reply-To: <1220278827.70590.35.camel@buffy.york.ac.uk> References: <1220278827.70590.35.camel@buffy.york.ac.uk> Message-ID: <20080901161850.GE80839@alchemy.franken.de> 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: 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: at device 5.0 on pci0 > pci1: 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: 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: 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: 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: 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; From nwhitehorn at freebsd.org Mon Sep 1 17:51:04 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Mon Sep 1 17:51:34 2008 Subject: HEAD panic with ofw_pcibus.c 1.21 on Blade 100 In-Reply-To: <1220287328.70590.46.camel@buffy.york.ac.uk> References: <1220278827.70590.35.camel@buffy.york.ac.uk> <20080901161850.GE80839@alchemy.franken.de> <1220287328.70590.46.camel@buffy.york.ac.uk> Message-ID: <48BC1E52.7060200@freebsd.org> Gavin Atkinson wrote: > On Mon, 2008-09-01 at 18:18 +0200, Marius Strobl wrote: >> 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@. > >> 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? Speaking of ahc(4), I have one in my Ultra 5 which will not work unless I have options AHC_ALLOW_MEMIO in my kernel config. I think this option should always be valid for sparc64 systems. Can it be in the default kernel? -Nathan From marius at alchemy.franken.de Mon Sep 1 19:46:34 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Mon Sep 1 19:46:40 2008 Subject: HEAD panic with ofw_pcibus.c 1.21 on Blade 100 In-Reply-To: <1220286044.70590.43.camel@buffy.york.ac.uk> References: <1220278827.70590.35.camel@buffy.york.ac.uk> <1220286044.70590.43.camel@buffy.york.ac.uk> Message-ID: <20080901194632.GF80839@alchemy.franken.de> On Mon, Sep 01, 2008 at 05:20:44PM +0100, Gavin Atkinson wrote: > On Mon, 2008-09-01 at 15:20 +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, > > [snip] > > > Any suggestions? Are we missing some code necessary to support master > > mode aborts? > > After further research (mainly involving eyeballing > pci_pbm_err_handler() in OpenSolaris), it looks like we are indeed > missing code to handle them. Therefore, until this code is written, I > suspect the patch above is actually correct. > While not setting master abort mode on PCI-PCI-bridges might hide your problem, the right place for ignoring master and (in this case) target aborts, both of which are fatal in general though, would be the host-PCI-bridge. Similarly, support for peeking and poking of I/O and memory space like OpenSolaris apparently has (the associated recovery handlers probably are the code you're refering to) should be implemented PCI-bus wide and not just grounded at PCI-PCI-bridges. I don't think there's a real need to go through the hoops to support these in FreeBSD though. The blind bus access ahc(4) ISA front-end does is also what hangs B100 during boot even with master abort mode in the PCI-PCI-bridges I think. We're looking at several problems here though and IMO the first one is that ahc(4) shouldn't try to identify cards on LPC(-like) busses and the respective code also only should be compiled in on architectures where machine actually can have ISA slots (which currently is only i386 AFAICT). Marius From marius at alchemy.franken.de Mon Sep 1 19:47:28 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Mon Sep 1 19:47:35 2008 Subject: HEAD panic with ofw_pcibus.c 1.21 on Blade 100 In-Reply-To: <1220287328.70590.46.camel@buffy.york.ac.uk> References: <1220278827.70590.35.camel@buffy.york.ac.uk> <20080901161850.GE80839@alchemy.franken.de> <1220287328.70590.46.camel@buffy.york.ac.uk> Message-ID: <20080901194726.GG80839@alchemy.franken.de> On Mon, Sep 01, 2008 at 05:42:08PM +0100, Gavin Atkinson wrote: > On Mon, 2008-09-01 at 18:18 +0200, Marius Strobl wrote: > > 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@. > > > 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; > > This patch (with the addition of a "return;" inside the #ifdef which I'm > assuming was forgotten!) gets me booting again with stock ofw_pcibus.c. Oops, the "return;" was missing of course. Marius From gibbs at scsiguy.com Mon Sep 1 21:38:06 2008 From: gibbs at scsiguy.com (Justin T. Gibbs) Date: Mon Sep 1 21:38:13 2008 Subject: HEAD panic with ofw_pcibus.c 1.21 on Blade 100 In-Reply-To: <20080901194726.GG80839@alchemy.franken.de> References: <1220278827.70590.35.camel@buffy.york.ac.uk> <20080901161850.GE80839@alchemy.franken.de> <1220287328.70590.46.camel@buffy.york.ac.uk> <20080901194726.GG80839@alchemy.franken.de> Message-ID: <48BC5AF8.50600@scsiguy.com> The driver isn't buggy. This particular hardware can only be identified via an invasive probe. Just returning early is a hack. How does Sparc64 exclude other, non-PNP devices from its probe sequence? They all have #ifdefs in them for Sparc64 and every other platform that gives a bus fault for touching a location that is unmapped? There's no generic method for trapping bus faults during invasive probes so that panics are avoided? There's no generic method for flagging probes as invasive so that they simply are never called (or compiled in) on platforms that cannot tolerate them? If you absolutely have to remove the probe just for sparc, it would be better to figure out how to just avoid compiling in that probe (config spec change "optional isa_nonpnp", or similar?). -- Justin Marius Strobl wrote: > On Mon, Sep 01, 2008 at 05:42:08PM +0100, Gavin Atkinson wrote: >> On Mon, 2008-09-01 at 18:18 +0200, Marius Strobl wrote: >>> 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@. >>> 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; >> This patch (with the addition of a "return;" inside the #ifdef which I'm >> assuming was forgotten!) gets me booting again with stock ofw_pcibus.c. > > Oops, the "return;" was missing of course. > > Marius > > From marius at alchemy.franken.de Mon Sep 1 23:16:07 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Mon Sep 1 23:16:14 2008 Subject: HEAD panic with ofw_pcibus.c 1.21 on Blade 100 In-Reply-To: <48BC5AF8.50600@scsiguy.com> References: <1220278827.70590.35.camel@buffy.york.ac.uk> <20080901161850.GE80839@alchemy.franken.de> <1220287328.70590.46.camel@buffy.york.ac.uk> <20080901194726.GG80839@alchemy.franken.de> <48BC5AF8.50600@scsiguy.com> Message-ID: <20080901231604.GH80839@alchemy.franken.de> On Mon, Sep 01, 2008 at 03:13:28PM -0600, Justin T. Gibbs wrote: > The driver isn't buggy. This particular hardware can only be identified > via an invasive probe. I meant misbehaving from the sparc64 point of view, not buggy in general. > > Just returning early is a hack. How does Sparc64 exclude other, non-PNP > devices from its probe sequence? It doesn't and invasive probes involving I/O or memory space accesses aren't supported. There are no ISA-slots in sparc64 machines and in general one can only regard the devices in the device tree provided by the firmware (which one can consider as PNP-mechanism) as existent and functional so supporting invasive probes or non-PNP devices doesn't make much sense from a hardware point of view. > They all have #ifdefs in them for > Sparc64 and every other platform that gives a bus fault for touching > a location that is unmapped? The other ISA drivers doing invasive probes aren't relevant for sparc64 as they either simply can't show up in a sparc64 machine. Some drivers with multiple bus front-ends also aren't in GENERIC as their core f.e. doesn't use bus_dma(9) or isn't endian-clean and therefore doesn't work on sparc64 so far anyway. It's just ahc(4) which is in GENERIC as the PCI variant works but brings in an invasive probe. > There's no generic method for trapping > bus faults during invasive probes so that panics are avoided? There's a procedure for configuration space accesses but for I/O and memory space one can really just ignore bus faults if there's a way to tell the host-to-foo driver that they are expected f.e. due to invasive probing. > There's > no generic method for flagging probes as invasive so that they > simply are never called (or compiled in) on platforms that cannot > tolerate them? Not as far as I can tell. > > If you absolutely have to remove the probe just for sparc, it would > be better to figure out how to just avoid compiling in that probe > (config spec change "optional isa_nonpnp", or similar?). What I think would be the right thing to do in this regard is splitting the ISA drivers and bus front-ends into bus front-ends for LPC or LPC-like busses (i.e. on-board PNP- only/firmware enumerated) and real ISA busses (non-PNP, cards in real slots). Though as far as I know there's more to LPC in terms of ACPI-probing which I currently don't understand and I admit that I'm reluctant to doing that much work just to keep a single bus front-end from probing... Marius From paulo.fessel at virtus-ti.com.br Tue Sep 2 21:00:07 2008 From: paulo.fessel at virtus-ti.com.br (Paulo Afonso Graner Fessel) Date: Tue Sep 2 21:00:21 2008 Subject: sparc64/127051: hme interfaces "pause" with the message "device timeout" on FreeBSD 7.0/sparc64 on an Enterprise 220R Message-ID: <200809022058.m82KwuWm012459@www.freebsd.org> >Number: 127051 >Category: sparc64 >Synopsis: hme interfaces "pause" with the message "device timeout" on FreeBSD 7.0/sparc64 on an Enterprise 220R >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-sparc64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 02 21:00:05 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Paulo Afonso Graner Fessel >Release: 7.0 >Organization: Virtus TI >Environment: FreeBSD vtsfprfw01.virtus-ti.com.br 7.0-RELEASE FreeBSD 7.0-RELEASE #7: Fri Jun 20 19:29:52 BRT 2008 root@vtsuprfw01.dedalusprime.com.br:/usr/obj/usr/src/sys/VIRTUSFW sparc64 >Description: We have a pair of UltraSparc II servers configured as HA-firewall with carp and pfsync. I noticed that even with an advskew of zero on the primary firewall (vtsfprfw01) the carp interfaces end up migrating to the backup firewall, which has an advskew of 200. Here's ifconfig for the primary firewall (master): hme0: flags=8843 metric 0 mtu 1500 options=b ether 08:00:20:d0:c3:dd inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet 100baseTX status: active hme1: flags=8b43 metric 0 mtu 1500 options=b ether 08:00:20:bc:a6:b4 inet 200.215.183.101 netmask 0xfffffff0 broadcast 200.215.183.111 media: Ethernet 100baseTX status: active hme2: flags=8b43 metric 0 mtu 1500 options=b ether 08:00:20:bc:a6:b5 inet 200.143.2.2 netmask 0xffffff00 broadcast 200.143.2.255 media: Ethernet 100baseTX status: active hme3: flags=8802 metric 0 mtu 1500 options=b ether 08:00:20:bc:a6:b6 media: Ethernet autoselect hme4: flags=8802 metric 0 mtu 1500 options=b ether 08:00:20:bc:a6:b7 media: Ethernet autoselect pflog0: flags=141 metric 0 mtu 33160 lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff000000 pfsync0: flags=41 metric 0 mtu 1460 pfsync: syncdev: hme0 syncpeer: 192.168.0.2 maxupd: 128 carp0: flags=49 metric 0 mtu 1500 inet 200.215.183.100 netmask 0xfffffff0 carp: BACKUP vhid 1 advbase 1 advskew 0 carp1: flags=49 metric 0 mtu 1500 inet 200.143.2.1 netmask 0xffffff00 carp: BACKUP vhid 2 advbase 1 advskew 0 And the same, for the second firewall (backup): vtsfprfw02# ifconfig -a hme0: flags=8843 metric 0 mtu 1500 options=b ether 08:00:20:e7:39:31 inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet 100baseTX status: active hme1: flags=8b43 metric 0 mtu 1500 options=b ether 08:00:20:bc:a3:a0 inet 200.215.183.102 netmask 0xfffffff0 broadcast 200.215.183.111 media: Ethernet 100baseTX status: active hme2: flags=8b43 metric 0 mtu 1500 options=b ether 08:00:20:bc:a3:a1 inet 200.143.2.3 netmask 0xffffff00 broadcast 200.143.2.255 media: Ethernet 100baseTX status: active hme3: flags=8802 metric 0 mtu 1500 options=b ether 08:00:20:bc:a3:a2 media: Ethernet autoselect hme4: flags=8802 metric 0 mtu 1500 options=b ether 08:00:20:bc:a3:a3 media: Ethernet autoselect pflog0: flags=141 metric 0 mtu 33160 lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff000000 pfsync0: flags=41 metric 0 mtu 1460 pfsync: syncdev: hme0 syncpeer: 192.168.0.1 maxupd: 128 carp0: flags=49 metric 0 mtu 1500 inet 200.215.183.100 netmask 0xfffffff0 carp: MASTER vhid 1 advbase 1 advskew 200 carp1: flags=49 metric 0 mtu 1500 inet 200.143.2.1 netmask 0xffffff00 carp: MASTER vhid 2 advbase 1 advskew 200 After noticing this, I also saw that "local-mac-address?" on the first firewall was set to "false", what caused all the interface ports to show the same MAC address. I've fixed this and rebooted the server, to investigate if this had something to do with the issue. Everything was alright during approximate 30 minutes, when the firewall has changed to the secondary machine. Here's an excerpt from /var/log/messages from the primary firewall: Sep 2 10:18:51 vtsfprfw01 ftp-proxy[929]: listening on 127.0.0.1 port 8021 Sep 2 10:18:51 vtsfprfw01 getty[943]: open /dev/ttyv2: No such file or directory Sep 2 10:18:51 vtsfprfw01 getty[945]: open /dev/ttyv4: No such file or directory Sep 2 10:18:51 vtsfprfw01 getty[941]: open /dev/ttyv0: No such file or directory Sep 2 10:18:51 vtsfprfw01 getty[948]: open /dev/ttyv7: No such file or directory Sep 2 10:18:51 vtsfprfw01 getty[946]: open /dev/ttyv5: No such file or directory Sep 2 10:18:51 vtsfprfw01 getty[944]: open /dev/ttyv3: No such file or directory Sep 2 10:18:51 vtsfprfw01 getty[942]: open /dev/ttyv1: No such file or directory Sep 2 10:18:51 vtsfprfw01 getty[947]: open /dev/ttyv6: No such file or directory Sep 2 10:18:58 vtsfprfw01 login: ROOT LOGIN (root) ON ttyu0 Sep 2 10:44:43 vtsfprfw01 kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) Sep 2 10:44:43 vtsfprfw01 kernel: hme2: device timeout Sep 2 10:44:48 vtsfprfw01 kernel: carp0: BACKUP -> MASTER (preempting a slower master) Sep 2 10:44:48 vtsfprfw01 kernel: arp_rtrequest: bad gateway 200.215.183.100 (!AF_LINK) Sep 2 11:11:48 vtsfprfw01 kernel: hme2: device timeout Sep 2 11:35:19 vtsfprfw01 kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) Sep 2 11:35:19 vtsfprfw01 kernel: hme2: device timeout Sep 2 11:35:24 vtsfprfw01 kernel: carp0: BACKUP -> MASTER (preempting a slower master) Sep 2 11:35:24 vtsfprfw01 kernel: arp_rtrequest: bad gateway 200.215.183.100 (!AF_LINK) Sep 2 13:37:16 vtsfprfw01 kernel: carp1: MASTER -> BACKUP (more frequent advertisement received) Sep 2 13:37:16 vtsfprfw01 kernel: hme1: device timeout Sep 2 13:37:17 vtsfprfw01 kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) Sep 2 16:11:06 vtsfprfw01 kernel: arp_rtrequest: bad gateway 200.143.2.1 (!AF_LINK) Sep 2 16:11:14 vtsfprfw01 kernel: carp1: MASTER -> BACKUP (more frequent advertisement received) As it can be seen from the logs, there's a number of messages like "hmeX: device timeout". When this happens, carp0 and carp1 see this as a disconnection and are forced to the secondary firewall. The most interesting is part is that I don't lose communication with either machines: I'm able to ping the first firewall normally after the event, and I don't get messages neither in the OS or on the switch pointing to link loss. The secondary server also shows the same problem (hmeX device timeout): Sep 1 15:58:00 vtsfprfw02 kernel: hme0: device timeout Sep 1 16:35:00 vtsfprfw02 kernel: hme0: device timeout Sep 1 16:35:40 vtsfprfw02 last message repeated 2 times Sep 1 16:45:33 vtsfprfw02 kernel: carp1: MASTER -> BACKUP (more frequent advertisement received) Sep 1 16:45:34 vtsfprfw02 kernel: hme1: device timeout Sep 1 16:45:35 vtsfprfw02 kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) Sep 1 16:45:47 vtsfprfw02 kernel: arp_rtrequest: bad gateway 200.215.183.100 (!AF_LINK) Sep 1 16:45:47 vtsfprfw02 kernel: carp1: BACKUP -> MASTER (preempting a slower master) Sep 1 16:45:47 vtsfprfw02 kernel: arp_rtrequest: bad gateway 200.143.2.1 (!AF_LINK) Sep 1 16:45:48 vtsfprfw02 kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) Sep 1 16:45:48 vtsfprfw02 kernel: carp0: BACKUP -> MASTER (preempting a slower master) Sep 1 16:45:48 vtsfprfw02 kernel: arp_rtrequest: bad gateway 200.215.183.100 (!AF_LINK) Sep 1 17:12:16 vtsfprfw02 kernel: carp1: MASTER -> BACKUP (more frequent advertisement received) Sep 1 17:12:16 vtsfprfw02 kernel: hme1: device timeout Sep 1 17:12:17 vtsfprfw02 kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) Sep 1 17:44:33 vtsfprfw02 kernel: arp: 200.215.183.110 is on hme1 but got reply from 00:14:d1:38:92:ba on hme2 Sep 1 17:45:05 vtsfprfw02 last message repeated 21 times Sep 1 17:45:27 vtsfprfw02 last message repeated 15 times Sep 1 18:55:48 vtsfprfw02 kernel: arp_rtrequest: bad gateway 200.215.183.100 (!AF_LINK) Sep 1 18:55:48 vtsfprfw02 kernel: carp1: BACKUP -> MASTER (preempting a slower master) Sep 1 18:55:48 vtsfprfw02 kernel: arp_rtrequest: bad gateway 200.143.2.1 (!AF_LINK) Sep 1 18:55:48 vtsfprfw02 kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) Sep 1 18:55:49 vtsfprfw02 kernel: carp0: BACKUP -> MASTER (preempting a slower master) Sep 1 18:55:49 vtsfprfw02 kernel: arp_rtrequest: bad gateway 200.215.183.100 (!AF_LINK) Sep 1 19:24:43 vtsfprfw02 sshd[34638]: error: PAM: authentication error for pfessel from 201.20.234.104 Sep 1 19:24:46 vtsfprfw02 sshd[34641]: error: ssh_msg_send: write Sep 2 10:19:31 vtsfprfw02 kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) Sep 2 10:19:50 vtsfprfw02 kernel: arp: 200.143.2.2 moved from 08:00:20:d0:c3:dd to 08:00:20:bc:a6:b5 on hme2 Sep 2 10:19:51 vtsfprfw02 kernel: carp1: MASTER -> BACKUP (more frequent advertisement received) Sep 2 10:45:15 vtsfprfw02 kernel: arp_rtrequest: bad gateway 200.143.2.1 (!AF_LINK) Sep 2 10:45:15 vtsfprfw02 kernel: carp0: BACKUP -> MASTER (preempting a slower master) Sep 2 10:45:15 vtsfprfw02 kernel: arp_rtrequest: bad gateway 200.215.183.100 (!AF_LINK) Sep 2 10:45:20 vtsfprfw02 kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) Sep 2 10:45:26 vtsfprfw02 kernel: carp1: MASTER -> BACKUP (more frequent advertisement received) Sep 2 11:12:19 vtsfprfw02 kernel: arp_rtrequest: bad gateway 200.143.2.1 (!AF_LINK) Sep 2 11:12:32 vtsfprfw02 kernel: carp1: MASTER -> BACKUP (more frequent advertisement received) Sep 2 11:35:51 vtsfprfw02 kernel: arp_rtrequest: bad gateway 200.143.2.1 (!AF_LINK) Sep 2 11:35:51 vtsfprfw02 kernel: carp0: BACKUP -> MASTER (preempting a slower master) Sep 2 11:35:51 vtsfprfw02 kernel: arp_rtrequest: bad gateway 200.215.183.100 (!AF_LINK) Sep 2 11:35:56 vtsfprfw02 kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) Sep 2 11:36:06 vtsfprfw02 kernel: carp1: MASTER -> BACKUP (more frequent advertisement received) Sep 2 13:37:47 vtsfprfw02 kernel: arp_rtrequest: bad gateway 200.215.183.100 (!AF_LINK) Sep 2 13:37:48 vtsfprfw02 kernel: carp1: BACKUP -> MASTER (preempting a slower master) Sep 2 13:37:48 vtsfprfw02 kernel: arp_rtrequest: bad gateway 200.143.2.1 (!AF_LINK) Sep 2 13:37:48 vtsfprfw02 kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) Sep 2 13:37:49 vtsfprfw02 kernel: carp0: BACKUP -> MASTER (preempting a slower master) Sep 2 13:37:49 vtsfprfw02 kernel: arp_rtrequest: bad gateway 200.215.183.100 (!AF_LINK) Sep 2 14:01:06 vtsfprfw02 sshd[37221]: error: PAM: authentication error for root from 200.143.2.125 Sep 2 14:01:08 vtsfprfw02 sshd[37221]: error: PAM: authentication error for root from 200.143.2.125 Sep 2 16:07:37 vtsfprfw02 sshd[37559]: error: PAM: authentication error for root from 200.143.2.125 Sep 2 16:08:17 vtsfprfw02 last message repeated 3 times Sep 2 16:08:35 vtsfprfw02 sshd[37559]: error: PAM: authentication error for root from 200.143.2.125 Sep 2 16:08:38 vtsfprfw02 sshd[37566]: error: ssh_msg_send: write Sep 2 16:08:50 vtsfprfw02 sshd[37567]: error: PAM: authentication error for root from 200.143.2.125 Sep 2 16:09:00 vtsfprfw02 last message repeated 5 times Sep 2 16:11:40 vtsfprfw02 kernel: hme2: device timeout This log is even more interesting, as it's shown here there's the first transition of the carp interfaces from MASTER to BACKUP from when I first rebooted the master firewall to fix the eeprom issue; but there are also other transitions from BACKUP to MASTER to BACKUP to MASTER again, which haven't been logged in the master firewall! Now, some background information about network topology. * carp0 is connected to hme1 in both servers (master and backup), and points to our default internet gateway; * carp1 is connected to hme2 in both servers (master and backup), and points to our data center's front-end network (200.143.2.0/24) * pfsync0 is associated to hme0 in both servers. We don't use a back-to-back connection via crossover cable, but instead we use a dedicated VLAN on one of our switches. Because of this I've chosen to specify syncpeers on both servers, with the master firewall pointing to the backup firewall and vice-versa, always using hme0 as the physical device for pfsync0. I've checked that VHIDs from other firewalls which use this VLAN don't coincide with the ones we use in this particular configuration. Finally, hardware configuration follows: * Master firewall: E220R with 2 USII 450 MHz processors, 2 SUN18G SCSI hard disks, 2 GB RAM, one Sun QFE PCI interface (hme1-hme4 ports) plus the onboard HME interface (hme0). * Backup firewall: E420R with 2 USII 450 MHz processors, 2 SUN18G SCSI hard disks, 2 GB RAM, one Sun QFE PCI interface (hme1-hme4 ports) plus the onboard HME interface (hme0). As you can see, both machines are nearly identical. My feeling is that this behaviour has something to do with something specific to sparc64 architecture, as I do have other 2 Sun QFE PCI boards running on Intel architecture (Dell Poweredges 1650 and 1750 respectively) and there are no such issues whatsoever. These i386 servers have already an uptime of 11 days and there is no "hmeX: device timeout" in either server. >How-To-Repeat: Just configure the networking in the servers as shown and then is just a question of time for the problem to appear. It can take days, hours, or minutes, but it will show up after some time. >Fix: >Release-Note: >Audit-Trail: >Unformatted: From marius at alchemy.franken.de Tue Sep 2 21:10:46 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Tue Sep 2 21:10:53 2008 Subject: HEAD panic with ofw_pcibus.c 1.21 on Blade 100 In-Reply-To: <20080901231604.GH80839@alchemy.franken.de> References: <1220278827.70590.35.camel@buffy.york.ac.uk> <20080901161850.GE80839@alchemy.franken.de> <1220287328.70590.46.camel@buffy.york.ac.uk> <20080901194726.GG80839@alchemy.franken.de> <48BC5AF8.50600@scsiguy.com> <20080901231604.GH80839@alchemy.franken.de> Message-ID: <20080902211043.GA21904@alchemy.franken.de> On Tue, Sep 02, 2008 at 01:16:04AM +0200, Marius Strobl wrote: > On Mon, Sep 01, 2008 at 03:13:28PM -0600, Justin T. Gibbs wrote: > > > > If you absolutely have to remove the probe just for sparc, it would > > be better to figure out how to just avoid compiling in that probe > > (config spec change "optional isa_nonpnp", or similar?). > > What I think would be the right thing to do in this regard > is splitting the ISA drivers and bus front-ends into bus > front-ends for LPC or LPC-like busses (i.e. on-board PNP- > only/firmware enumerated) and real ISA busses (non-PNP, > cards in real slots). Though as far as I know there's more > to LPC in terms of ACPI-probing which I currently don't > understand and I admit that I'm reluctant to doing that > much work just to keep a single bus front-end from probing... > Thinking some more about it I decided to work around the lack of distinction between LPC and real ISA at a different level. Marius From obrien at freebsd.org Tue Sep 2 22:09:54 2008 From: obrien at freebsd.org (David O'Brien) Date: Tue Sep 2 22:10:00 2008 Subject: HEAD panic with ofw_pcibus.c 1.21 on Blade 100 In-Reply-To: <48BC1E52.7060200@freebsd.org> References: <1220278827.70590.35.camel@buffy.york.ac.uk> <20080901161850.GE80839@alchemy.franken.de> <1220287328.70590.46.camel@buffy.york.ac.uk> <48BC1E52.7060200@freebsd.org> Message-ID: <20080902214634.GA86270@dragon.NUXI.org> On Mon, Sep 01, 2008 at 11:54:42AM -0500, Nathan Whitehorn wrote: > Speaking of ahc(4), I have one in my Ultra 5 which will not work unless I > have options AHC_ALLOW_MEMIO in my kernel config. I think this option > should always be valid for sparc64 systems. Can it be in the default Simple enough request - done for 8-CURRENT. From marius at alchemy.franken.de Thu Sep 4 22:00:04 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Thu Sep 4 22:00:11 2008 Subject: sparc64/127051: hme interfaces "pause" with the message "device timeout" on FreeBSD 7.0/sparc64 on an Enterprise 220R Message-ID: <200809042200.m84M04RA058382@freefall.freebsd.org> The following reply was made to PR sparc64/127051; it has been noted by GNATS. From: Marius Strobl To: Paulo Afonso Graner Fessel , bug-followup@FreeBSD.org Cc: Subject: Re: sparc64/127051: hme interfaces "pause" with the message "device timeout" on FreeBSD 7.0/sparc64 on an Enterprise 220R Date: Thu, 4 Sep 2008 23:25:15 +0200 On Tue, Sep 02, 2008 at 08:58:56PM +0000, Paulo Afonso Graner Fessel wrote: > > >Environment: > FreeBSD vtsfprfw01.virtus-ti.com.br 7.0-RELEASE FreeBSD 7.0-RELEASE #7: Fri Jun 20 19:29:52 BRT 2008 root@vtsuprfw01.dedalusprime.com.br:/usr/obj/usr/src/sys/VIRTUSFW sparc64 Please give 7.0-STABLE/7.1-PRERELEASE a try, there where several bugs in hme(4) fixed since 7.0-RELEASE. Marius From bugmaster at FreeBSD.org Mon Sep 8 02:22:28 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 8 02:24:14 2008 Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org Message-ID: <200809080222.m882MRoq006818@freefall.freebsd.org> The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/127051 sparc64 [hme] hme interfaces "pause" with the message "device o sparc/119244 sparc64 X11Forwarding to X11 server on sparc crashes Xorg o sparc/119240 sparc64 top has WCPU over 100% on UP system s sparc/119239 sparc64 gdb coredumps on sparc64 o sparc/119017 sparc64 7.0 Beta won't install on U60 o sparc/118932 sparc64 7.0-BETA4/sparc-64 kernel panic in rip_output o sparc/113556 sparc64 panic: trap: memory address not aligned; Rebooting... o sparc/109908 sparc64 apache22 mod_perl issue on sparc64 f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 s sparc/107087 sparc64 system is hinged during boot from CD f sparc/106251 sparc64 [libmalloc] malloc fails > for large allocations f sparc/105607 sparc64 [modules] modules on sparc64 don't work with >= 4GB f sparc/105157 sparc64 No reply to ping on Sparc64 o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/95297 sparc64 vt100 term does not work in install o sparc/80890 sparc64 [panic] kmem_malloc(73728): kmem_map too small running o sparc/80410 sparc64 [netgraph] netgraph is causing crash with mpd on sparc o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC 19 problems total. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned. From flo at kasimir.com Mon Sep 8 20:50:04 2008 From: flo at kasimir.com (Florian Smeets) Date: Mon Sep 8 20:50:18 2008 Subject: sparc64/105607: [modules] modules on sparc64 don't work with >= 4GB Message-ID: <200809082050.m88Ko3W7045050@freefall.freebsd.org> The following reply was made to PR sparc64/105607; it has been noted by GNATS. From: Florian Smeets To: bug-followup@FreeBSD.org, aledm@qix.co.uk Cc: Subject: Re: sparc64/105607: [modules] modules on sparc64 don't work with >= 4GB Date: Mon, 08 Sep 2008 22:24:53 +0200 This pr can indeed be closed. real memory = 6442450944 (6144 MB) avail memory = 6286655488 (5995 MB) flo@280r:~ 17 > kldstat Id Refs Address Size Name 1 3 0xc0000000 58f4a0 kernel (/boot/kernel/kernel) 2 1 0xc0590000 139ab0 geom_mirror.ko (/boot/kernel/geom_mirror.ko) This is 8-CURRENT btw. Cheers, Florian From linimon at FreeBSD.org Mon Sep 8 22:29:53 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Sep 8 22:30:06 2008 Subject: sparc64/105607: [modules] modules on sparc64 don't work with >= 4GB Message-ID: <200809082229.m88MTq1T053882@freefall.freebsd.org> Synopsis: [modules] modules on sparc64 don't work with >= 4GB State-Changed-From-To: feedback->closed State-Changed-By: linimon State-Changed-When: Mon Sep 8 22:29:19 UTC 2008 State-Changed-Why: Confirmed fixed in 7.0 and later. Thanks for the response. http://www.freebsd.org/cgi/query-pr.cgi?pr=105607 From tinderbox at freebsd.org Sun Sep 14 19:18:06 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Sep 14 19:19:07 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20080914191802.6F0E973039@freebsd-current.sentex.ca> TB --- 2008-09-14 18:05:13 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-14 18:05:13 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-09-14 18:05:13 - cleaning the object tree TB --- 2008-09-14 18:05:36 - cvsupping the source tree TB --- 2008-09-14 18:05:36 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-09-14 18:05:46 - building world (CFLAGS=-O -pipe) TB --- 2008-09-14 18:05:46 - cd /src TB --- 2008-09-14 18:05:46 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 14 18:05:47 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Sep 14 19:13:57 UTC 2008 TB --- 2008-09-14 19:13:57 - generating LINT kernel config TB --- 2008-09-14 19:13:57 - cd /src/sys/sun4v/conf TB --- 2008-09-14 19:13:57 - /usr/bin/make -B LINT TB --- 2008-09-14 19:13:57 - building LINT kernel (COPTFLAGS=) TB --- 2008-09-14 19:13:57 - cd /src TB --- 2008-09-14 19:13:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Sep 14 19:13:58 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/unit.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/pci/atiixp.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/pci/envy24.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/pci/envy24ht.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/pci/es137x.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/pci/spicds.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/sound/pci/hda/hdac.c /src/sys/dev/sound/pci/hda/hdac.c:642: error: 'HDA_CODEC_ALC663' undeclared here (not in a function) *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-14 19:18:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-14 19:18:02 - ERROR: failed to build lint kernel TB --- 2008-09-14 19:18:02 - tinderbox aborted TB --- 3121.24 user 390.16 system 4368.60 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Mon Sep 15 08:35:12 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Sep 15 08:35:24 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20080915083510.2BCB173039@freebsd-current.sentex.ca> TB --- 2008-09-15 07:18:25 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-15 07:18:25 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-09-15 07:18:25 - cleaning the object tree TB --- 2008-09-15 07:19:00 - cvsupping the source tree TB --- 2008-09-15 07:19:00 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-09-15 07:19:06 - building world (CFLAGS=-O -pipe) TB --- 2008-09-15 07:19:06 - cd /src TB --- 2008-09-15 07:19:06 - /usr/bin/make -B buildworld >>> World build started on Mon Sep 15 07:19:07 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Sep 15 08:28:30 UTC 2008 TB --- 2008-09-15 08:28:30 - generating LINT kernel config TB --- 2008-09-15 08:28:30 - cd /src/sys/sparc64/conf TB --- 2008-09-15 08:28:30 - /usr/bin/make -B LINT TB --- 2008-09-15 08:28:30 - building LINT kernel (COPTFLAGS=) TB --- 2008-09-15 08:28:30 - cd /src TB --- 2008-09-15 08:28:30 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Sep 15 08:28:31 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/pfil.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/radix.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/radix_mpath.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/raw_cb.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/raw_usrreq.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net/route.c /src/sys/net/route.c: In function 'rt_check': /src/sys/net/route.c:1719: error: invalid type argument of '->' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-15 08:35:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-15 08:35:09 - ERROR: failed to build lint kernel TB --- 2008-09-15 08:35:09 - tinderbox aborted TB --- 3189.74 user 404.35 system 4604.34 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From bugmaster at FreeBSD.org Mon Sep 15 15:18:56 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 15 15:21:02 2008 Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org Message-ID: <200809151518.m8FFItru019032@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/127051 sparc64 [hme] hme interfaces "pause" with the message "device o sparc/119244 sparc64 X11Forwarding to X11 server on sparc crashes Xorg o sparc/119240 sparc64 top has WCPU over 100% on UP system s sparc/119239 sparc64 gdb coredumps on sparc64 o sparc/119017 sparc64 7.0 Beta won't install on U60 o sparc/118932 sparc64 7.0-BETA4/sparc-64 kernel panic in rip_output o sparc/113556 sparc64 panic: trap: memory address not aligned; Rebooting... o sparc/109908 sparc64 apache22 mod_perl issue on sparc64 f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 s sparc/107087 sparc64 system is hinged during boot from CD f sparc/106251 sparc64 [libmalloc] malloc fails > for large allocations f sparc/105157 sparc64 No reply to ping on Sparc64 o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/95297 sparc64 vt100 term does not work in install o sparc/80890 sparc64 [panic] kmem_malloc(73728): kmem_map too small running o sparc/80410 sparc64 [netgraph] netgraph is causing crash with mpd on sparc o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC 18 problems total. From tinderbox at freebsd.org Sat Sep 20 22:55:46 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sat Sep 20 22:55:52 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20080920225537.8DCD573039@freebsd-current.sentex.ca> TB --- 2008-09-20 22:54:32 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-20 22:54:32 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-09-20 22:54:32 - cleaning the object tree TB --- 2008-09-20 22:55:03 - cvsupping the source tree TB --- 2008-09-20 22:55:03 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-09-20 22:55:09 - building world (CFLAGS=-O -pipe) TB --- 2008-09-20 22:55:09 - cd /src TB --- 2008-09-20 22:55:09 - /usr/bin/make -B buildworld >>> World build started on Sat Sep 20 22:55:10 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-20 22:55:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-20 22:55:37 - ERROR: failed to build world TB --- 2008-09-20 22:55:37 - tinderbox aborted TB --- 18.34 user 5.29 system 64.80 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Sat Sep 20 22:56:41 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sat Sep 20 22:56:48 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20080920225639.706DA73039@freebsd-current.sentex.ca> TB --- 2008-09-20 22:55:37 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-20 22:55:37 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-09-20 22:55:37 - cleaning the object tree TB --- 2008-09-20 22:56:06 - cvsupping the source tree TB --- 2008-09-20 22:56:06 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-09-20 22:56:12 - building world (CFLAGS=-O -pipe) TB --- 2008-09-20 22:56:12 - cd /src TB --- 2008-09-20 22:56:12 - /usr/bin/make -B buildworld >>> World build started on Sat Sep 20 22:56:14 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-20 22:56:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-20 22:56:39 - ERROR: failed to build world TB --- 2008-09-20 22:56:39 - tinderbox aborted TB --- 17.95 user 5.16 system 61.70 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Sun Sep 21 00:02:55 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Sep 21 00:03:06 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20080921000252.E30467303E@freebsd-current.sentex.ca> TB --- 2008-09-21 00:02:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-21 00:02:17 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-09-21 00:02:17 - cleaning the object tree TB --- 2008-09-21 00:02:18 - cvsupping the source tree TB --- 2008-09-21 00:02:18 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-09-21 00:02:23 - building world (CFLAGS=-O -pipe) TB --- 2008-09-21 00:02:23 - cd /src TB --- 2008-09-21 00:02:23 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 21 00:02:25 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-21 00:02:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-21 00:02:52 - ERROR: failed to build world TB --- 2008-09-21 00:02:52 - tinderbox aborted TB --- 17.27 user 2.73 system 35.52 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Sun Sep 21 00:03:06 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Sep 21 00:03:13 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20080921000301.79D7673039@freebsd-current.sentex.ca> TB --- 2008-09-21 00:02:30 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-21 00:02:30 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-09-21 00:02:30 - cleaning the object tree TB --- 2008-09-21 00:02:31 - cvsupping the source tree TB --- 2008-09-21 00:02:31 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-09-21 00:02:36 - building world (CFLAGS=-O -pipe) TB --- 2008-09-21 00:02:36 - cd /src TB --- 2008-09-21 00:02:36 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 21 00:02:37 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-21 00:03:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-21 00:03:01 - ERROR: failed to build world TB --- 2008-09-21 00:03:01 - tinderbox aborted TB --- 17.15 user 2.66 system 31.38 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Sun Sep 21 00:22:06 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Sep 21 00:22:10 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20080921002203.BE06A73039@freebsd-current.sentex.ca> TB --- 2008-09-21 00:21:33 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-21 00:21:33 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-09-21 00:21:33 - cleaning the object tree TB --- 2008-09-21 00:21:34 - cvsupping the source tree TB --- 2008-09-21 00:21:34 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-09-21 00:21:39 - building world (CFLAGS=-O -pipe) TB --- 2008-09-21 00:21:39 - cd /src TB --- 2008-09-21 00:21:39 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 21 00:21:40 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-21 00:22:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-21 00:22:03 - ERROR: failed to build world TB --- 2008-09-21 00:22:03 - tinderbox aborted TB --- 17.31 user 2.60 system 30.25 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Sun Sep 21 00:22:09 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Sep 21 00:22:27 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20080921002207.8F0BA7303E@freebsd-current.sentex.ca> TB --- 2008-09-21 00:21:37 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-21 00:21:37 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-09-21 00:21:37 - cleaning the object tree TB --- 2008-09-21 00:21:38 - cvsupping the source tree TB --- 2008-09-21 00:21:38 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-09-21 00:21:43 - building world (CFLAGS=-O -pipe) TB --- 2008-09-21 00:21:43 - cd /src TB --- 2008-09-21 00:21:43 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 21 00:21:44 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-21 00:22:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-21 00:22:07 - ERROR: failed to build world TB --- 2008-09-21 00:22:07 - tinderbox aborted TB --- 17.30 user 2.57 system 29.67 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Sun Sep 21 00:42:05 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Sep 21 00:42:07 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20080921004200.147FA73039@freebsd-current.sentex.ca> TB --- 2008-09-21 00:41:31 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-21 00:41:31 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-09-21 00:41:31 - cleaning the object tree TB --- 2008-09-21 00:41:32 - cvsupping the source tree TB --- 2008-09-21 00:41:32 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-09-21 00:41:37 - building world (CFLAGS=-O -pipe) TB --- 2008-09-21 00:41:37 - cd /src TB --- 2008-09-21 00:41:37 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 21 00:41:38 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-21 00:42:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-21 00:42:00 - ERROR: failed to build world TB --- 2008-09-21 00:42:00 - tinderbox aborted TB --- 17.31 user 2.59 system 28.38 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Sun Sep 21 00:42:07 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Sep 21 00:42:23 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20080921004204.2B2497303E@freebsd-current.sentex.ca> TB --- 2008-09-21 00:41:35 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-21 00:41:35 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-09-21 00:41:35 - cleaning the object tree TB --- 2008-09-21 00:41:36 - cvsupping the source tree TB --- 2008-09-21 00:41:36 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-09-21 00:41:41 - building world (CFLAGS=-O -pipe) TB --- 2008-09-21 00:41:41 - cd /src TB --- 2008-09-21 00:41:41 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 21 00:41:41 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-21 00:42:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-21 00:42:04 - ERROR: failed to build world TB --- 2008-09-21 00:42:04 - tinderbox aborted TB --- 17.28 user 2.61 system 28.98 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Mon Sep 22 03:04:18 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Sep 22 03:04:30 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20080922030414.CFA6373039@freebsd-current.sentex.ca> TB --- 2008-09-22 02:05:28 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-22 02:05:28 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-09-22 02:05:28 - cleaning the object tree TB --- 2008-09-22 02:05:57 - cvsupping the source tree TB --- 2008-09-22 02:05:57 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-09-22 02:06:05 - building world (CFLAGS=-O -pipe) TB --- 2008-09-22 02:06:05 - cd /src TB --- 2008-09-22 02:06:05 - /usr/bin/make -B buildworld >>> World build started on Mon Sep 22 02:06:07 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -I/src/sbin/ipf/ipresend/../../../contrib/ipfilter -I/src/sbin/ipf/ipresend/../../../contrib/ipfilter/tools -I/src/sbin/ipf/ipresend/../../../sys -I/src/sbin/ipf/ipresend/../../../sys/contrib/ipfilter -DSTATETOP -D__UIO_EXPOSE -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o /obj/sparc64/src/sbin/ipf/ipresend/../libipf/libipf.a -lkvm gzip -cn /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/ipresend.1 > ipresend.1.gz ===> sbin/ipfw (all) cc -O -pipe -fstack-protector -Wno-pointer-sign -c /src/sbin/ipfw/ipfw2.c /src/sbin/ipfw/ipfw2.c: In function 'table_handler': /src/sbin/ipfw/ipfw2.c:5877: error: 'a' undeclared (first use in this function) /src/sbin/ipfw/ipfw2.c:5877: error: (Each undeclared identifier is reported only once /src/sbin/ipfw/ipfw2.c:5877: error: for each function it appears in.) *** Error code 1 Stop in /src/sbin/ipfw. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-22 03:04:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-22 03:04:14 - ERROR: failed to build world TB --- 2008-09-22 03:04:14 - tinderbox aborted TB --- 2495.10 user 319.91 system 3525.98 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Mon Sep 22 03:05:30 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Sep 22 03:05:39 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20080922030528.0624973039@freebsd-current.sentex.ca> TB --- 2008-09-22 02:08:02 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-22 02:08:02 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-09-22 02:08:02 - cleaning the object tree TB --- 2008-09-22 02:08:33 - cvsupping the source tree TB --- 2008-09-22 02:08:33 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-09-22 02:08:40 - building world (CFLAGS=-O -pipe) TB --- 2008-09-22 02:08:40 - cd /src TB --- 2008-09-22 02:08:40 - /usr/bin/make -B buildworld >>> World build started on Mon Sep 22 02:08:41 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -I/src/sbin/ipf/ipresend/../../../contrib/ipfilter -I/src/sbin/ipf/ipresend/../../../contrib/ipfilter/tools -I/src/sbin/ipf/ipresend/../../../sys -I/src/sbin/ipf/ipresend/../../../sys/contrib/ipfilter -DSTATETOP -D__UIO_EXPOSE -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o /obj/sun4v/src/sbin/ipf/ipresend/../libipf/libipf.a -lkvm gzip -cn /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/ipresend.1 > ipresend.1.gz ===> sbin/ipfw (all) cc -O -pipe -fstack-protector -Wno-pointer-sign -c /src/sbin/ipfw/ipfw2.c /src/sbin/ipfw/ipfw2.c: In function 'table_handler': /src/sbin/ipfw/ipfw2.c:5877: error: 'a' undeclared (first use in this function) /src/sbin/ipfw/ipfw2.c:5877: error: (Each undeclared identifier is reported only once /src/sbin/ipfw/ipfw2.c:5877: error: for each function it appears in.) *** Error code 1 Stop in /src/sbin/ipfw. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-22 03:05:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-22 03:05:28 - ERROR: failed to build world TB --- 2008-09-22 03:05:28 - tinderbox aborted TB --- 2491.32 user 317.91 system 3445.89 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From bugmaster at FreeBSD.org Mon Sep 22 11:07:04 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 22 11:07:52 2008 Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org Message-ID: <200809221107.m8MB73m8015510@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/127051 sparc64 [hme] hme interfaces "pause" with the message "device o sparc/119244 sparc64 X11Forwarding to X11 server on sparc crashes Xorg o sparc/119240 sparc64 top has WCPU over 100% on UP system s sparc/119239 sparc64 gdb coredumps on sparc64 o sparc/119017 sparc64 7.0 Beta won't install on U60 o sparc/118932 sparc64 7.0-BETA4/sparc-64 kernel panic in rip_output o sparc/113556 sparc64 panic: trap: memory address not aligned; Rebooting... o sparc/109908 sparc64 apache22 mod_perl issue on sparc64 f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 s sparc/107087 sparc64 system is hinged during boot from CD f sparc/106251 sparc64 [libmalloc] malloc fails > for large allocations f sparc/105157 sparc64 No reply to ping on Sparc64 o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/95297 sparc64 vt100 term does not work in install o sparc/80890 sparc64 [panic] kmem_malloc(73728): kmem_map too small running o sparc/80410 sparc64 [netgraph] netgraph is causing crash with mpd on sparc o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC 18 problems total. From bugmaster at FreeBSD.org Mon Sep 29 11:06:58 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 29 11:08:49 2008 Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org Message-ID: <200809291106.m8TB6vdK040940@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/127051 sparc64 [hme] hme interfaces "pause" with the message "device o sparc/119244 sparc64 X11Forwarding to X11 server on sparc crashes Xorg o sparc/119240 sparc64 top has WCPU over 100% on UP system s sparc/119239 sparc64 gdb coredumps on sparc64 o sparc/119017 sparc64 7.0 Beta won't install on U60 o sparc/118932 sparc64 7.0-BETA4/sparc-64 kernel panic in rip_output o sparc/113556 sparc64 panic: trap: memory address not aligned; Rebooting... o sparc/109908 sparc64 apache22 mod_perl issue on sparc64 f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 s sparc/107087 sparc64 system is hinged during boot from CD f sparc/106251 sparc64 [libmalloc] malloc fails > for large allocations f sparc/105157 sparc64 No reply to ping on Sparc64 o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/95297 sparc64 vt100 term does not work in install o sparc/80890 sparc64 [panic] kmem_malloc(73728): kmem_map too small running o sparc/80410 sparc64 [netgraph] netgraph is causing crash with mpd on sparc o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC 18 problems total. From scaron at umich.edu Tue Sep 30 00:42:37 2008 From: scaron at umich.edu (Sean Thomas Caron) Date: Tue Sep 30 00:42:44 2008 Subject: Kernel panic in 7.0-RELEASE with fatm driver Message-ID: <20080929201947.86701vp3bs8vcatc@web.mail.umich.edu> Hi folks, I've been running FreeBSD 6.x on a number of Ultrasparc based systems using the Cranor NATM driver with a bunch of Fore PCA-200E cards. It generally worked but as the machines got hit with higher and higher network load I would get kernel panics at fairly random intervals on "sbdrop" and "sbflush". Sometimes I would get two per day, sometimes I wouldn't get any for two weeks. So after a while at this I decided to try 7.0-RELEASE out hoping whatever bug was causing these random kernel panics might have gotten fixed. Test system is Sun Fire v120, 550 MHz, 1 GB RAM, PCA-200e installed in PCI slot. I pruned a bunch of stuff from GENERIC and added the usual Cranor NATM stuff that I was using in 6.x. In particular - # ATM options NATM device atm device fatm device utopia Kernel does have multiprocessing enabled (as GENERIC did) even though it's a uniprocessor machine. I built the new kernel then reboot and it panics immediately after touching the ATM card - fatm0: mem 0x200000-0x3fffff at device 5.0 on pci2 panic: bus_dma_tag_create: parent DMA tag NULL cpuid = 0 Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. I'm hoping maybe someone has seen this before and has a patch laying around somewhere, or if nothing else, it might get passed along to the fatm maintainer eventually? If anyone wants to see any further information e.g. full kernel configuration file, I will be happy to pass along. I can also procure a backtrace if someone can tell me how to hardcode a dump path into the kernel; I can't find a procedure documented anywhere. Thanks! -Sean From marius at alchemy.franken.de Tue Sep 30 06:54:12 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Tue Sep 30 06:54:20 2008 Subject: Kernel panic in 7.0-RELEASE with fatm driver In-Reply-To: <20080929201947.86701vp3bs8vcatc@web.mail.umich.edu> References: <20080929201947.86701vp3bs8vcatc@web.mail.umich.edu> Message-ID: <20080930065410.GA87677@alchemy.franken.de> On Mon, Sep 29, 2008 at 08:19:47PM -0400, Sean Thomas Caron wrote: > Hi folks, > > I've been running FreeBSD 6.x on a number of Ultrasparc based systems > using the Cranor NATM driver with a bunch of Fore PCA-200E cards. It > generally worked but as the machines got hit with higher and higher > network load I would get kernel panics at fairly random intervals on > "sbdrop" and "sbflush". Sometimes I would get two per day, sometimes I > wouldn't get any for two weeks. > > So after a while at this I decided to try 7.0-RELEASE out hoping > whatever bug was causing these random kernel panics might have gotten > fixed. > > Test system is Sun Fire v120, 550 MHz, 1 GB RAM, PCA-200e installed in > PCI slot. > > I pruned a bunch of stuff from GENERIC and added the usual Cranor NATM > stuff that I was using in 6.x. In particular - > > # ATM > > options NATM > device atm > device fatm > device utopia > > Kernel does have multiprocessing enabled (as GENERIC did) even though > it's a uniprocessor machine. If you're compiling a custom kernel anyway you should leave out options SMP on a UP machine for performance reasons. > > I built the new kernel then reboot and it panics immediately after > touching the ATM card - > > fatm0: mem 0x200000-0x3fffff at device 5.0 on pci2 > panic: bus_dma_tag_create: parent DMA tag NULL > cpuid = 0 > Uptime: 1s > Automatic reboot in 15 seconds - press a key on the console to abort > --> Press a key on the console to reboot, > --> or switch off the system now. > > I'm hoping maybe someone has seen this before and has a patch laying > around somewhere, or if nothing else, it might get passed along to the > fatm maintainer eventually? Please give the attached patch a try. > > If anyone wants to see any further information e.g. full kernel > configuration file, I will be happy to pass along. I can also procure > a backtrace if someone can tell me how to hardcode a dump path into > the kernel; I can't find a procedure documented anywhere. > FYI, you can specifiy the path (defaulting to /var/crash) for the dump via "dumpdir" in /etc/rc.conf. Marius -------------- next part -------------- A non-text attachment was scrubbed... Name: fatm_bus_get_dma_tag.diff Type: text/x-diff Size: 531 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20080930/bee01b6b/fatm_bus_get_dma_tag.bin From scaron at umich.edu Tue Sep 30 16:22:29 2008 From: scaron at umich.edu (Sean Thomas Caron) Date: Tue Sep 30 16:22:36 2008 Subject: Kernel panic in 7.0-RELEASE with fatm driver Message-ID: <20080930122228.142223bgn8iye9ok@web.mail.umich.edu> Hi Marius, I applied the patch that you furnished and rebuilt the kernel, now the system is coming up just fine after probing the ATM card and the interface seems to take an IP and ifconfig up with no problems at all. I'm away from home using ILOM right now to interact with the server but I will actually try hooking it up to my switch and passing some packets through it tonight when I get home to be absolutely sure that it's working -- but this is looking very promising indeed. :) Thanks very much for your efforts! I really appreciate it. -Sean