From owner-freebsd-ia64@FreeBSD.ORG Thu Feb 10 17:36:23 2005 Return-Path: Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0575216A4CE for ; Thu, 10 Feb 2005 17:36:23 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34CF943D45 for ; Thu, 10 Feb 2005 17:36:22 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.1/8.13.1) with ESMTP id j1AHaL2f074844; Thu, 10 Feb 2005 09:36:21 -0800 (PST) (envelope-from marcel@xcllnt.net) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3b5f2cfc893b5249791b0b3c051e70fe@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Thu, 10 Feb 2005 09:36:20 -0800 To: m X-Mailer: Apple Mail (2.619.2) cc: ia64@FreeBSD.org Subject: Re: FreeBSD IA64 5.3/RELEASE on Compaq DL590. (boot error) X-BeenThere: freebsd-ia64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the IA-64 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2005 17:36:23 -0000 On Feb 9, 2005, at 10:25 PM, m wrote: >> From: m >> Date: Wed, 09 Feb 2005 20:42:46 -0500 >> To: Marcel Moolenaar >> Cc: >> Subject: Re: FreeBSD IA64 5.3/RELEASE on Compaq DL590. (boot error) >> >> Marcel Moolenaar (marcel@xcllnt.net) wrote: >>> >>> On Wed, Feb 09, 2005 at 07:30:30PM -0500, bigcat@runningleopard.com >>> wrote: >>>> >>>> pci25: on pcib6 >>>> ida0: port 0xc000-0xc0ff mem >>> 0x43000000-0x43ffffff,0x41000000-0x41ffffff irq 110 at device >>> 8.0 on pci25 >>>> ida0: [GIANT-LOCKED] >>>> >>>> fatal kernel trap (cpu 0): >>>> >>>> trap vector = 0x14 (Page Not Present) >>>> cr.iip = 0xe000000004288350 >>>> cr.ipsr = 0x1210080a2010 (mfl,ic,dt,dfh,rt,cpl=0,it,ri=1,bn) >>>> cr.isr = 0x20400000000 (code=0,vector=0,r,ei=1) >>>> cr.ifa = 0xa0000000dbd0610c >>>> curthread = 0xe0000000049815e8 >>>> pid = 0, comm = swapper >>>> >>>> [thread 0] >>>> Stopped at ida_command+0x2e1: [M1] ld8 r14=[r14] >>>> db> >>> >>> Ouch... >>> >>>> Any ideas? >>> >>> First of all: A backtrace would definitely help. At the "db>" prompt >>> type: >>> trace >>> >> Here you go: >> >> db> trace >> ida_command(0xe0000000008a4600, 0x11, 0xe0000000048f11e0, 0x200, 0x0, >> 0x0, >> 0x1) >> at ida_command+0x2e1 >> ida_attach(0xe0000000008a4600, 0xe0000000008a4690, 0xe0000000008a4668, >> 0xe000000 >> 0008a4700, 0xe00000000428a1c0, 0x410, 0xe000000004b481f0) at >> ida_attach+0x80 >> ida_pci_attach(0xe0000000008b0d00, 0x0, 0xe0000000008a4600, >> 0xe0000000008a4688, >> 0x101000, 0xe00000000449c790, 0x797, 0xe000000004b481f0) at >> ida_pci_attach+0x4a0 >> >> device_attach(0xe0000000008b0d00) at device_attach+0x4c0 >> bus_generic_attach(0xe0000000008b0d00, 0xe00000000410bd50, 0x38d, >> 0xe00000000486 >> cd40) at bus_generic_attach+0x40 >> acpi_pci_attach(0xe0000000008b0c00, 0xe0000000008e4800, >> 0xe0000000048f2320, >> 0xe0 >> 000000048f1448, 0xe00000000449c790, 0x797, 0xe000000004b481f0) at >> acpi_pci_attac >> h+0x250 >> device_attach(0xe0000000008b0c00) at device_attach+0x4c0 >> bus_generic_attach(0xe0000000008b0c00, 0xe00000000410f460, 0x50e, >> 0xe0000000009d >> 01c0) at bus_generic_attach+0x40 >> acpi_pcib_attach(0xe0000000008e4800, 0xe0000000009158e0, 0x19, >> 0xe0000000001a200 >> 0, 0xe0000000048f2320) at acpi_pcib_attach+0x1a0 >> acpi_pcib_acpi_attach(0xe0000000008e4800, 0xe0000000009158d4, >> 0xe0000000048f1478 >> , 0xe0000000009158d8, 0xe0000000009158c8, 0xe0000000009158c0, >> 0xe00000000449c790 >> , 0x797) at acpi_pcib_acpi_attach+0x370 >> device_attach(0xe0000000008e4800) at device_attach+0x4c0 >> bus_generic_attach(0xe0000000008e4800, 0xe0000000040fb180, 0xa9d, >> 0xe0000000048f >> 20a0) at bus_generic_attach+0x40 >> acpi_attach(0xe0000000001a2000, 0xe000000000953988, 0x0, >> 0xe0000000048f14b8, >> 0xe >> 0000000048f14a8, 0xe0000000008d6248, 0xe000000004830728, >> 0xe000000000953990) >> at >> acpi_attach+0xc20 >> device_attach(0xe0000000001a2000) at device_attach+0x4c0 >> bus_generic_attach(0xe0000000001a2000) at bus_generic_attach+0x40 >> nexus_attach(0xe0000000001a2200, 0xe00000000449c790, 0x797, >> 0xe00000000449c760) >> at nexus_attach+0xd0 >> device_attach(0xe0000000001a2200) at device_attach+0x4c0 >> root_bus_configure(0xe0000000001a2200, 0xe0000000047bda70, 0x186) at >> root_bus_co >> nfigure+0x50 >> configure(0xe00000000440cb90, 0x48b) at configure+0x60 >> mi_startup(0xe000000004867440, 0xe000000004981d50, >> 0xe000000004981d58, 0x1, >> 0xe0 >> 00000004981d48, 0xe000000004981d60, 0xe0000000047d44b0, 0x899) at >> mi_startup+0x2 >> c0 >> ia64_init(0xe000000004981788) at ia64_init+0xc70 >> __start() at __start+0xa0 >> db> >> >>> Secondly: It looks like the ida(4) driver is not 64-bit clean. The >>> faulting instruction is an 8-byte wide load from an address that's >>> not 8-byte aligned. This is always fatal in the kernel, although >>> it's not the reason for the panic in this case. Nonetheless, the >>> code is suspicious... >>> >>>> I'm suspecting that there is no kernel loadable for the Compaq Disk >>>> Array, >>>> perhaps? >>> >>> The ida(4) driver comes as a loadable kernel module, but happens >>> to be compiled into the kernel by default. Unfortunately this means >>> that I need to create a new snapshot with the ida(4) driver removed >>> from the kernel, or you remove the Compaq Disk Array from the machine >>> until you can build your own kernel without the ida(4) driver. >>> >>> As for fixing the ida(4) driver: I don't have the hardware, so I >>> can't do that and I need to see the backtrace to see if one can >>> fix the ida(4) driver on any 64-bit machine, or if it has to be >>> an ia64 box... >>> >> >> Unfortunately, that's not an option for me; I need to use the CDA as >> I don't >> have any other drives that would be usable! >> > > Actually, on further investigation, that's a def. possibility. There > is > enough room to add other drives, including IDE or SCSI on a diff. bus > that's > not controlled by the Compaq IDA. I looked at the code of the ida(4) driver some more and it's best I remove the driver from the kernel for now. > If anyone would like remote desktop access to a machine with a console > on > this machine to work, I'll set it up. Yes, that would be good. I could make the ida(4) driver 64-bit clean. It's much easier if FreeBSD is already installed on the DL590 (having taken out the CDA first), and a new kernel is built that doesn't have the ida(4) driver. Then the CDA can be inserted again and I have a good platform to work on. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net