wrt amd64-elf.hpt37xx_lib.o.uu, I'd like us to stop uuencoding objects, they can just be committed directly.

We have a number of binary files in the tree already, some representative examples:

stand/efi/boot1/fat-amd64.tmpl.xz
contrib/unbound/contrib/unbound_cacti.tar.gz
contrib/binutils/ld/emultempl/spu_ovl.o
tests/sys/cddl/zfs/tests/cli_root/zpool_import/blockfiles/unclean_export.dat.bz2

It appears this is not connected in sys/modules?

Have a HighPoint 2840a that uses that uses this driver. How could I test this out?

In D15307#402094, @jrmoede_gmail.com wrote:

Have a HighPoint 2840a that uses that uses this driver. How could I test this out?

I could do a build that has the driver and put it on freefall so you could grab it and test it. Do you have amd64 hardware I assume?

In D15307#406125, @jpaetzel wrote:

In D15307#402094, @jrmoede_gmail.com wrote:

Have a HighPoint 2840a that uses that uses this driver. How could I test this out?

I could do a build that has the driver and put it on freefall so you could grab it and test it. Do you have amd64 hardware I assume?

I contacted HighPoint and they are going to do a driver for me to install. Think that will be the route I will go for now.

IMO uuencoding objects is an artifact of when we had a less capable VCS; we have binary files in the tree already and so it should be fine to skip the uuencode.

One user asked me why this driver never hit src tree. Were there any serious issues with the driver?

Note there's a slightly newer driver from HighPoint.

https://www.highpoint-tech.com/BIOS_Driver/RR3740A_840A/FreeBSD/hpt37xx_FreeBSD_Src_v1.0.4.2_19_07_23.tgz

In D15307#663960, @jkim wrote:

One user asked me why this driver never hit src tree. Were there any serious issues with the driver?

Note there's a slightly newer driver from HighPoint.

https://www.highpoint-tech.com/BIOS_Driver/RR3740A_840A/FreeBSD/hpt37xx_FreeBSD_Src_v1.0.4.2_19_07_23.tgz

I don't have a card to test with. That, coupled with the binary blob makes me less inclined to spend time on it.
However, I'll pull this in and make sure we don't lose markj's changes in this area.

But I'd like reports of it working after the commit to feel happiest.

In D15307#664358, @imp wrote:

But I'd like reports of it working after the commit to feel happiest.

I'll make sure about that. Thanks!

In D15307#664721, @jkim wrote:

In D15307#664358, @imp wrote:

But I'd like reports of it working after the commit to feel happiest.

I'll make sure about that. Thanks!

Great! Thanks. There's a hptiop that's billed as supporting all 3xxx/4xxx hpt cards, but the man page doesn't list 37xx cards. Do you know if the cards this driver supports are also supported by that one?

In D15307#666805, @imp wrote:

In D15307#664721, @jkim wrote:

In D15307#664358, @imp wrote:

But I'd like reports of it working after the commit to feel happiest.

I'll make sure about that. Thanks!

Great! Thanks. There's a hptiop that's billed as supporting all 3xxx/4xxx hpt cards, but the man page doesn't list 37xx cards. Do you know if the cards this driver supports are also supported by that one?

The user reported hptiop does not support the card. FYI, PCI device ID is 0x3742 and not listed in hptiop_probe().

The user gave me access to his box to test the latest driver from the website. Good news is it works very well. Unfortunately, kldload hpt37xx panics kernel. I see it panics in hpt_match() but I cannot trace it any further because the problem is somewhere in the binary blob. When it is compiled in kernel or loaded from loader(8), everything looks normal. What should we do now?

BTW, I found there is PR236371.