Ah, one more thing just to hopefully prove I'm not totally crazy. Here is
output from the CentOS 7 install with the kmod module running:
Here is the SATA controller info showing it is using the "sata_via" kernel
driver (lspci -v -nn):
00:0f.0 IDE interface [0101]: VIA Technologies, Inc. VT8251 Serial ATA
Controller [1106:5287] (rev 20) (prog-if 8f [PCI native mode controller,
supports both channels switched to ISA compatibility mode, supports bus
mastering])
Subsystem: VIA Technologies, Inc. Device [1106:3349]
Flags: bus master, medium devsel, latency 32, IRQ 21
I/O ports at fc00 [size=8]
I/O ports at f800 [size=4]
I/O ports at f400 [size=8]
I/O ports at f000 [size=4]
I/O ports at ec00 [size=16]
Memory at dffff000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [c0] Power Management version 2
Kernel driver in use: sata_via
Kernel modules: pata_acpi, ata_generic, sata_via
Using the kmod module:
# modinfo sata_via
filename:
/lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/sata_via.ko.xz
version: 2.6
license: GPL
description: SCSI low-level driver for VIA SATA controllers
author: Jeff Garzik
retpoline: Y
rhelversion: 7.9
srcversion: D02B8C752BDC9941B11FCCB
alias: pci:v00001106d00009000sv*sd*bc*sc*i*
alias: pci:v00001106d00005287sv*sd*bc*sc*i*
alias: pci:v00001106d00007372sv*sd*bc*sc*i*
alias: pci:v00001106d00005372sv*sd*bc*sc*i*
alias: pci:v00001106d00003249sv*sd*bc*sc*i*
alias: pci:v00001106d00003149sv*sd*bc*sc*i*
alias: pci:v00001106d00000591sv*sd*bc*sc*i*
alias: pci:v00001106d00005337sv*sd*bc*sc*i*
depends: libata
vermagic: 3.10.0-1160.el7.x86_64 SMP mod_unload modversions
signer: The ELRepo Project (http://elrepo.org): ELRepo.org Secure
Boot Key
sig_key: F3:65:AD:34:81:A7:B2:0E:34:27:B6:1B:2A:26:63:5B:83:FE:42:7B
sig_hashalgo: sha256
parm: vt6420_hotplug:Enable hot-plug support for VT6420 (0=Don't
support, 1=support) (int)
And testing the read/write speed:
# hdparm -Tt /dev/sdb
/dev/sdb:
Timing cached reads: 990 MB in 2.00 seconds = 494.89 MB/sec
Timing buffered disk reads: 328 MB in 3.02 seconds = 108.75 MB/sec
So weird!
On Wed, Jul 21, 2021 at 1:16 PM Tristan Evans <azurepanc...@gmail.com>
wrote:
> Thanks so much everyone for not only creating the kmod that fixes my
> issue, but also for the suggestions on handing it during installation.
>
> Phil, that makes a lot of sense regarding using `inst.dd` and the
> conflicting modules. I do wonder though.. These installations are to be
> automated using a kickstart script, so I wonder if in the "pre" section
> (before any storage settings are applied and installation begins) it can do
> some finagling to unload the intree module and replace it with the kmod..
> Not sure if that is better/worse than just using a custom kernel image, but
> it got me thinking.
>
> To do some testing, I booted into the CentOS installer media and started
> trying some things:
>
> Extracted the RPM:
>
> rpm2cpio ./kmod-sata_via-2.6-1.el7_9.elrepo.x86_64.rpm | cpio -idmv
> ./etc/depmod.d/kmod-sata_via.conf
> ./lib/modules/3.10.0-1160.el7.x86_64
> ./lib/modules/3.10.0-1160.el7.x86_64/extra
> ./lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via
> ./lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/sata_via.ko.xz
> ./usr/share/doc/kmod-sata_via-2.6
> ./usr/share/doc/kmod-sata_via-2.6/GPL-v2.0.txt
>
> I copied the files to their specific locations:
>
> cp ./etc/depmod.d/kmod-sata_via.conf /etc/depmod.d/
> cp ./lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/sata_via.ko.xz
> /lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/
>
> Note that I made a quick update to "kmod-sata_via.conf". It seems it was
> configured to look into "weak-updates/sata_via", but the RPM would install
> the module to "extra/sata_via".
>
> I then ran `depmod -a` and now it seems the OS recognizes the kmod
> sata_via driver:
>
> [anaconda root@unknown001a6443e48f sata_via]# modinfo sata_via
> filename:
> /lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/sata_via.ko.xz
> version: 2.6
> license: GPL
> description: SCSI low-level driver for VIA SATA controllers
> author: Jeff Garzik
> retpoline: Y
> rhelversion: 7.9
> srcversion: D02B8C752BDC9941B11FCCB
> alias: pci:v00001106d00009000sv*sd*bc*sc*i*
> alias: pci:v00001106d00005287sv*sd*bc*sc*i*
> alias: pci:v00001106d00007372sv*sd*bc*sc*i*
> alias: pci:v00001106d00005372sv*sd*bc*sc*i*
> alias: pci:v00001106d00003249sv*sd*bc*sc*i*
> alias: pci:v00001106d00003149sv*sd*bc*sc*i*
> alias: pci:v00001106d00000591sv*sd*bc*sc*i*
> alias: pci:v00001106d00005337sv*sd*bc*sc*i*
> depends: libata
> vermagic: 3.10.0-1160.el7.x86_64 SMP mod_unload modversions
> signer: The ELRepo Project (http://elrepo.org): ELRepo.org Secure
> Boot Key
> sig_key: F3:65:AD:34:81:A7:B2:0E:34:27:B6:1B:2A:26:63:5B:83:FE:42:7B
> sig_hashalgo: sha256
> parm: vt6420_hotplug:Enable hot-plug support for VT6420 (0=Don't
> support, 1=support) (int)
>
> So I then load the module (notice it does indeed appear to be finding the
> kmod module):
>
> [anaconda root@unknown001a6443e48f 3.10.0-1160.el7.x86_64]# modprobe -v
> sata_via
> insmod /lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/sata_via.ko.xz
>
> But to my surprise, the disk speed test is behaving like I'm still using
> the old module!
>
> [anaconda root@unknown001a6443e48f 3.10.0-1160.el7.x86_64]# hdparm -Tt
> /dev/sdc
>
> /dev/sdc:
> Timing cached reads: 2 MB in 6.39 seconds = 320.27 kB/sec
> Timing buffered disk reads: 4 MB in 3.09 seconds = 1.30 MB/sec
>
> I'm so confused. I swear that it works great when installed by the RPM in
> the installed OS. Am I maybe overlooking something here?
>
> I do like the idea of just patching the kernel. My only challenge with
> that is I will ultimately be PXE booting these systems into the installer
> environment with Foreman and I believe it kind of obfuscates the boot
> kernel somewhere not easily accessed. Though maybe I can somehow work
> around that using the `stage2` parameter per Wolfy's suggestion.
>
> I know I am probably going beyond what this community generally supports
> here and I totally understand if we're hitting that wall by the way. I will
> continue chipping away at this, but if anyone has any
> suggestions/tips/tricks, I would love 'em!
>
> Thanks,
> Tristan
>
>
> On Tue, Jul 20, 2021 at 7:18 PM Manuel Wolfshant <wo...@nobugconsulting.ro>
> wrote:
>
>> On 7/21/21 1:58 AM, Phil Perry wrote:
>> > Hi Tristan,
>> >
>> > That's great news, problem half solved!
>> >
>> > Gmail decided to reject my off list email to you as it didn't like the
>> > binary attachments, hence you never received it.
>> >
>> > We have published the script we use to make our ISO images here:
>> >
>> > https://github.com/elrepo/elrepo-scripts/blob/master/mkdd.sh
>> >
>> > Just place the RPM and SRPM in the same directory, and run the script:
>> >
>> > ./mkdd.sh kmod-foo-version-release.el7.elrepo.x86_64.rpm
>> >
>> > which will create the ISO image for you, which you can then dd to a
>> > usb drive.
>> >
>> > Regarding the installation, I've only ever used the `inst.dd` method
>> > when installing a driver for unsupported hardware. I think the issue
>> > here is that the hardware *is* supported by the (buggy) kernel driver.
>> > When the kmod driver is _replacing_ (updating) an existing kernel
>> > driver, we use an /etc/depmod.d/kmod-sata_via.conf file to tell depmod
>> > to override the in-kernel driver with our updated kmod driver. I
>> > suspect that override process isn't working during the installation
>> > hence the installer is using the existing kernel driver.
>> >
>> > In terms of a solution, if the `inst.dd` method isn't working, I think
>> > you would need to create custom CentOS installation media with a
>> > patched kernel. It's simple enough to patch the kernel source code to
>> > backport the sata_via driver as per our kmod, but I have no idea how
>> > to then go about creating custom installation media with the patched
>> > kernel.
>> >
>>
>> One can use the inst.stage2 anaconda parameter to load a different
>> kernel. That's what I used when I was testing a debug kernel provided by
>> RH when I found a bug in an SSD driver.
>>
>>
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/chap-anaconda-boot-options
>>
>>
>> wolfy
>>
>> _______________________________________________
>> elrepo mailing list
>> elrepo@lists.elrepo.org
>> http://lists.elrepo.org/mailman/listinfo/elrepo
>>
>
_______________________________________________
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo
