On Fri, Aug 05, 2022 at 07:46:41PM -0700, Michael Truog wrote:
> On 7/31/22 00:00, Klemens Nanni wrote:
> > On Sat, Jul 30, 2022 at 06:58:21PM -0700, Michael Truog wrote:
> > > I previously sent an email regarding the Areca ARC-1880 on sparc64.
> > > I also have an Areca ARC-1222i 8 Port PCIe RAID card which
> > This one is indeed listed as supported card.
>
> I focused on the Areca ARC-1222i 8 Port card and returned the Areca ARC-1880
> card. If someone wants the Areca ARC-1222 card as a donation, just tell me
> where to send it. I am unable to return it and I am likely not able to use
> it without support.
You could build a ramdisk kernel with ARC_DEBUG and see if that provides
more insight as to where/when exactly it goes wrong.
> > A /sys/dev/pci/pcidevs entry could be incorrect or missing.
> > Please see my previous reply about getting PCI IDs and check.
>
> The install CD didn't have pcidump(8) and /sys/dev/pci/pcidevs didn't appear
> to be accessible.
pcidump(8) is available in multi-user for which you need to boot with
arc(4) disabled as explained earlier. To recap:
1. boot the installer into configure mode, see boot_config(8):
{ok} boot cdrom /bsd -c
2. disable arc and continue boot:
UKC> disable arc
UKC> exit
3. proceed install
4. boot new install, again with arc disabled to avoid crash:
{ok} boot disk /bsd -c
UKC> disable arc
UKC> exit
This should let you use OpenBSD as usual on this hardware except for the
RAID controller until the driver is fixed. To persistently disable it,
put "disable arc" into bsd.re-config(5).
Then, to see why your ARC-1222 is detected as ARC-1680, you can
5. check PCI vendor/device IDs for the plugged in but unused card
against the pcidevs file[0] (which provides the strings in dmesg):
# pcidump -v
0: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/pcidevs
>
> The ILOM "-> ls -level all /System/PCI_Devices/Add-on" didn't work with my
> version of ILOM. I am not sure why. I have always been doing
> show/set/reset with /SP or /SYS paths. The /SYS/MB/RISERX/PCIEY path didn't
> provide any information.
I don't have access to a T5220 system, the provided command works on a
T4-2 system.
>
> > > Are Areca cards not meant to work on sparc64?
> > > Tell me if you need more information.
> > You could try earlier OpenBSD releases to see if this is a regression.
> I was able to determine that the first install CD to have a kernel panic
> with the Areca ARC-1222 on sparc64 was OpenBSD 5.5 . The OpenBSD 5.4
> install CD was able to boot without any problems. The OpenBSD 5.5 boot log
> is below the email contents, though it looks like the same panic.
So something in sys/dev/pci/arc.c after/excluding revision 1.96 aka.
OPENBSD_5_4_BASE and up to/including 1.101 aka. OPENBSD_5.5.101 could
have introduced this regression (I did not yet go through this):
$ cvs log -N -r 1.97:1.101 /usr/src/sys/dev/pci/arc.c
RCS file: /cvs/src/sys/dev/pci/arc.c,v
Working file: /usr/src/sys/dev/pci/arc.c
head: 1.123
branch:
locks: strict
access list:
keyword substitution: kv
total revisions: 124; selected revisions: 5
description:
----------------------------
revision 1.101
date: 2014/02/08 16:02:42; author: chris; state: Exp; lines: +2 -2;
Be conservative about the resources the controller advertises for
"type D" Marvel 9580. From Ching Huang, Areca.
ok dlg@
----------------------------
revision 1.100
date: 2014/02/08 15:58:01; author: chris; state: Exp; lines: +2 -6;
Stop disablng/enabling interrupts in the interrupt handler for
"chip type D" which is Marvell 9580. None of the other types do
this and OpenBSD doesn't interrupt during the interrupt routine
anyways. From Ching Huang, Areca.
ok dlg@
----------------------------
revision 1.99
date: 2014/01/24 02:47:12; author: dlg; state: Exp; lines: +2 -2;
DVA should be 64 bits, so make sure it is before getting the high bits.
the DVA macro should cast, but i am wary of the effects on all uses of
it,
so fixing it in the one place that needs it.
fixes compiles on i386
----------------------------
revision 1.98
date: 2014/01/23 23:47:37; author: chris; state: Exp; lines: +1300
-285;
Manufacturer driver update for ARC-1880, 1882, 1213, 1223, 1214
Tested on a variety of Intel-IOP cards
ok dlg@ henning@ "i'll ok to get this unstuck"
----------------------------
revision 1.97
date: 2013/12/06 21:03:03; author: deraadt; state: Exp; lines: +6
-12;
Add a DVACT_WAKEUP op to the *_activate() API. This is called after the
kernel resumes normal (non-cold, able to run processes, etc) operation.
Previously we were relying on specific DVACT_RESUME op's in drivers
creating callback/threads themselves, but that has become too common,
indicating the need for a built-in mechanism.
ok dlg kettenis, tested by a sufficient amount of people
=============================================================================
