Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 Feb 2005 01:25:00 -0500
From:      m <m@telerama.com>
To:        Marcel Moolenaar <marcel@xcllnt.net>
Cc:        freebsd-ia64@freebsd.org
Subject:   Re: FreeBSD IA64 5.3/RELEASE on Compaq DL590. (boot error)
Message-ID:  <BE30686C.CC8B%m@telerama.com>
In-Reply-To: <20050209.J7W.64424800@JRwlocal>

next in thread | previous in thread | raw e-mail | index | archive | help
> From: m <mark@compitsolutions.com>
> Date: Wed, 09 Feb 2005 20:42:46 -0500
> To: Marcel Moolenaar <marcel@xcllnt.net>
> Cc: <freebsd-ia64@freebsd.org>
> 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: <ACPI PCI bus> on pcib6
>>> ida0: <Compaq Integrated Array controller> 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.

If anyone would like remote desktop access to a machine with a console on
this machine to work, I'll set it up.

Mark.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BE30686C.CC8B%m>