From owner-freebsd-scsi@FreeBSD.ORG Mon Jun 30 09:34:25 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0632537B401 for ; Mon, 30 Jun 2003 09:34:25 -0700 (PDT) Received: from astro.umn.edu (hal.astro.umn.edu [128.101.221.100]) by mx1.FreeBSD.org (Postfix) with SMTP id 4BC0C43FE9 for ; Mon, 30 Jun 2003 09:34:24 -0700 (PDT) (envelope-from carde@astro.umn.edu) Received: (qmail 7495 invoked by uid 10063); 30 Jun 2003 16:34:18 -0000 Date: Mon, 30 Jun 2003 11:34:18 -0500 From: kelley eicher To: Joshua Myles , freebsd-scsi@freebsd.org Message-ID: <20030630163418.GA6774@astro.umn.edu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Subject: Re: Adaptec RAID recommendations X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2003 16:34:25 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > I'm trying to decide on a 64-bit RAID card for a dual-Xeon server running > FreeBSD 4.8. The system is a Dell 2650, and the RAID controller will be > connected to a 14-disk U160 array with 73 GB Seagate disks. I intend to u= se > the disks in a RAID 5 configuration. >=20 i'm in this very same boat. currently i have some systems running with myle= x extremeraid 2000 cards but i have not been overly impressed with their st= ability in either linux or freebsd. > Anyway, as I understand it, Adaptec controllers are the most compatible w= ith > FreeBSD, so I'm looking at the 3210S and the 2200S. The 3210S can use more > cache RAM (256 MB) than the 2200S, but the 2200S may be (theoretically) > faster due to a slightly faster processor (100 MHz 80303 vs. 66 MHz). >=20 actually, both the 2200S and the 3210S have the same processor in them. the= 80303 processor is 100Mhz. the specs state 64bit/66Mhz 80303 processor but= that is only in reference to the bus rate no thte clock rate. the 80302 is= the 66Mhz version and is included on 21xxS boards and below. you would want the 2200S if you're planning on upgrading to U320 drives tho= ugh. this brings me to my question: is the adaptec 2200S supported under fr= eebsd 4.8? has the asr driver been updated for U320 support or no? > Does anyone have experience with either controller, or have some advice or > pointers for me? >=20 yeah, don't use the Mylex cards! ,) -kelley --=20 >> kelley j eicher << UNIX architect >> Univ. of MN Astronomy Dept. << ph: (612) 626-2067 or (612) 624-3589 >> fx: (612) 626-2029 << office: 385 physics >> carde at astro dot umn dot edu --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/AGaHF3O5KT+A1xQRAuXgAJ96oUublPw8nN9RfBAcQ3viHzl6zQCgmYnp DcjQwrK7RDLe1uhwJbRhy5I= =/GFt -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From owner-freebsd-scsi@FreeBSD.ORG Mon Jun 30 11:02:49 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D12937B401 for ; Mon, 30 Jun 2003 11:02:49 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EBD243FA3 for ; Mon, 30 Jun 2003 11:02:49 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h5UI2mUp084050 for ; Mon, 30 Jun 2003 11:02:48 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h5UI2m1q084044 for scsi@freebsd.org; Mon, 30 Jun 2003 11:02:48 -0700 (PDT) Date: Mon, 30 Jun 2003 11:02:48 -0700 (PDT) Message-Id: <200306301802.h5UI2m1q084044@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: scsi@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2003 18:02:49 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [1999/12/21] kern/15608 scsi acd0 / cd0 give inconsistent errors on em 1 problem total. From owner-freebsd-scsi@FreeBSD.ORG Mon Jun 30 12:34:29 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A831C37B404 for ; Mon, 30 Jun 2003 12:34:29 -0700 (PDT) Received: from maine.60north.net (maine.60north.net [198.143.201.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D39CF43FDD for ; Mon, 30 Jun 2003 12:34:26 -0700 (PDT) (envelope-from jackp@flag.60north.net) Received: from wms1.60north.net (mws1.60north.net [198.143.201.200]) by maine.60north.net (8.11.3/8.11.3) with SMTP id h5UJYOe73546 for ; Mon, 30 Jun 2003 15:34:24 -0400 (EDT) Received: FROM flag.60north.net BY wms1.60north.net ; Mon Jun 30 15:26:30 2003 -0700 Received: from admin.60north.net by flag.60north.net id aa08066; 30 Jun 2003 15:33 EDT Date: Mon, 30 Jun 2003 19:33:44 -0000 To: , , From: Jack Patton X-Mailer: TWIG 2.7.6 Message-ID: <200306301533.aa08066@flag.60north.net> Subject: Re: kern/53566: IBM Eserver (245 || 345) + ServeRaid 5i ips driver panic X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jackp@flag.60north.net List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2003 19:34:30 -0000 Okay, I hooked up a serial console and the CURRENT-20030627-JPSNAP. This is as far as the boot gets, along with a trace. Has there been any progress backporting this driver to 4.8 yet? Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT-20030627-JPSNAP #0: Fri Jun 27 00:23:43 GMT 2003 root@ushi.jp.freebsd.org:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0b5d000. Preloaded mfs_root "/boot/mfsroot" at 0xc0b5d278. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0b5d2bc. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 2793897976 Hz CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.90-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 526385152 (502 MB) avail memory = 499253248 (476 MB) Pentium Pro MTRR support enabled md0: Preloaded image 4423680 bytes at 0xc06d9528 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pcibios: BIOS version 2.10 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <32-bit timer at 3.579545MHz> port 0x488-0x48b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 pcib0: on acpi0 pci0: on pcib0 pcib0: slot 9 INTA is routed to irq 10 pcib0: slot 15 INTA is routed to irq 11 pci0: at device 9.0 (no driver attached) atapci0: port 0x700-0x70f,0x374- 0x377,0x17 0-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: simplex device, DMA on primary only ata1: at 0x170 irq 15 on atapci0 ohci0: mem 0xfebfe000-0xfebfefff irq 11 at devic e 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered isab0: at device 15.3 on pci0 isa0: on isab0 pcib1: on acpi0 pci2: on pcib1 pcib1: slot 8 INTA is routed to irq 3 bge0: mem 0xfbff0000- 0xfb ffffff irq 3 at device 8.0 on pci2 bge0: Ethernet address: 00:09:6b:a5:18:05 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX -FDX, auto pcib2: on acpi0 pci5: on pcib2 pcib2: slot 3 INTA is routed to irq 9 ips0: mem 0xf4000000-0xf7ffffff irq 9 at device 3.0 on p ci5 ips0: logical drives: 222 ipsd0: on ips0 ipsd0: Logical Drive (1824184MB) ipsd1: on ips0 ipsd1: Logical Drive (1824184MB) ipsd2: on ips0 ipsd2: Logical Drive (1824184MB) ipsd3: on ips0 ipsd3: Logical Drive (1824184MB) ipsd4: on ips0 ipsd4: Logical Drive (1824184MB) ipsd5: on ips0 ipsd5: Logical Drive (1824184MB) ipsd6: on ips0 ipsd6: Logical Drive (1824184MB) ipsd7: on ips0 ipsd7: Logical Drive (1824184MB) pcib3: on acpi0 pci7: on pcib3 pcib4: on acpi0 Memory modified after free 0xc4300c00(252) panic: Most recently used by devbuf Debugger("panic") Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db> tr Debugger(c05025bf,c05c5240,c0519512,c0b7fa7c,100) at Debugger+0x54 panic(c0519512,c0500e61,fc,c0c3ab74,c0c3ab60) at panic+0xcc mtrash_ctor(c4300c00,100,0,549,c4300c00) at mtrash_ctor+0x5d uma_zalloc_arg(c0c3ab60,0,1,c0b7fb44,e) at uma_zalloc_arg+0x194 malloc(98,c0b4d1a0,1,c0b7fb1c,c0b352c8) at malloc+0xd4 AcpiOsAllocate(98,c4308140,4,4,c4315cc0) at AcpiOsAllocate+0x21 AcpiUtInitializeBuffer(c431c250,98,c0b4876c,0,c0b7fb44) at AcpiUtInitializeBuffe r+0x38 AcpiRsCreatePciRoutingTable(c4315cc0,c431c250,8,c0b7fb6c,c4315cc0) at AcpiRsCrea tePciRoutingTable+0x3e AcpiRsGetPrtMethodData(c43045a0,c431c250,c433e380,c431c250,c0b7fbbc) at AcpiRsGe tPrtMethodData+0x41 AcpiGetIrqRoutingTable(c43045a0,c431c250,100,c0b7fbac,9) at AcpiGetIrqRoutingTab le+0x35 acpi_pcib_attach(c433e380,c431c250,9,c0b7fbe8,c42dc068) at acpi_pcib_attach+0x6e acpi_pcib_acpi_attach(c433e380,c18c4500,c433e380,c433e380,c18c4500) at acpi_pcib _acpi_attach+0x21d DEVICE_ATTACH(c433e380,c433e380,6,c18ab020,0) at DEVICE_ATTACH+0x48 device_probe_and_attach(c433e380,4,c0b7fc78,c0b390e4,c18c4500) at device_probe_a nd_attach+0x7d bus_generic_attach(c18c4500,c18ab020,64,c0b39100,c18c4500) at bus_generic_attach +0x28 acpi_probe_children(c18c4500,c0b3a8a0,c4318980,0,1a4) at acpi_probe_children+0x9 4 acpi_attach(c18c4500,c42dc098,c05288f8,c18c4500,c18c3580) at acpi_attach+0x6e3 DEVICE_ATTACH(c18c4500,c18c4500,c18c3580,c05288f0,1) at DEVICE_ATTACH+0x48 device_probe_and_attach(c18c4500,c18c3580,c0b7fd18,c049713c,c18c3580) at device_ probe_and_attach+0x7d bus_generic_attach(c18c3580,c42ad098,c0b7fd34,c0327798,c18c3580) at bus_generic_ attach+0x28 nexus_attach(c18c3580,c42ad098,c05288f8,c18c3580,c18c4080) at nexus_attach+0x1c DEVICE_ATTACH(c18c3580,c18c3580,0,c18b18d0,1) at DEVICE_ATTACH+0x48 device_probe_and_attach(c18c3580,c18b18d0,c0b7fd80,c04887b5,c18c4080) at device_ probe_and_attach+0x7d root_bus_configure(c18c4080,c051c640,0,c0b7fd98,c02e9a25) at root_bus_configure+ 0x28 configure(0,b7c000,b7cc00,b7c000,0) at configure+0x35 mi_startup() at mi_startup+0xb5 begin() at begin+0x2c db> -- Jack Patton From owner-freebsd-scsi@FreeBSD.ORG Mon Jun 30 18:28:45 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B968037B404; Mon, 30 Jun 2003 18:28:45 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7782B43FE0; Mon, 30 Jun 2003 18:28:44 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h611Sis19557; Mon, 30 Jun 2003 18:28:44 -0700 Received: from freebsd.org (hollin.btc.adaptec.com [10.100.253.56]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id SAA28251; Mon, 30 Jun 2003 18:28:43 -0700 (PDT) Message-ID: <3F00E33A.3080908@freebsd.org> Date: Mon, 30 Jun 2003 19:26:18 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jackp@flag.60north.net References: <200306301533.aa08066@flag.60north.net> In-Reply-To: <200306301533.aa08066@flag.60north.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-scsi@freebsd.org cc: freebsd-bugs@freebsd.org cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/53566: IBM Eserver (245 || 345) + ServeRaid 5i ips driver panic X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2003 01:28:46 -0000 Jack Patton wrote: > Okay, I hooked up a serial console and the CURRENT-20030627-JPSNAP. This is > as far as the boot gets, along with a trace. Has there been any progress > backporting this driver to 4.8 yet? > There isn't much sense in backporting this until the memory corruption problem is fixed. I'll see what I can do. Scott > > Copyright (c) 1992-2003 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 5.1-CURRENT-20030627-JPSNAP #0: Fri Jun 27 00:23:43 GMT 2003 > root@ushi.jp.freebsd.org:/usr/obj/usr/src/sys/GENERIC > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0b5d000. > Preloaded mfs_root "/boot/mfsroot" at 0xc0b5d278. > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0b5d2bc. > Timecounter "i8254" frequency 1193182 Hz > Timecounter "TSC" frequency 2793897976 Hz > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.90-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 > > Features=0xbfebfbff MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Hyperthreading: 2 logical CPUs > real memory = 526385152 (502 MB) > avail memory = 499253248 (476 MB) > Pentium Pro MTRR support enabled > md0: Preloaded image 4423680 bytes at 0xc06d9528 > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > pcibios: BIOS version 2.10 > acpi0: power button is handled as a fixed feature programming model. > Timecounter "ACPI-fast" frequency 3579545 Hz > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x488-0x48b on acpi0 > acpi_cpu0: on acpi0 > acpi_cpu1: on acpi0 > pcib0: on acpi0 > pci0: on pcib0 > pcib0: slot 9 INTA is routed to irq 10 > pcib0: slot 15 INTA is routed to irq 11 > pci0: at device 9.0 (no driver attached) > atapci0: port 0x700-0x70f,0x374- > 0x377,0x17 > 0-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 15.1 on pci0 > ata0: at 0x1f0 irq 14 on atapci0 > ata1: simplex device, DMA on primary only > ata1: at 0x170 irq 15 on atapci0 > ohci0: mem 0xfebfe000-0xfebfefff irq 11 at > devic > e 15.2 on pci0 > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 4 ports with 4 removable, self powered > isab0: at device 15.3 on pci0 > isa0: on isab0 > pcib1: on acpi0 > pci2: on pcib1 > pcib1: slot 8 INTA is routed to irq 3 > bge0: mem 0xfbff0000- > 0xfb > ffffff irq 3 at device 8.0 on pci2 > bge0: Ethernet address: 00:09:6b:a5:18:05 > miibus0: on bge0 > brgphy0: on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX > -FDX, auto > pcib2: on acpi0 > pci5: on pcib2 > pcib2: slot 3 INTA is routed to irq 9 > ips0: mem 0xf4000000-0xf7ffffff irq 9 at device 3.0 > on p > ci5 > ips0: logical drives: 222 > ipsd0: on ips0 > ipsd0: Logical Drive (1824184MB) > ipsd1: on ips0 > ipsd1: Logical Drive (1824184MB) > ipsd2: on ips0 > ipsd2: Logical Drive (1824184MB) > ipsd3: on ips0 > ipsd3: Logical Drive (1824184MB) > ipsd4: on ips0 > ipsd4: Logical Drive (1824184MB) > ipsd5: on ips0 > ipsd5: Logical Drive (1824184MB) > ipsd6: on ips0 > ipsd6: Logical Drive (1824184MB) > ipsd7: on ips0 > ipsd7: Logical Drive (1824184MB) > pcib3: on acpi0 > pci7: on pcib3 > pcib4: on acpi0 > Memory modified after free 0xc4300c00(252) > panic: Most recently used by devbuf > > Debugger("panic") > Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 > db> tr > Debugger(c05025bf,c05c5240,c0519512,c0b7fa7c,100) at Debugger+0x54 > panic(c0519512,c0500e61,fc,c0c3ab74,c0c3ab60) at panic+0xcc > mtrash_ctor(c4300c00,100,0,549,c4300c00) at mtrash_ctor+0x5d > uma_zalloc_arg(c0c3ab60,0,1,c0b7fb44,e) at uma_zalloc_arg+0x194 > malloc(98,c0b4d1a0,1,c0b7fb1c,c0b352c8) at malloc+0xd4 > AcpiOsAllocate(98,c4308140,4,4,c4315cc0) at AcpiOsAllocate+0x21 > AcpiUtInitializeBuffer(c431c250,98,c0b4876c,0,c0b7fb44) at > AcpiUtInitializeBuffe > r+0x38 > AcpiRsCreatePciRoutingTable(c4315cc0,c431c250,8,c0b7fb6c,c4315cc0) at > AcpiRsCrea > tePciRoutingTable+0x3e > AcpiRsGetPrtMethodData(c43045a0,c431c250,c433e380,c431c250,c0b7fbbc) at > AcpiRsGe > tPrtMethodData+0x41 > AcpiGetIrqRoutingTable(c43045a0,c431c250,100,c0b7fbac,9) at > AcpiGetIrqRoutingTab > le+0x35 > acpi_pcib_attach(c433e380,c431c250,9,c0b7fbe8,c42dc068) at > acpi_pcib_attach+0x6e > > acpi_pcib_acpi_attach(c433e380,c18c4500,c433e380,c433e380,c18c4500) at > acpi_pcib > _acpi_attach+0x21d > DEVICE_ATTACH(c433e380,c433e380,6,c18ab020,0) at DEVICE_ATTACH+0x48 > device_probe_and_attach(c433e380,4,c0b7fc78,c0b390e4,c18c4500) at > device_probe_a > nd_attach+0x7d > bus_generic_attach(c18c4500,c18ab020,64,c0b39100,c18c4500) at > bus_generic_attach > +0x28 > acpi_probe_children(c18c4500,c0b3a8a0,c4318980,0,1a4) at > acpi_probe_children+0x9 > 4 > acpi_attach(c18c4500,c42dc098,c05288f8,c18c4500,c18c3580) at acpi_attach+0x6e3 > DEVICE_ATTACH(c18c4500,c18c4500,c18c3580,c05288f0,1) at DEVICE_ATTACH+0x48 > device_probe_and_attach(c18c4500,c18c3580,c0b7fd18,c049713c,c18c3580) at > device_ > probe_and_attach+0x7d > bus_generic_attach(c18c3580,c42ad098,c0b7fd34,c0327798,c18c3580) at > bus_generic_ > attach+0x28 > nexus_attach(c18c3580,c42ad098,c05288f8,c18c3580,c18c4080) at > nexus_attach+0x1c > DEVICE_ATTACH(c18c3580,c18c3580,0,c18b18d0,1) at DEVICE_ATTACH+0x48 > device_probe_and_attach(c18c3580,c18b18d0,c0b7fd80,c04887b5,c18c4080) at > device_ > probe_and_attach+0x7d > root_bus_configure(c18c4080,c051c640,0,c0b7fd98,c02e9a25) at > root_bus_configure+ > 0x28 > configure(0,b7c000,b7cc00,b7c000,0) at configure+0x35 > mi_startup() at mi_startup+0xb5 > begin() at begin+0x2c > db> From owner-freebsd-scsi@FreeBSD.ORG Tue Jul 1 01:01:54 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5653937B404 for ; Tue, 1 Jul 2003 01:01:51 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 6C00344005 for ; Tue, 1 Jul 2003 01:01:50 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 86219 invoked by uid 1000); 1 Jul 2003 08:01:53 -0000 Date: Tue, 1 Jul 2003 01:01:53 -0700 (PDT) From: Nate Lawson To: Jack Patton In-Reply-To: <200306301533.aa08066@flag.60north.net> Message-ID: <20030701010014.Q86209@root.org> References: <200306301533.aa08066@flag.60north.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-scsi@freebsd.org cc: freebsd-bugs@freebsd.org cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/53566: IBM Eserver (245 || 345) + ServeRaid 5i ips driver panic X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2003 08:01:54 -0000 On Mon, 30 Jun 2003, Jack Patton wrote: > Okay, I hooked up a serial console and the CURRENT-20030627-JPSNAP. This is > as far as the boot gets, along with a trace. Has there been any progress > backporting this driver to 4.8 yet? > > FreeBSD 5.1-CURRENT-20030627-JPSNAP #0: Fri Jun 27 00:23:43 GMT 2003 > root@ushi.jp.freebsd.org:/usr/obj/usr/src/sys/GENERIC > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0b5d000. > Preloaded mfs_root "/boot/mfsroot" at 0xc0b5d278. > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0b5d2bc. Disable acpi and try again. Update your BIOS to hopefully get new ACPI code. There's some problem here with unitialized memory. It may be elsewhere though and ACPI is just stumbling onto it. -Nate From owner-freebsd-scsi@FreeBSD.ORG Tue Jul 1 07:30:40 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72FDA37B401 for ; Tue, 1 Jul 2003 07:30:40 -0700 (PDT) Received: from astro.umn.edu (hal.astro.umn.edu [128.101.221.100]) by mx1.FreeBSD.org (Postfix) with SMTP id 5DF4243FE9 for ; Tue, 1 Jul 2003 07:30:39 -0700 (PDT) (envelope-from carde@astro.umn.edu) Received: (qmail 30669 invoked by uid 10063); 1 Jul 2003 14:30:39 -0000 Date: Tue, 1 Jul 2003 09:30:38 -0500 From: kelley eicher To: Scott Long Message-ID: <20030701143038.GA30350@astro.umn.edu> References: <3EE59CF9.1010809@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: <3EE59CF9.1010809@freebsd.org> User-Agent: Mutt/1.4.1i cc: freebsd-scsi@freebsd.org Subject: Re: 64-bit raid controller recommendation X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2003 14:30:40 -0000 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable scott- > It's hard to tell from the asr driver where the 32-bit limitation > comes from and/or if there is a way to fix it. To directly answer > your question, the Adaptec aac cards and driver support 64-bit > addressing with no bouncing. This includes the 5400, 2120, and 2200 > cards. >=20 so is the 2200S officially supported under freebsd 4.x? or is that just 5.x? -kelley --=20 >> kelley j eicher << UNIX architect >> Univ. of MN Astronomy Dept. << ph: (612) 626-2067 or (612) 624-3589 >> fx: (612) 626-2029 << office: 385 physics >> carde at astro dot umn dot edu --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/AZsNF3O5KT+A1xQRAhlSAJ9o2zgNdvMNx65s1FVxGAmd8i9GUwCdH0/r 1Yg7mtGO1Wh3qT4lEl5/zFQ= =nnas -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt-- From owner-freebsd-scsi@FreeBSD.ORG Tue Jul 1 12:00:36 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46A4837B40A for ; Tue, 1 Jul 2003 12:00:36 -0700 (PDT) Received: from maine.60north.net (maine.60north.net [198.143.201.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EA7E44035 for ; Tue, 1 Jul 2003 12:00:33 -0700 (PDT) (envelope-from jackp@flag.60north.net) Received: from wms1.60north.net (mws1.60north.net [198.143.201.200]) by maine.60north.net (8.11.3/8.11.3) with SMTP id h61J0Ne80869 for ; Tue, 1 Jul 2003 15:00:23 -0400 (EDT) Received: FROM flag.60north.net BY wms1.60north.net ; Tue Jul 01 14:52:34 2003 -0700 Received: from admin.60north.net by flag.60north.net id aa18828; 1 Jul 2003 14:59 EDT Date: Tue, 1 Jul 2003 18:59:05 -0000 To: Nate Lawson , Jack Patton From: Jack Patton X-Mailer: TWIG 2.7.6 In-Reply-To: <20030701010014.Q86209@root.org> Message-ID: <200307011459.aa18828@flag.60north.net> cc: freebsd-scsi@freebsd.org cc: freebsd-bugs@freebsd.org cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/53566: IBM Eserver (245 || 345) + ServeRaid 5i ips driver panic X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jackp@flag.60north.net List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2003 19:00:38 -0000 Nate Lawson said: > On Mon, 30 Jun 2003, Jack Patton wrote: > > Okay, I hooked up a serial console and the CURRENT-20030627-JPSNAP. This is > > as far as the boot gets, along with a trace. Has there been any progress > > backporting this driver to 4.8 yet? > > > > FreeBSD 5.1-CURRENT-20030627-JPSNAP #0: Fri Jun 27 00:23:43 GMT 2003 > > root@ushi.jp.freebsd.org:/usr/obj/usr/src/sys/GENERIC > > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0b5d000. > > Preloaded mfs_root "/boot/mfsroot" at 0xc0b5d278. > > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0b5d2bc. > > Disable acpi and try again. Update your BIOS to hopefully get new ACPI > code. There's some problem here with unitialized memory. It may be > elsewhere though and ACPI is just stumbling onto it. > > -Nate > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > Here's the result of booting with hint.acpi.0.disabled=1. We just got this server recently. The server BIOS is at the latest version. I'm downloading a BIOS/Firmware for the ServeRaid card itself now and will test it with that applied. Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT-20030627-JPSNAP #0: Fri Jun 27 00:23:43 GMT 2003 root@ushi.jp.freebsd.org:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0b13000. Preloaded mfs_root "/boot/mfsroot" at 0xc0b13278. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 2793899260 Hz CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.90-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 526385152 (502 MB) avail memory = 499556352 (476 MB) Pentium Pro MTRR support enabled md0: Preloaded image 4423680 bytes at 0xc06d9528 npx0: on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 pcib0: at pcibus 0 on motherboard pci0: on pcib0 pci0: at device 9.0 (no driver attached) atapci0: port 0x700-0x70f,0x374- 0x377,0x17 0-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: simplex device, DMA on primary only ata1: at 0x170 irq 15 on atapci0 ohci0: mem 0xfebfe000-0xfebfefff irq 11 at devic e 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered isab0: at device 15.3 on pci0 isa0: on isab0 pcib1: at pcibus 1 on motherboard pci1: on pcib1 pcib2: at pcibus 2 on motherbo ard pci2: on pcib2 bge0: mem 0xfbff0000- 0xfb ffffff irq 3 at device 8.0 on pci2 bge0: Ethernet address: 00:09:6b:a5:18:05 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX -FDX, auto pcib5: at pcibus 5 on motherbo ard pci5: on pcib5 ips0: mem 0xf4000000-0xf7ffffff irq 9 at device 3.0 on p ci5 ips0: logical drives: 222 ipsd0: on ips0 ipsd0: Logical Drive (1824184MB) ipsd1: on ips0 ipsd1: Logical Drive (1824184MB) ipsd2: on ips0 ipsd2: Logical Drive (1824184MB) ipsd3: on ips0 ipsd3: Logical Drive (1824184MB) ipsd4: on ips0 ipsd4: Logical Drive (1824184MB) ipsd5: on ips0 ipsd5: Logical Drive (1824184MB) ipsd6: on ips0 ipsd6: Logical Drive (1824184MB) ipsd7: on ips0 ipsd7: Logical Drive (1824184MB) pcib7: at pcibus 7 on motherbo ard pci7: on pcib7 pcib9: at pcibus 9 on motherbo ard pci9: on pcib9 Memory modified after free 0xc18b5700(252) panic: Most recently used by devbuf Debugger("panic") Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db> tr Debugger(c05025bf,c05c5240,c0519512,c0b35ca4,100) at Debugger+0x54 panic(c0519512,c0500e61,fc,c0c3ab74,c0c3ab60) at panic+0xcc mtrash_ctor(c18b5700,100,0,549,c18b5700) at mtrash_ctor+0x5d uma_zalloc_arg(c0c3ab60,0,101,c0327740,c0599ca8) at uma_zalloc_arg+0x194 malloc(a8,c0556ac0,101,c05226b0,c0b35d6c) at malloc+0xd4 device_get_children(c4321380,c0b35d58,c0b35d5c,c0325d82,c18bf700) at device_get_ children+0x47 isa_probe_children(c4321380,c051c640,0,c0b35d98,c02e9a25) at isa_probe_children+ 0x2d configure(0,b32000,b32c00,b32000,0) at configure+0x4b mi_startup() at mi_startup+0xb5 begin() at begin+0x2c db> -- Jack Patton From owner-freebsd-scsi@FreeBSD.ORG Tue Jul 1 12:51:16 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBB3637B407 for ; Tue, 1 Jul 2003 12:51:16 -0700 (PDT) Received: from maine.60north.net (maine.60north.net [198.143.201.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C8EE43FE9 for ; Tue, 1 Jul 2003 12:51:14 -0700 (PDT) (envelope-from jackp@flag.60north.net) Received: from wms1.60north.net (mws1.60north.net [198.143.201.200]) by maine.60north.net (8.11.3/8.11.3) with SMTP id h61Jp3e81194 for ; Tue, 1 Jul 2003 15:51:03 -0400 (EDT) Received: FROM flag.60north.net BY wms1.60north.net ; Tue Jul 01 15:43:16 2003 -0700 Received: from admin.60north.net by flag.60north.net id aa10636; 1 Jul 2003 15:47 EDT Date: Tue, 1 Jul 2003 19:47:09 -0000 To: Nate Lawson , Jack Patton From: Jack Patton X-Mailer: TWIG 2.7.6 In-Reply-To: <20030701010014.Q86209@root.org> Message-ID: <200307011547.aa10636@flag.60north.net> cc: freebsd-scsi@freebsd.org cc: freebsd-bugs@freebsd.org cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/53566: IBM Eserver (245 || 345) + ServeRaid 5i ips driver panic X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jackp@flag.60north.net List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2003 19:51:17 -0000 Nate Lawson said: > On Mon, 30 Jun 2003, Jack Patton wrote: > > Okay, I hooked up a serial console and the CURRENT-20030627-JPSNAP. This is > > as far as the boot gets, along with a trace. Has there been any progress > > backporting this driver to 4.8 yet? > > > > FreeBSD 5.1-CURRENT-20030627-JPSNAP #0: Fri Jun 27 00:23:43 GMT 2003 > > root@ushi.jp.freebsd.org:/usr/obj/usr/src/sys/GENERIC > > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0b5d000. > > Preloaded mfs_root "/boot/mfsroot" at 0xc0b5d278. > > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0b5d2bc. > > Disable acpi and try again. Update your BIOS to hopefully get new ACPI > code. There's some problem here with unitialized memory. It may be > elsewhere though and ACPI is just stumbling onto it. > > -Nate > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > Here's the result of booting with hint.acpi.0.disabled=1. We just got this server recently. The server BIOS is at the latest version. I'm downloading a BIOS/Firmware for the ServeRaid card itself now and will test it with that applied. Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT-20030627-JPSNAP #0: Fri Jun 27 00:23:43 GMT 2003 root@ushi.jp.freebsd.org:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0b13000. Preloaded mfs_root "/boot/mfsroot" at 0xc0b13278. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 2793899260 Hz CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.90-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 526385152 (502 MB) avail memory = 499556352 (476 MB) Pentium Pro MTRR support enabled md0: Preloaded image 4423680 bytes at 0xc06d9528 npx0: on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 pcib0: at pcibus 0 on motherboard pci0: on pcib0 pci0: at device 9.0 (no driver attached) atapci0: port 0x700-0x70f,0x374- 0x377,0x17 0-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: simplex device, DMA on primary only ata1: at 0x170 irq 15 on atapci0 ohci0: mem 0xfebfe000-0xfebfefff irq 11 at devic e 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered isab0: at device 15.3 on pci0 isa0: on isab0 pcib1: at pcibus 1 on motherboard pci1: on pcib1 pcib2: at pcibus 2 on motherbo ard pci2: on pcib2 bge0: mem 0xfbff0000- 0xfb ffffff irq 3 at device 8.0 on pci2 bge0: Ethernet address: 00:09:6b:a5:18:05 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX -FDX, auto pcib5: at pcibus 5 on motherbo ard pci5: on pcib5 ips0: mem 0xf4000000-0xf7ffffff irq 9 at device 3.0 on p ci5 ips0: logical drives: 222 ipsd0: on ips0 ipsd0: Logical Drive (1824184MB) ipsd1: on ips0 ipsd1: Logical Drive (1824184MB) ipsd2: on ips0 ipsd2: Logical Drive (1824184MB) ipsd3: on ips0 ipsd3: Logical Drive (1824184MB) ipsd4: on ips0 ipsd4: Logical Drive (1824184MB) ipsd5: on ips0 ipsd5: Logical Drive (1824184MB) ipsd6: on ips0 ipsd6: Logical Drive (1824184MB) ipsd7: on ips0 ipsd7: Logical Drive (1824184MB) pcib7: at pcibus 7 on motherbo ard pci7: on pcib7 pcib9: at pcibus 9 on motherbo ard pci9: on pcib9 Memory modified after free 0xc18b5700(252) panic: Most recently used by devbuf Debugger("panic") Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db> tr Debugger(c05025bf,c05c5240,c0519512,c0b35ca4,100) at Debugger+0x54 panic(c0519512,c0500e61,fc,c0c3ab74,c0c3ab60) at panic+0xcc mtrash_ctor(c18b5700,100,0,549,c18b5700) at mtrash_ctor+0x5d uma_zalloc_arg(c0c3ab60,0,101,c0327740,c0599ca8) at uma_zalloc_arg+0x194 malloc(a8,c0556ac0,101,c05226b0,c0b35d6c) at malloc+0xd4 device_get_children(c4321380,c0b35d58,c0b35d5c,c0325d82,c18bf700) at device_get_ children+0x47 isa_probe_children(c4321380,c051c640,0,c0b35d98,c02e9a25) at isa_probe_children+ 0x2d configure(0,b32000,b32c00,b32000,0) at configure+0x4b mi_startup() at mi_startup+0xb5 begin() at begin+0x2c db> -- Jack Patton From owner-freebsd-scsi@FreeBSD.ORG Tue Jul 1 13:11:35 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0D3537B405 for ; Tue, 1 Jul 2003 13:11:35 -0700 (PDT) Received: from maine.60north.net (maine.60north.net [198.143.201.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B84E644035 for ; Tue, 1 Jul 2003 13:11:33 -0700 (PDT) (envelope-from jackp@flag.60north.net) Received: from wms1.60north.net (mws1.60north.net [198.143.201.200]) by maine.60north.net (8.11.3/8.11.3) with SMTP id h61KBLe81322 for ; Tue, 1 Jul 2003 16:11:21 -0400 (EDT) Received: FROM flag.60north.net BY wms1.60north.net ; Tue Jul 01 16:03:33 2003 -0700 Received: from admin.60north.net by flag.60north.net id aa18169; 1 Jul 2003 16:07 EDT Date: Tue, 1 Jul 2003 20:06:50 -0000 To: Nate Lawson , Jack Patton From: Jack Patton X-Mailer: TWIG 2.7.6 In-Reply-To: <20030701010014.Q86209@root.org> Message-ID: <200307011607.aa18169@flag.60north.net> cc: freebsd-scsi@freebsd.org cc: freebsd-bugs@freebsd.org cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/53566: IBM Eserver (245 || 345) + ServeRaid 5i ips driver panic X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jackp@flag.60north.net List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2003 20:11:36 -0000 Nate Lawson said: > On Mon, 30 Jun 2003, Jack Patton wrote: > > Okay, I hooked up a serial console and the CURRENT-20030627-JPSNAP. This is > > as far as the boot gets, along with a trace. Has there been any progress > > backporting this driver to 4.8 yet? > > > > FreeBSD 5.1-CURRENT-20030627-JPSNAP #0: Fri Jun 27 00:23:43 GMT 2003 > > root@ushi.jp.freebsd.org:/usr/obj/usr/src/sys/GENERIC > > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0b5d000. > > Preloaded mfs_root "/boot/mfsroot" at 0xc0b5d278. > > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0b5d2bc. > > Disable acpi and try again. Update your BIOS to hopefully get new ACPI > code. There's some problem here with unitialized memory. It may be > elsewhere though and ACPI is just stumbling onto it. > > -Nate > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > Here's the result of booting with hint.acpi.0.disabled=1. We just got this server recently. The server BIOS is at the latest version. I'm downloading a BIOS/Firmware for the ServeRaid card itself now and will test it with that applied. Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT-20030627-JPSNAP #0: Fri Jun 27 00:23:43 GMT 2003 root@ushi.jp.freebsd.org:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0b13000. Preloaded mfs_root "/boot/mfsroot" at 0xc0b13278. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 2793899260 Hz CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.90-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 526385152 (502 MB) avail memory = 499556352 (476 MB) Pentium Pro MTRR support enabled md0: Preloaded image 4423680 bytes at 0xc06d9528 npx0: on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 pcib0: at pcibus 0 on motherboard pci0: on pcib0 pci0: at device 9.0 (no driver attached) atapci0: port 0x700-0x70f,0x374- 0x377,0x17 0-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: simplex device, DMA on primary only ata1: at 0x170 irq 15 on atapci0 ohci0: mem 0xfebfe000-0xfebfefff irq 11 at devic e 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered isab0: at device 15.3 on pci0 isa0: on isab0 pcib1: at pcibus 1 on motherboard pci1: on pcib1 pcib2: at pcibus 2 on motherbo ard pci2: on pcib2 bge0: mem 0xfbff0000- 0xfb ffffff irq 3 at device 8.0 on pci2 bge0: Ethernet address: 00:09:6b:a5:18:05 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX -FDX, auto pcib5: at pcibus 5 on motherbo ard pci5: on pcib5 ips0: mem 0xf4000000-0xf7ffffff irq 9 at device 3.0 on p ci5 ips0: logical drives: 222 ipsd0: on ips0 ipsd0: Logical Drive (1824184MB) ipsd1: on ips0 ipsd1: Logical Drive (1824184MB) ipsd2: on ips0 ipsd2: Logical Drive (1824184MB) ipsd3: on ips0 ipsd3: Logical Drive (1824184MB) ipsd4: on ips0 ipsd4: Logical Drive (1824184MB) ipsd5: on ips0 ipsd5: Logical Drive (1824184MB) ipsd6: on ips0 ipsd6: Logical Drive (1824184MB) ipsd7: on ips0 ipsd7: Logical Drive (1824184MB) pcib7: at pcibus 7 on motherbo ard pci7: on pcib7 pcib9: at pcibus 9 on motherbo ard pci9: on pcib9 Memory modified after free 0xc18b5700(252) panic: Most recently used by devbuf Debugger("panic") Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db> tr Debugger(c05025bf,c05c5240,c0519512,c0b35ca4,100) at Debugger+0x54 panic(c0519512,c0500e61,fc,c0c3ab74,c0c3ab60) at panic+0xcc mtrash_ctor(c18b5700,100,0,549,c18b5700) at mtrash_ctor+0x5d uma_zalloc_arg(c0c3ab60,0,101,c0327740,c0599ca8) at uma_zalloc_arg+0x194 malloc(a8,c0556ac0,101,c05226b0,c0b35d6c) at malloc+0xd4 device_get_children(c4321380,c0b35d58,c0b35d5c,c0325d82,c18bf700) at device_get_ children+0x47 isa_probe_children(c4321380,c051c640,0,c0b35d98,c02e9a25) at isa_probe_children+ 0x2d configure(0,b32000,b32c00,b32000,0) at configure+0x4b mi_startup() at mi_startup+0xb5 begin() at begin+0x2c db> -- Jack Patton From owner-freebsd-scsi@FreeBSD.ORG Tue Jul 1 14:01:35 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF33C37B401 for ; Tue, 1 Jul 2003 14:01:35 -0700 (PDT) Received: from noao.edu (noao.edu [140.252.1.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 241C344013 for ; Tue, 1 Jul 2003 14:01:33 -0700 (PDT) (envelope-from grandi@noao.edu) Received: from regulus.tuc.noao.edu (account grandi [140.252.1.146] verified) by noao.edu (CommuniGate Pro SMTP 4.1b8) with ESMTP-TLS id 7945090 for freebsd-scsi@freebsd.org; Tue, 01 Jul 2003 14:01:32 -0700 Date: Tue, 1 Jul 2003 14:01:32 -0700 (MST) From: Steve Grandi X-X-Sender: grandi@regulus.tuc.noao.edu To: freebsd-scsi@freebsd.org Message-ID: <20030701135436.R69773@regulus.tuc.noao.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: AIC 7902 driver in Stable: problems with a B channel drive. X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2003 21:01:36 -0000 The recent changes to the AIC7902 Stable driver make it boot cleanly, once more, on my Supermicro SuperServer 6013P-8 system with a X5DPR-8G2 motherboard which features an embedded, dual-channel AIC7902 controller. What still doesn't work: I attach a JetStor III disk array (from AC&NC) to the B channel of the embedded controller and the Stable boot goes into a nice loop of "Dump Card State". See below for a listing of a couple of cycles of this loop from a verbose dump. The AIC7902 BIOS correctly sees the disk array as target 3 on the B channel of the controller. ----------------------------------------------------------------------------- Waiting 5 seconds for SCSI devices to settle (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. ahd0: Downloading Sequencer Program... 710 instructions downloaded ahd0: Features 0x101, Bugs 0x8fffff, Flags 0x43f1 (noperiph:ahd0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. ahd1: Downloading Sequencer Program... 710 instructions downloaded ahd1: Features 0x101, Bugs 0x8fffff, Flags 0x43f0 (noperiph:ahd1:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. (ahd0:A:1:0): Sending PPR bus_width 1, period 8, offset 7f, ppr_options bf (ahd0:A:1:0): Received PPR width 1, period 8, offset 3f,options bf Filtered to width 1, period 8, offset 3f, options bf ahd0: target 1 using 16bit transfers ahd0: target 1 synchronous with period = 0x8, offset = 0x3f(RDSTRM|DT|IU|QAS) (ahd0:A:0:0): Sending PPR bus_width 1, period 8, offset 7f, ppr_options bf (ahd0:A:0:0): Received PPR width 1, period 8, offset 3f,options bf Filtered to width 1, period 8, offset 3f, options bf ahd0: target 0 using 16bit transfers ahd0: target 0 synchronous with period = 0x8, offset = 0x3f(RDSTRM|DT|IU|QAS) (ahd1:A:3:0): Sending PPR bus_width 1, period 9, offset 7f, ppr_options 3f (ahd1:A:3:0): Received PPR width 1, period 9, offset 1f,options 3f Filtered to width 1, period 9, offset 1f, options 3f ahd1: target 3 using 16bit transfers ahd1: target 3 synchronous with period = 0x9, offset = 0x1f(RDSTRM|DT|IU|QAS) (probe33:ahd1:0:3:0): Unexpected busfree in Command phase, 1 SCBs aborted, PRGMCNT == 0xfe >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahd1: Dumping Card State at program address 0xfc Mode 0x11 Card was paused HS_MAILBOX[0x0] INTCTL[0x80]:(SWTMINTMASK) SEQINTSTAT[0x0] SAVED_MODE[0x11] DFFSTAT[0x11]:(CURRFIFO_1|FIFO0FREE) SCSISIGI[0x0]:(P_DATAOUT) SCSIPHASE[0x0] SCSIBUS[0x0] LASTPHASE[0x80]:(P_COMMAND) SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x10]:(FASTMODE) SEQINTCTL[0x0] SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] SSTAT0[0x0] SSTAT1[0x8]:(BUSFREE) SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0x0] SIMODE1[0xac]:(ENSCSIPERR|ENBUSFREE|ENSCSIRST|ENSELTIMO) LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x0] SCB Count = 16 CMDS_PENDING = 1 LASTSCB 0xc CURRSCB 0xc NEXTSCB 0x0 qinstart = 21 qinfifonext = 21 QINFIFO: WAITING_TID_QUEUES: Pending list: Total 0 Kernel Free SCB list: 12 1 2 3 4 5 6 7 8 9 10 11 13 14 15 0 Sequencer Complete DMA-inprog list: Sequencer Complete list: Sequencer DMA-Up and Complete list: ahd1: FIFO0 Free, LONGJMP == 0x80ff, SCB 0x0 SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x0] ahd1: FIFO1 Active, LONGJMP == 0x8072, SCB 0xc SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x88]:(HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0xc]:(DLZERO|SHVALID) SHADDR = 0x00, SHCNT = 0x6 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) LQIN: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 ahd1: LQISTATE = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x42 ahd1: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x0 SIMODE0[0xc]:(ENOVERRUN|ENIOERR) CCSCBCTL[0x4]:(CCSCBDIR) ahd1: REG0 == 0x7cba, SINDEX = 0x111, DINDEX = 0xe1 ahd1: SCBPTR == 0xc, SCB_NEXT == 0xff40, SCB_NEXT2 == 0xff9a CDB 0 0 0 0 0 0 STACK: 0x0 0x0 0x0 0x0 0x0 0x0 0xa7 0xf1 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> (ahd1:A:3:1): Sending PPR bus_width 1, period 9, offset 1f, ppr_options 3f (ahd1:A:3:1): Received PPR width 1, period 9, offset 1f,options 3f Filtered to width 1, period 9, offset 1f, options 3f (probe0:ahd1:0:3:1): Unexpected busfree in Command phase, 1 SCBs aborted, PRGMCNT == 0x97 >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahd1: Dumping Card State at program address 0x95 Mode 0x0 Card was paused HS_MAILBOX[0x0] INTCTL[0x80]:(SWTMINTMASK) SEQINTSTAT[0x0] SAVED_MODE[0x11] DFFSTAT[0x11]:(CURRFIFO_1|FIFO0FREE) SCSISIGI[0x0]:(P_DATAOUT) SCSIPHASE[0x0] SCSIBUS[0x0] LASTPHASE[0x80]:(P_COMMAND) SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x10]:(FASTMODE) SEQINTCTL[0x80]:(INTVEC1DSL) SEQ_FLAGS[0x40]:(NO_CDB_SENT) SEQ_FLAGS2[0x0] SSTAT0[0x0] SSTAT1[0x8]:(BUSFREE) SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0x0] SIMODE1[0xac]:(ENSCSIPERR|ENBUSFREE|ENSCSIRST|ENSELTIMO) LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x0] SCB Count = 16 CMDS_PENDING = 1 LASTSCB 0xc CURRSCB 0xc NEXTSCB 0x0 qinstart = 22 qinfifonext = 22 QINFIFO: WAITING_TID_QUEUES: Pending list: Total 0 Kernel Free SCB list: 12 1 2 3 4 5 6 7 8 9 10 11 13 14 15 0 Sequencer Complete DMA-inprog list: Sequencer Complete list: Sequencer DMA-Up and Complete list: ahd1: FIFO0 Free, LONGJMP == 0x80ff, SCB 0x0 SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x0] ahd1: FIFO1 Active, LONGJMP == 0x8072, SCB 0xc SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x88]:(HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0xc]:(DLZERO|SHVALID) SHADDR = 0x00, SHCNT = 0x6 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) LQIN: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 ahd1: LQISTATE = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x42 ahd1: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x0 SIMODE0[0xc]:(ENOVERRUN|ENIOERR) CCSCBCTL[0x4]:(CCSCBDIR) ahd1: REG0 == 0x53b8, SINDEX = 0x100, DINDEX = 0xe1 ahd1: SCBPTR == 0x0, SCB_NEXT == 0xff00, SCB_NEXT2 == 0x0 CDB 0 0 0 0 0 0 STACK: 0x23 0xa2 0xf1 0x0 0x0 0x0 0x0 0x0 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> (ahd1:A:3:1): Sending PPR bus_width 1, period 9, offset 1f, ppr_options 3f (ahd1:A:3:1): Received PPR width 1, period 9, offset 1f,options 3f Filtered to width 1, period 9, offset 1f, options 3f (probe0:ahd1:0:3:1): Unexpected busfree in Command phase, 1 SCBs aborted, PRGMCNT == 0x96 -------------------------------------------------------------------------------- and So on..... -- Steve Grandi National Optical Astronomy Observatory/AURA Inc., Tucson AZ USA Internet: grandi@noao.edu Voice: +1 520 318-8228 FAX: +1 520 318-8360 From owner-freebsd-scsi@FreeBSD.ORG Tue Jul 1 15:08:06 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC0E237B401 for ; Tue, 1 Jul 2003 15:08:06 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44CE94402B for ; Tue, 1 Jul 2003 15:08:04 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h61M83s16191; Tue, 1 Jul 2003 15:08:04 -0700 Received: from [10.100.253.70] (aslan.btc.adaptec.com [10.100.253.70]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id PAA15530; Tue, 1 Jul 2003 15:08:02 -0700 (PDT) Date: Tue, 01 Jul 2003 16:09:13 -0600 From: "Justin T. Gibbs" To: Steve Grandi , freebsd-scsi@freebsd.org Message-ID: <112840000.1057097353@aslan.btc.adaptec.com> In-Reply-To: <20030701135436.R69773@regulus.tuc.noao.edu> References: <20030701135436.R69773@regulus.tuc.noao.edu> X-Mailer: Mulberry/3.1.0b3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: AIC 7902 driver in Stable: problems with a B channel drive. X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Justin T. Gibbs" List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2003 22:08:07 -0000 > What still doesn't work: I attach a JetStor III disk array (from AC&NC) to > the B channel of the embedded controller and the Stable boot goes into a > nice loop of "Dump Card State". See below for a listing of a couple of > cycles of this loop from a verbose dump. The AIC7902 BIOS correctly sees > the disk array as target 3 on the B channel of the controller. Is the JetStor III rated for U320? My guess is no, but that it is not properly rejecting the packetized request we make in our outgoing parallel protocol request message. To work around this broken device, disable packetized protocol in SCSI select. Just dropping the speed to 160 does not disable packetized protocol. You should probably disable QAS for this target as well. -- Justin From owner-freebsd-scsi@FreeBSD.ORG Tue Jul 1 15:11:02 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB9D937B401 for ; Tue, 1 Jul 2003 15:11:02 -0700 (PDT) Received: from noao.edu (noao.edu [140.252.1.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id D117043FF2 for ; Tue, 1 Jul 2003 15:11:01 -0700 (PDT) (envelope-from grandi@noao.edu) Received: from regulus.tuc.noao.edu (account grandi [140.252.1.146] verified) by noao.edu (CommuniGate Pro SMTP 4.1b8) with ESMTP-TLS id 7945964; Tue, 01 Jul 2003 15:11:01 -0700 Date: Tue, 1 Jul 2003 15:11:01 -0700 (MST) From: Steve Grandi X-X-Sender: grandi@regulus.tuc.noao.edu To: "Justin T. Gibbs" In-Reply-To: <112840000.1057097353@aslan.btc.adaptec.com> Message-ID: <20030701150951.K69773@regulus.tuc.noao.edu> References: <20030701135436.R69773@regulus.tuc.noao.edu> <112840000.1057097353@aslan.btc.adaptec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-scsi@freebsd.org Subject: Re: AIC 7902 driver in Stable: problems with a B channel drive. X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2003 22:11:02 -0000 No, the JetStor is a U160 device. I will try turning off the packetized protocol and QAS and see what happens. Thanks! On Tue, 1 Jul 2003, Justin T. Gibbs wrote: > > What still doesn't work: I attach a JetStor III disk array (from AC&NC) to > > the B channel of the embedded controller and the Stable boot goes into a > > nice loop of "Dump Card State". See below for a listing of a couple of > > cycles of this loop from a verbose dump. The AIC7902 BIOS correctly sees > > the disk array as target 3 on the B channel of the controller. > > Is the JetStor III rated for U320? My guess is no, but that it is not > properly rejecting the packetized request we make in our outgoing parallel > protocol request message. To work around this broken device, disable > packetized protocol in SCSI select. Just dropping the speed to 160 does > not disable packetized protocol. You should probably disable QAS for > this target as well. > > -- > Justin > > -- Steve Grandi National Optical Astronomy Observatory/AURA Inc., Tucson AZ USA Internet: grandi@noao.edu Voice: +1 520 318-8228 FAX: +1 520 318-8360 From owner-freebsd-scsi@FreeBSD.ORG Tue Jul 1 17:07:43 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2909337B401 for ; Tue, 1 Jul 2003 17:07:43 -0700 (PDT) Received: from bast.unixathome.org (bast.unixathome.org [66.11.174.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D03E4404D for ; Tue, 1 Jul 2003 17:07:42 -0700 (PDT) (envelope-from dan@langille.org) Received: from wocker (wocker.unixathome.org [192.168.0.99]) by bast.unixathome.org (Postfix) with ESMTP id 26B2B3D28; Tue, 1 Jul 2003 20:07:41 -0400 (EDT) From: "Dan Langille" To: Matthew Jacob Date: Tue, 01 Jul 2003 20:07:40 -0400 MIME-Version: 1.0 Message-ID: <3F01EA0C.420.5FD9390A@localhost> Priority: normal References: <1054550725.1582.1859.camel@rufus> In-reply-to: <20030603111738.X24586@wonky.in0.lcl> X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body cc: freebsd-scsi@freebsd.org Subject: Re: Differences between Solaris/Linux and FreeBSD X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2003 00:07:43 -0000 As a bacula fan I'd like to see it working on FreeBSD but I don't know what I can do in order to achieve that objective. Any ideas? On 3 Jun 2003 at 11:39, Matthew Jacob wrote: > > As promised, in this email, I will try my best to describe > > the differences I found between Solaris/Linux and FreeBSD > > concerning tape handling. There were five separate areas > > where I noticed differences: > > > > 1. On Solaris/Linux, the default behavior for ioctl(MTEOM) > > is to run in what they call slow mode. In this mode, the > > tape is positioned to the end of the data, and the driver > > returns the correct file number in the MTIOCGET packet. > > It is possible to enable fast-EOM, but no one uses it to > > my knowledge. > > > > On FreeBSD, you apparently always use the fast-EOM so that > > the tape position is unknown after the ioctl(). > > You *could* read block position. Particularly for h/w blocks this works > very fast when you need to locate. > > NB: SCSI-3 changed the layout for h/w block position stuff and I haven't > updated the FreeBSD driver to handle this yet. > > > Bacula always knows how many files are on a tape, and when > > appending to a tape that is already written and newly opened, > > it MUST know where it is on the tape. As a consequence, on > > FreeBSD, I must explicitly use MTFSF with read()s in between > > to position to the end of the tape -- a fairly slow affair. > > Uh, this is how 'slow' EOM works. It's not really faster to do it in the > kernel as opposed to in the driver. > > I must point out that you cannot, and should not, depend absolutely on > reported position. For tape you can ensure BOT or end of recorded media, > but otherwise you really must use self-referential data on the tape if > tape location is important. > > > 2. Your handling of EOM differs from Solaris/Linux. On both of > > those systems, when the Bacula reads the first EOF, the driver > > returns 0 bytes read. On reading the second EOF, the driver > > returns 0 bytes read, but before returning backspaces over > > the EOF, leaving you positioned correctly for appending to the > > tape and having told you you are at the end of the tape by > > giving two consecutive 0 byte read. Any further read() > > request return an I/O error. > > > > On FreeBSD, reading the first EOF returns 0 bytes, reading > > the second EOF also returns 0 bytes (sometimes, I apparently > > get "Illegal operation"). However, the tape is left positioned > > after the second EOF, so appending from that point effectively > > "loses" the data. > > > > To handle this correctly the FreeBSD user must add a configuration > > statement to Bacula telling him to backspace file at EOM. > > Yes. This is a problem. > > But part of the problem here is that dual-filemark at EOM is only one > tape convention- and a poorly thought out one at best- it exists > *solely* because a *few* (ancient) tape drives would unwind off the feed > reel if you kept advancing them. For QIC drives, you *cannot* write dual > filemarks (really). > > Note that there is a setting that can change the model to single EOM. If > I could have gotten away with it, I would have made this the default. > > I think, though, I'd accept that the FreeBSD behaviour is a bug that > should be fixed. If we have a dual fmk EOT model and are advancing along > and hit two in a row, we *probably* should say we're at logical EOT and > backspace over one of them. After all, this is what we do when we're > *writing* to tape and close the no-rewind device. > > I also would agree that this situation is exacerbated by the 'space to > end of recorded data' model for the MTEOM command. This now leaves us > with a legacy of tapes with spurious dual filemarks in the middle. > > Oops. This means that I really can't fix things the way you'd like :-(. > > > > > 3. I have previously described this but will do so again for > > completeness here. On Solaris/Linux when Bacula does: > > > > write(); > > ioctl(MTEOF); > > ioctl(MTEOF) > > ioctl(MTBSF); > > ioctl(MTBSF); > > ioctl(MTBSR); > > read(); > > > > the read() re-reads the last write. On FreeBSD, the read returns > > 0 bytes (there is also a problem of freezing the tape wrapped into > > this example if I am not mistaken). Apparently the 0 bytes read is > > because FreeBSD adds an additional EOF mark (not necessary) and > > leaves the drive positioned *after* the mark thus re-reading the > > last record fails when it logically should not. > > I don't believe that FreeBSD adds an additional filemark here, but I > should add this as a test case. I have another tester program that I use > for testing block locate, but I haven't really validated it or finished > it yet. > > Why, btw, are you issuing two MTEOFs? The mtop has a count field y'know > :-). > > > > > 4. Tape freezing: On Solaris/Linux, the tape never "freezes". On > > FreeBSD it does freeze. As best I can determine, you freeze the > > drive when you lose track of where you are. Typically, this > > occurs when I do a MTBSR to re-read the last record. On Solaris/Linux > > the tape is never frozen, but when they don't know the position, > > they simply return -s in the MTIOCGET packet, which is fine with > > me because Bacula only uses that info when initially reading a > > tape to append to it. > > > > Freezing the tape causes all sorts of problems because it generates > > a flood of unexpected errors. Within a large complicated program like > > Bacula, when a low level routine re-reads a record during writing and > > the tape freezes, it cannot simply rewind the drive as this could > > cause chaos and possible overwriting of the beginning of the drive. > > > > I've attempted to overcome tape freezing by providing the user a > > means to turn off MTBSR (but they don't always do so), and by issuing > > ioctl(MTIOCERRSTAT) after every return of -1 from any I/O request. > > > > I recommend that you do away with freezing the drive -- it seems to > > me that it only causes more problems. In saying that I have to > > that I really do not understand tape freezing or why you do it since > > I found no documentation on it, and everything I write above I have > > deduced from what Dan has reported back to me. > > Freezing the drive is precisely what Solaris and Linux *should* do. If > you've lost position, you have to take some action to bring the tape to > a known position. The unaware application should not be allowed to > overwrite in random spots on the tape. If your low level read/write > routines get any kind of error, you have to move to a "what do I have in > my tape drive now?" state anyway. > > You know, I was pretty sure I'd documented the freeze option, but I > cannot find it in the man page (sa(4)) now at all. > > > > > > 5. I am quite fuzzy on this point because I forget exactly what happened > > and what I did about it. > > > > It seems to me that on Linux, if I read a block but specify a number > > of bytes less than the number actually in the block on the tape, the > > driver returns the data anyway. I then check if the block is > > internally complete and if not, increase my record size to the size > > indicated in the data received, backspace one record, and re-read it. > > > > If I am not mistaken, on FreeBSD, the first read returns an error, > > and Bacula just immediately gives up. Your documentation specifies > > that one can never read a partial record from a tape, but it does not > > specify what error code is generated. As a consequence, rather than > > recovering and re-reading the record, Bacula has to assume it was > > a fatal error. > > The reason linux 'succeeds' here is because linux internally reads all > tape data to an oversized buffer in kernel memory anyway. This means > that it doesn't suffer an 'overrun' condition which is what you are > doing if you attempt to read *less* than a tape record size. Solaris > will fail the same way, btw, as FreeBSD. > > What you should always do is start out by reading the largest possible > record size (a pathetic 64KB for FreeBSD) and adjust *downward* (if > desired and you are just autosizing to find a tape record size). > > > THanks for doing the critique. There's definitely food for thought here > and some changes that *should* be made. -- Dan Langille : http://www.langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Tue Jul 1 17:42:59 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FBD137B401 for ; Tue, 1 Jul 2003 17:42:56 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 28D4043FE5 for ; Tue, 1 Jul 2003 17:42:55 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 88666 invoked by uid 1000); 2 Jul 2003 00:42:56 -0000 Date: Tue, 1 Jul 2003 17:42:56 -0700 (PDT) From: Nate Lawson To: Jack Patton In-Reply-To: <200307011459.aa18828@flag.60north.net> Message-ID: <20030701174149.X88547@root.org> References: <200307011459.aa18828@flag.60north.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-scsi@freebsd.org cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/53566: IBM Eserver (245 || 345) + ServeRaid 5i ips driver panic X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2003 00:43:00 -0000 On Tue, 1 Jul 2003, Jack Patton wrote: > Nate Lawson said: > > Disable acpi and try again. Update your BIOS to hopefully get new ACPI > > code. There's some problem here with unitialized memory. It may be > > elsewhere though and ACPI is just stumbling onto it. > > Here's the result of booting with hint.acpi.0.disabled=1. We just got this > server recently. The server BIOS is at the latest version. I'm downloading a > BIOS/Firmware for the ServeRaid card itself now and will test it with that > applied. > > Memory modified after free 0xc18b5700(252) > panic: Most recently used by devbuf > > Debugger("panic") > Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 > db> tr > Debugger(c05025bf,c05c5240,c0519512,c0b35ca4,100) at Debugger+0x54 > panic(c0519512,c0500e61,fc,c0c3ab74,c0c3ab60) at panic+0xcc > mtrash_ctor(c18b5700,100,0,549,c18b5700) at mtrash_ctor+0x5d > uma_zalloc_arg(c0c3ab60,0,101,c0327740,c0599ca8) at uma_zalloc_arg+0x194 > malloc(a8,c0556ac0,101,c05226b0,c0b35d6c) at malloc+0xd4 > device_get_children(c4321380,c0b35d58,c0b35d5c,c0325d82,c18bf700) at > device_get_ > children+0x47 > isa_probe_children(c4321380,c051c640,0,c0b35d98,c02e9a25) at > isa_probe_children+ > 0x2d > configure(0,b32000,b32c00,b32000,0) at configure+0x4b > mi_startup() at mi_startup+0xb5 > begin() at begin+0x2c > db> Nope, I was wrong. Looks like it is indeed our problem. At least this tr is easier to read. :) -Nate From owner-freebsd-scsi@FreeBSD.ORG Tue Jul 1 18:50:41 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCB4437B401 for ; Tue, 1 Jul 2003 18:50:41 -0700 (PDT) Received: from bucaramanga.oriental.ac (CTS210191135087.cts.ne.jp [210.191.135.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2B1F43FBF for ; Tue, 1 Jul 2003 18:50:40 -0700 (PDT) (envelope-from shuji.kono@oriental.ac) Received: from [127.0.0.1] (219-106-254-10.cust.bit-drive.ne.jp [219.106.254.10]) by bucaramanga.oriental.ac (Postfix) with ESMTP id 5661E34D59 for ; Wed, 2 Jul 2003 10:50:39 +0900 (JST) Date: Wed, 02 Jul 2003 10:50:36 +0900 From: Shuji Kono To: freebsd-scsi@freebsd.org Message-Id: <20030702100010.B057.SHUJI.KONO@oriental.ac> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.10 Subject: Inconsistent softupdate after installation of MegaMonitor X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2003 01:50:42 -0000 I'm running 2 servers with 4.8-STABLE and MegaRAID Express500. Recently I installed MegaMonitor1.02 and MegaMgr6.00 but some inconsistencies on the filesystem are reported since then. I'm not sure if this was caused by MegaMonitor but I've never experienced this before using MegaMonitor. Does anyone have ideas? Both servers have the same hardware specs: Supermicro Superserver 6010H, PentiumIII 1.0BGHz x 2, 256MB DIMM x 2, Express500, Seagate ST336607LC x 2 (RAID-1) Server 1: Postfix core dumped few minutes after installation. I rebooted the server but it caused kernel panic. Rebooted again and it seems working now. Postfix started logging this repeatedly after installation of MegaMonitor: > Jun 26 11:36:43 server1 postfix/master[162]: warning: process /usr/local/lib > exec/postfix/proxymap pid 49073 killed by signal 11 > Jun 26 11:36:43 server1 postfix/master[162]: warning: /usr/local/libexec/pos > tfix/proxymap: bad command startup -- throttling kernel log: > pid 49073 (proxymap), uid 0: exited on signal 11 (core dumped) > pid 49075 (proxymap), uid 0: exited on signal 11 (core dumped) > pid 49076 (proxymap), uid 0: exited on signal 11 (core dumped) > . > . I tried restarting Postfix but it would not listen smtp any more. I rebooted the server and got the following logs: > Fatal trap 12: page fault while in kernel mode > mp_lock = 00000002; cpuid = 0; lapic.id = 00000000 > fault virtual address = 0x30 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc022a660 > stack pointer = 0x10:0xd739cd8c > frame pointer = 0x10:0xd739cd8c > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 250 (httpd) > interrupt mask = none <- SMP: XXX > trap number = 12 > panic: page fault > mp_lock = 00000002; cpuid = 0; lapic.id = 00000000 > boot() called on cpu#0 > > syncing disks... 57 18 7 6 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 > giving up on 2 buffers > Uptime: 53s > Automatic reboot in 15 seconds - press a key on the console to abort > WARNING: / was not properly dismounted Then I rebooted the server again. fsck completed successfully and server1 returned to the normal state. Server 2: Started reporting filesystem inconsistency after installation of MegaMonitor. egrep core dumps everytime it runs. daily run output: > find: /usr/src/contrib/libstdc++/std/bastring.cc: Bad file descriptor > find: /usr/src/contrib/libstdc++/std/bastring.h: Bad file descriptor > find: /usr/src/contrib/libstdc++/std/complext.cc: Bad file descriptor > . > . > find: /usr/src/contrib/libstdc++/stl/function.h: Bad file descriptor fsck: > ** /dev/amrd0s1f (NO WRITE) > ** Last Mounted on /usr > ** Phase 1 - Check Blocks and Sizes > PARTIALLY ALLOCATED INODE I=518852 > UNEXPECTED SOFT UPDATE INCONSISTENCY > > PARTIALLY ALLOCATED INODE I=518861 > UNEXPECTED SOFT UPDATE INCONSISTENCY > > PARTIALLY ALLOCATED INODE I=518875 > UNEXPECTED SOFT UPDATE INCONSISTENCY > > ** Phase 2 - Check Pathnames > UNALLOCATED I=518849 OWNER=root MODE=0 > SIZE=0 MTIME=Jan 1 09:00 1970 > NAME=/src/contrib/libstdc++/std/bastring.cc > > UNEXPECTED SOFT UPDATE INCONSISTENCY > > UNALLOCATED I=518850 OWNER=root MODE=0 > SIZE=0 MTIME=Jan 1 09:00 1970 > NAME=/src/contrib/libstdc++/std/bastring.h > > UNEXPECTED SOFT UPDATE INCONSISTENCY > > UNALLOCATED I=518851 OWNER=root MODE=0 > SIZE=0 MTIME=Jan 1 09:00 1970 > NAME=/src/contrib/libstdc++/std/complext.cc > > UNEXPECTED SOFT UPDATE INCONSISTENCY > . > . > UNALLOCATED I=518879 OWNER=root MODE=0 > SIZE=0 MTIME=Jan 1 09:00 1970 > NAME=/src/contrib/libstdc++/stl/function.h > > UNEXPECTED SOFT UPDATE INCONSISTENCY > > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > LINK COUNT FILE I=2060810 OWNER=root MODE=0 > SIZE=0 MTIME=Jul 2 10:44 2003 COUNT 0 SHOULD BE -1 > > ** Phase 5 - Check Cyl groups > FREE BLK COUNT(S) WRONG IN SUPERBLK > > SUMMARY INFORMATION BAD > > BLK(S) MISSING IN BIT MAPS > > 166647 files, 739567 used, 14837246 free (49006 frags, 1848530 blocks, 0.3% frag > mentation) kernel log: > Jun 30 03:01:45 server2 /kernel: pid 1271 (egrep), uid 0: exited on signal 11 (core dumped) > Jun 30 03:01:45 server2 /kernel: pid 1289 (egrep), uid 0: exited on signal 11 (core dumped) > Jun 30 04:50:00 server2 /kernel: pid 1475 (egrep), uid 0: exited on signal 11 (core dumped) > . > . I'm unable to fix nor remove those corrupted files. I also tried fsck and clri with any possible options but could not free the inodes. MegaMonitor itself is working fine. -- Shuji Kono From owner-freebsd-scsi@FreeBSD.ORG Tue Jul 1 23:11:26 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9259737B401 for ; Tue, 1 Jul 2003 23:11:26 -0700 (PDT) Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AE4544005 for ; Tue, 1 Jul 2003 23:11:25 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.12.9/8.12.9) with ESMTP id h626BNKa049358; Tue, 1 Jul 2003 23:11:24 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Tue, 1 Jul 2003 23:11:23 -0700 (PDT) From: Matthew Jacob X-X-Sender: mjacob@beppo To: Dan Langille In-Reply-To: <3F01EA0C.420.5FD9390A@localhost> Message-ID: <20030701230949.G48388@beppo> References: <1054550725.1582.1859.camel@rufus> <3F01EA0C.420.5FD9390A@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-scsi@freebsd.org Subject: Re: Differences between Solaris/Linux and FreeBSD X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mjacob@feral.com List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2003 06:11:26 -0000 the last I heard this was in the bacula court- I've been away, and will be away again shortly for the fourth of july. there's a compat issue for fixing stuff mentioned below. what do you think is broken at this point? On Tue, 1 Jul 2003, Dan Langille wrote: > As a bacula fan I'd like to see it working on FreeBSD but I don't > know what I can do in order to achieve that objective. Any ideas? > > On 3 Jun 2003 at 11:39, Matthew Jacob wrote: > > > > As promised, in this email, I will try my best to describe > > > the differences I found between Solaris/Linux and FreeBSD > > > concerning tape handling. There were five separate areas > > > where I noticed differences: > > > > > > 1. On Solaris/Linux, the default behavior for ioctl(MTEOM) > > > is to run in what they call slow mode. In this mode, the > > > tape is positioned to the end of the data, and the driver > > > returns the correct file number in the MTIOCGET packet. > > > It is possible to enable fast-EOM, but no one uses it to > > > my knowledge. > > > > > > On FreeBSD, you apparently always use the fast-EOM so that > > > the tape position is unknown after the ioctl(). > > > > You *could* read block position. Particularly for h/w blocks this works > > very fast when you need to locate. > > > > NB: SCSI-3 changed the layout for h/w block position stuff and I haven't > > updated the FreeBSD driver to handle this yet. > > > > > Bacula always knows how many files are on a tape, and when > > > appending to a tape that is already written and newly opened, > > > it MUST know where it is on the tape. As a consequence, on > > > FreeBSD, I must explicitly use MTFSF with read()s in between > > > to position to the end of the tape -- a fairly slow affair. > > > > Uh, this is how 'slow' EOM works. It's not really faster to do it in the > > kernel as opposed to in the driver. > > > > I must point out that you cannot, and should not, depend absolutely on > > reported position. For tape you can ensure BOT or end of recorded media, > > but otherwise you really must use self-referential data on the tape if > > tape location is important. > > > > > 2. Your handling of EOM differs from Solaris/Linux. On both of > > > those systems, when the Bacula reads the first EOF, the driver > > > returns 0 bytes read. On reading the second EOF, the driver > > > returns 0 bytes read, but before returning backspaces over > > > the EOF, leaving you positioned correctly for appending to the > > > tape and having told you you are at the end of the tape by > > > giving two consecutive 0 byte read. Any further read() > > > request return an I/O error. > > > > > > On FreeBSD, reading the first EOF returns 0 bytes, reading > > > the second EOF also returns 0 bytes (sometimes, I apparently > > > get "Illegal operation"). However, the tape is left positioned > > > after the second EOF, so appending from that point effectively > > > "loses" the data. > > > > > > To handle this correctly the FreeBSD user must add a configuration > > > statement to Bacula telling him to backspace file at EOM. > > > > Yes. This is a problem. > > > > But part of the problem here is that dual-filemark at EOM is only one > > tape convention- and a poorly thought out one at best- it exists > > *solely* because a *few* (ancient) tape drives would unwind off the feed > > reel if you kept advancing them. For QIC drives, you *cannot* write dual > > filemarks (really). > > > > Note that there is a setting that can change the model to single EOM. If > > I could have gotten away with it, I would have made this the default. > > > > I think, though, I'd accept that the FreeBSD behaviour is a bug that > > should be fixed. If we have a dual fmk EOT model and are advancing along > > and hit two in a row, we *probably* should say we're at logical EOT and > > backspace over one of them. After all, this is what we do when we're > > *writing* to tape and close the no-rewind device. > > > > I also would agree that this situation is exacerbated by the 'space to > > end of recorded data' model for the MTEOM command. This now leaves us > > with a legacy of tapes with spurious dual filemarks in the middle. > > > > Oops. This means that I really can't fix things the way you'd like :-(. > > > > > > > > 3. I have previously described this but will do so again for > > > completeness here. On Solaris/Linux when Bacula does: > > > > > > write(); > > > ioctl(MTEOF); > > > ioctl(MTEOF) > > > ioctl(MTBSF); > > > ioctl(MTBSF); > > > ioctl(MTBSR); > > > read(); > > > > > > the read() re-reads the last write. On FreeBSD, the read returns > > > 0 bytes (there is also a problem of freezing the tape wrapped into > > > this example if I am not mistaken). Apparently the 0 bytes read is > > > because FreeBSD adds an additional EOF mark (not necessary) and > > > leaves the drive positioned *after* the mark thus re-reading the > > > last record fails when it logically should not. > > > > I don't believe that FreeBSD adds an additional filemark here, but I > > should add this as a test case. I have another tester program that I use > > for testing block locate, but I haven't really validated it or finished > > it yet. > > > > Why, btw, are you issuing two MTEOFs? The mtop has a count field y'know > > :-). > > > > > > > > 4. Tape freezing: On Solaris/Linux, the tape never "freezes". On > > > FreeBSD it does freeze. As best I can determine, you freeze the > > > drive when you lose track of where you are. Typically, this > > > occurs when I do a MTBSR to re-read the last record. On Solaris/Linux > > > the tape is never frozen, but when they don't know the position, > > > they simply return -s in the MTIOCGET packet, which is fine with > > > me because Bacula only uses that info when initially reading a > > > tape to append to it. > > > > > > Freezing the tape causes all sorts of problems because it generates > > > a flood of unexpected errors. Within a large complicated program like > > > Bacula, when a low level routine re-reads a record during writing and > > > the tape freezes, it cannot simply rewind the drive as this could > > > cause chaos and possible overwriting of the beginning of the drive. > > > > > > I've attempted to overcome tape freezing by providing the user a > > > means to turn off MTBSR (but they don't always do so), and by issuing > > > ioctl(MTIOCERRSTAT) after every return of -1 from any I/O request. > > > > > > I recommend that you do away with freezing the drive -- it seems to > > > me that it only causes more problems. In saying that I have to > > > that I really do not understand tape freezing or why you do it since > > > I found no documentation on it, and everything I write above I have > > > deduced from what Dan has reported back to me. > > > > Freezing the drive is precisely what Solaris and Linux *should* do. If > > you've lost position, you have to take some action to bring the tape to > > a known position. The unaware application should not be allowed to > > overwrite in random spots on the tape. If your low level read/write > > routines get any kind of error, you have to move to a "what do I have in > > my tape drive now?" state anyway. > > > > You know, I was pretty sure I'd documented the freeze option, but I > > cannot find it in the man page (sa(4)) now at all. > > > > > > > > > > 5. I am quite fuzzy on this point because I forget exactly what happened > > > and what I did about it. > > > > > > It seems to me that on Linux, if I read a block but specify a number > > > of bytes less than the number actually in the block on the tape, the > > > driver returns the data anyway. I then check if the block is > > > internally complete and if not, increase my record size to the size > > > indicated in the data received, backspace one record, and re-read it. > > > > > > If I am not mistaken, on FreeBSD, the first read returns an error, > > > and Bacula just immediately gives up. Your documentation specifies > > > that one can never read a partial record from a tape, but it does not > > > specify what error code is generated. As a consequence, rather than > > > recovering and re-reading the record, Bacula has to assume it was > > > a fatal error. > > > > The reason linux 'succeeds' here is because linux internally reads all > > tape data to an oversized buffer in kernel memory anyway. This means > > that it doesn't suffer an 'overrun' condition which is what you are > > doing if you attempt to read *less* than a tape record size. Solaris > > will fail the same way, btw, as FreeBSD. > > > > What you should always do is start out by reading the largest possible > > record size (a pathetic 64KB for FreeBSD) and adjust *downward* (if > > desired and you are just autosizing to find a tape record size). > > > > > > THanks for doing the critique. There's definitely food for thought here > > and some changes that *should* be made. > > -- > Dan Langille : http://www.langille.org/ > > From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 2 12:04:13 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94F7137B401 for ; Wed, 2 Jul 2003 12:04:13 -0700 (PDT) Received: from fatpipi.cirx.org (fatpipi.cirx.org [211.23.144.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8247A43FD7 for ; Wed, 2 Jul 2003 12:04:12 -0700 (PDT) (envelope-from clive@tongi.org) Received: from fatpipi.cirx.org (nullmail@internal-fxp.home [192.168.1.254]) by fatpipi.cirx.org (8.12.8p1/8.12.8) with SMTP id h62J4AFY091214; Thu, 3 Jul 2003 03:04:10 +0800 (CST) (envelope-from clive@tongi.org) Received: (nullmailer pid 91212 invoked by uid 1000); Wed, 02 Jul 2003 19:04:10 -0000 Date: Thu, 3 Jul 2003 03:04:09 +0800 From: Clive Lin To: The Hermit Hacker Message-ID: <20030702190409.GA90932@fatpipi.cirx.org> References: <20030517200209.Q598@hub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030517200209.Q598@hub.org> X-Operating-System: FreeBSD i386 X-PGP-key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA008C03E User-Agent: Mutt/1.5.4i cc: freebsd-scsi@freebsd.org Subject: Re: talking to iir driver ... ? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2003 19:04:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, May 17, 2003 at 08:11:03PM -0300, The Hermit Hacker wrote: > > Morning all ... > > Is there a way, with camcontrol, of probing the iir drive to find out > what drives are sitting behind it? Or a command line interface to talk to > the controller similar to Adaptec's aacli? Hi, There's a aacli like (?) utility for freebsd. It's right at Intel web site, but NOT on the bundled CDROM :p http://www.intel.com/support/motherboards/server/srczcr/software.htm You'll have a package called iir-1.1.tgz inside the FreeBSD_212.zip. I did not tend to just `pkg_add iir-1.1.tgz`, because it will install intel's iir.ko, which is for 4.1. Just extract the storcon binary and issue `cd /dev; mknod iir c 164 0` is ok. The mknod is "documented" in the +POST-INSTALL file of the package. I'll spend some time to understand another utility called srcd, in order to make a asr-util like port. Clive -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/AyyXdFUoBaAIwD4RAqeZAKCC2h9awTPQHAEJpaVhMeLNa6wH8gCeMI2V GQQRj7uS+DnZvLt2fW8YaNY= =OQVC -----END PGP SIGNATURE----- From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 2 19:32:51 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8D6537B401 for ; Wed, 2 Jul 2003 19:32:51 -0700 (PDT) Received: from noao.edu (noao.edu [140.252.1.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 161B743FE5 for ; Wed, 2 Jul 2003 19:32:51 -0700 (PDT) (envelope-from grandi@noao.edu) Received: from [216.39.178.13] (HELO D4KHWJ11) by noao.edu (CommuniGate Pro SMTP 4.1b8) with ESMTP-TLS id 7978609; Wed, 02 Jul 2003 19:32:49 -0700 Date: Wed, 2 Jul 2003 19:32:45 -0700 (US Mountain Standard Time) From: Steve Grandi To: "Justin T. Gibbs" In-Reply-To: <112840000.1057097353@aslan.btc.adaptec.com> Message-ID: References: <20030701135436.R69773@regulus.tuc.noao.edu> <112840000.1057097353@aslan.btc.adaptec.com> X-X-Sender: grandi@email.noao.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-scsi@freebsd.org Subject: Re: AIC 7902 driver in Stable: problems with a B channel drive. X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2003 02:32:52 -0000 That did the trick! Thanks, Justin! I will also tell the folks at AC&NC about the problem. On Tue, 1 Jul 2003, Justin T. Gibbs wrote: > > What still doesn't work: I attach a JetStor III disk array (from AC&NC) to > > the B channel of the embedded controller and the Stable boot goes into a > > nice loop of "Dump Card State". See below for a listing of a couple of > > cycles of this loop from a verbose dump. The AIC7902 BIOS correctly sees > > the disk array as target 3 on the B channel of the controller. > > Is the JetStor III rated for U320? My guess is no, but that it is not > properly rejecting the packetized request we make in our outgoing parallel > protocol request message. To work around this broken device, disable > packetized protocol in SCSI select. Just dropping the speed to 160 does > not disable packetized protocol. You should probably disable QAS for > this target as well. > > -- > Justin > > -- Steve Grandi National Optical Astronomy Observatory/AURA Inc., Tucson AZ USA Internet: grandi@noao.edu Voice: +1 520 318-8228 FAX: +1 520 318-8360 From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 2 22:45:38 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8F7B37B401 for ; Wed, 2 Jul 2003 22:45:38 -0700 (PDT) Received: from postoffice.e-easy.com.au (eth0.lnk.e-easy.com.au [203.31.73.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1910E43FCB for ; Wed, 2 Jul 2003 22:45:37 -0700 (PDT) (envelope-from nigel@e-easy.com.au) Received: from postoffice.aims.com.au (nts-ts1.aims.private [192.168.10.2]) by postoffice.e-easy.com.au with ESMTP id h635jWH0005048 for ; Thu, 3 Jul 2003 15:45:32 +1000 (EST) (envelope-from nigel@e-easy.com.au) Received: from ntsts1 by aims.com.au (MDaemon.PRO.v6.8.4.R) with ESMTP id 41-md50000000013.tmp for ; Thu, 03 Jul 2003 15:45:28 +1000 From: "Nigel Weeks" To: Date: Thu, 3 Jul 2003 15:45:27 +1000 Message-ID: <002301c34126$4ee04870$020aa8c0@aims.private> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Importance: High X-Spam-Processed: aims.com.au, Thu, 03 Jul 2003 15:45:28 +1000 (not processed: spam filter disabled) X-Return-Path: nigel@e-easy.com.au X-MDaemon-Deliver-To: freebsd-scsi@freebsd.org X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-0.7 required=4.6 tests=AWL,BAYES_20,X_MSMAIL_PRIORITY_HIGH,X_PRIORITY_HIGH version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: Mylex RAID Performance X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2003 05:45:38 -0000 Has anyone got more than about 5MB/sec out of a Mylex DAC960PD? I have two striped 7200RPM 68-pin wide ultra drives on a channel (each channel supposed to handle 40MB/sec) Having one drive on each channel made no difference. Running the following command resulted in 5MB/sec maximum throughput dd if=/dev/zero of=/u1/hog bs=1024 count=5000 I tried this of block sizes (bs parameter) of 1024, 2048, 4096, 8192, 16000, and 32000 Any ideas? Nige. -------------------------------------------------------- Nigel Weeks E-Easy 15 Wellington St. Launceston Tas 7250 Ph. 61 3 6334 6664 Fax. 61 3 6331 7032 Email. nigel@e-easy.com.au Web: www.e-easy.com.au --------------------------------------------------------