From owner-freebsd-stable Mon Nov 11 8:17:36 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6116137B401 for ; Mon, 11 Nov 2002 08:17:31 -0800 (PST) Received: from obsidian.sentex.ca (obsidian.sentex.ca [64.7.128.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD8E843E3B for ; Mon, 11 Nov 2002 08:17:30 -0800 (PST) (envelope-from mike@sentex.net) Received: from simian.sentex.net (pyroxene.sentex.ca [199.212.134.18]) by obsidian.sentex.ca (8.12.6/8.12.6) with ESMTP id gABGHNUG099204; Mon, 11 Nov 2002 11:17:23 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <5.1.1.6.0.20021111111723.06e0f520@marble.sentex.ca> X-Sender: mdtpop@marble.sentex.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 11 Nov 2002 11:19:56 -0500 To: "Marc G. Fournier" , freebsd-stable@FreeBSD.ORG From: Mike Tancsa Subject: Re: Changes on Oct 28th break -STABLE kernel ... In-Reply-To: <20021110222143.D11716-100000@hub.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: By Sentex Communications (obsidian/20020517) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG There were another series of commits to the AMR driver this morning that might help you out. If you think its the AMR driver that is causing you grief, you might want to contact the committer. ---Mike ----------------- emoore 2002/11/11 05:19:11 PST Modified files: (Branch: RELENG_4) sys/dev/amr amr.c amr_cam.c amr_compat.h amr_disk.c amr_pci.c amr_tables.h amrio.h amrreg.h amrvar.h Log: amr.c, amr_cam.c, amrreg.h, amrvar.h: - added support for 12/16 byte cdb's, effecting CAM branch only ( non-disk support ) amrreg.h: - increased number of scatter gather elements from 16 to 26. amr_pci.c: - amr_pci_free(), incorrect bus tag meant for 'amr_mailbox_dmat' was being freed all: - copyright change requested by scottl ------------------------ At 10:46 PM 10/11/2002 -0400, Marc G. Fournier wrote: >Evening ... > > After spending today doing an incremental upgrade, starting from Oct12th >(my last stable), going to Oct12th, Oct19 and Oct27th (all sucessful), I >drop'd down to a 'daily incremental' ... Oct28th (the kernel I am now >running) appears to work great, but as soon as I go to Oct29th, I can't >get it to come up ... > > From cvsup, the changes between Oct28th (midnight) and Oct29th are: > >Connected to cvsup.FreeBSD.org >Updating collection src-all/cvs > Edit src/etc/MAKEDEV > Edit src/sys/conf/files > Edit src/sys/dev/amr/amr.c > Edit src/sys/dev/amr/amr_cam.c > Edit src/sys/dev/amr/amr_compat.h > Edit src/sys/dev/amr/amr_disk.c > Edit src/sys/dev/amr/amr_pci.c > Edit src/sys/dev/amr/amr_tables.h > Edit src/sys/dev/amr/amrio.h > Edit src/sys/dev/amr/amrreg.h > Edit src/sys/dev/amr/amrvar.h > Edit src/sys/modules/amr/Makefile > Edit src/sys/netinet/ip_fw.c >Finished successfully > > The AMR driver is what I'm running: > >venus# grep amr /var/run/dmesg.boot >amr0: flushing cache...done >amr0: mem 0xfc1f0000-0xfc1fffff irq 11 at device 2.0 on pci1 >amr0: Firmware E161, BIOS 3.13, >32MB RAM >amrd0: on amr0 >amrd0: 105000MB (215040000 sectors) RAID 5 (optimal) >Mounting root from ufs:/dev/amrd0s1a > > I've made not changes to my kernel config (or the hardware) between the >Oct28 and Oct29th kernels ... > > This server is a remote server, so 'hands on' debugging is difficult ... >the folks at Rackspace try and provide what they can, based on what is on >the console, which, in this case: > >"Your kernal failed when tring to boot the second processor." > > So, it seems that the 'hang @ "SMP: AP CPU #1 Launched!"' problem >started with code around the Oct28/Oct29th period ... > > According to /var/run/dmesg.boot, the following is what happens after >the "SMP: AP CPU #1 Launched!" message comes up on a good boot: > >SMP: AP CPU #1 Launched! >sa0 at sym0 bus 0 target 0 lun 0 >sa0: Removable Sequential Access SCSI-2 device >sa0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) >Mounting root from ufs:/dev/amrd0s1a > > and, on a good boot, the dmesg.boot looks like: > >Copyright (c) 1992-2002 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 4.7-STABLE #20: Sun Nov 10 18:55:29 CST 2002 > root@venus.hub.org:/usr/obj/usr/src/sys/kernel >Timecounter "i8254" frequency 1193182 Hz >CPU: Pentium III/Pentium III Xeon/Celeron (1262.67-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 > >Features=0x383fbff >real memory = 4227858432 (4128768K bytes) >avail memory = 4120436736 (4023864K bytes) >Programming 16 pins in IOAPIC #0 >IOAPIC #0 intpin 2 -> irq 0 >Programming 16 pins in IOAPIC #1 >FreeBSD/SMP: Multiprocessor motherboard > cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee00000 > cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee00000 > io0 (APIC): apic id: 4, version: 0x000f0011, at 0xfec00000 > io1 (APIC): apic id: 5, version: 0x000f0011, at 0xfec01000 >Preloaded elf kernel "kernel" at 0xc02a7000. >Pentium Pro MTRR support enabled >Using $PIR table, 10 entries at 0xc00f51c0 >npx0: on motherboard >npx0: INT 16 interface >pcib0: on motherboard >IOAPIC #1 intpin 6 -> irq 2 >IOAPIC #1 intpin 4 -> irq 5 >IOAPIC #1 intpin 5 -> irq 9 >pci0: on pcib0 >pci0: at 1.0 irq 2 >pci0: (vendor=0x8086, dev=0x1229) at 4.0 irq 5 >pci0: (vendor=0x8086, dev=0x1229) at 5.0 irq 9 >isab0: at device 15.0 on pci0 >isa0: on isab0 >pci0: at 15.1 >pci0: at 15.2 irq 10 >pcib1: on motherboard >IOAPIC #1 intpin 11 -> irq 11 >IOAPIC #1 intpin 7 -> irq 16 >IOAPIC #1 intpin 8 -> irq 17 >pci1: on pcib1 >amr0: mem 0xfc1f0000-0xfc1fffff irq 11 at device 2.0 on pci1 >amr0: Firmware E161, BIOS 3.13, >32MB RAM >sym0: <896> port 0xe400-0xe4ff mem >0xfebc8000-0xfebc9fff,0xfebe0000-0xfebe03ff irq 16 at device 3.0 on pci1 >sym0: Symbios NVRAM, ID 7, Fast-40, SE, parity checking >sym0: open drain IRQ line driver, using on-chip SRAM >sym0: using LOAD/STORE-based firmware. >sym0: handling phase mismatch from SCRIPTS. >sym1: <896> port 0xe800-0xe8ff mem >0xfebe8000-0xfebe9fff,0xfebf0000-0xfebf03ff irq 17 at device 3.1 on pci1 >sym1: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking >sym1: open drain IRQ line driver, using on-chip SRAM >sym1: using LOAD/STORE-based firmware. >sym1: handling phase mismatch from SCRIPTS. >orm0: