<div dir="ltr"><div>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:</div><div><br></div><div>Here is the SATA controller info showing it is using the "sata_via" kernel driver (lspci -v -nn):</div><div><br></div><div>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])<br> Subsystem: VIA Technologies, Inc. Device [1106:3349]<br> Flags: bus master, medium devsel, latency 32, IRQ 21<br> I/O ports at fc00 [size=8]<br> I/O ports at f800 [size=4]<br> I/O ports at f400 [size=8]<br> I/O ports at f000 [size=4]<br> I/O ports at ec00 [size=16]<br> Memory at dffff000 (32-bit, non-prefetchable) [size=1K]<br> Capabilities: [c0] Power Management version 2<br> Kernel driver in use: sata_via<br> Kernel modules: pata_acpi, ata_generic, sata_via<br></div><div><br></div><div>Using the kmod module:<br></div><div><br></div><div># modinfo sata_via<br>filename: /lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/sata_via.ko.xz<br>version: 2.6<br>license: GPL<br>description: SCSI low-level driver for VIA SATA controllers<br>author: Jeff Garzik<br>retpoline: Y<br>rhelversion: 7.9<br>srcversion: D02B8C752BDC9941B11FCCB<br>alias: pci:v00001106d00009000sv*sd*bc*sc*i*<br>alias: pci:v00001106d00005287sv*sd*bc*sc*i*<br>alias: pci:v00001106d00007372sv*sd*bc*sc*i*<br>alias: pci:v00001106d00005372sv*sd*bc*sc*i*<br>alias: pci:v00001106d00003249sv*sd*bc*sc*i*<br>alias: pci:v00001106d00003149sv*sd*bc*sc*i*<br>alias: pci:v00001106d00000591sv*sd*bc*sc*i*<br>alias: pci:v00001106d00005337sv*sd*bc*sc*i*<br>depends: libata<br>vermagic: 3.10.0-1160.el7.x86_64 SMP mod_unload modversions<br>signer: The ELRepo Project (<a href="http://elrepo.org">http://elrepo.org</a>): ELRepo.org Secure Boot Key<br>sig_key: F3:65:AD:34:81:A7:B2:0E:34:27:B6:1B:2A:26:63:5B:83:FE:42:7B<br>sig_hashalgo: sha256<br>parm: vt6420_hotplug:Enable hot-plug support for VT6420 (0=Don't support, 1=support) (int)</div><div><br></div><div>And testing the read/write speed:</div><div><br></div><div># hdparm -Tt /dev/sdb<br><br>/dev/sdb:<br> Timing cached reads: 990 MB in 2.00 seconds = 494.89 MB/sec<br> Timing buffered disk reads: 328 MB in 3.02 seconds = 108.75 MB/sec</div><div><br></div><div>So weird!<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 21, 2021 at 1:16 PM Tristan Evans <<a href="mailto:azurepancake@gmail.com">azurepancake@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks so much everyone for not only creating the kmod that fixes my issue, but also for the suggestions on handing it during installation.<div><br></div><div>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.<br></div><div><br></div><div>To do some testing, I booted into the CentOS installer media and started trying some things:</div><div><br></div><div>Extracted the RPM:</div><div><br></div><div>rpm2cpio ./kmod-sata_via-2.6-1.el7_9.elrepo.x86_64.rpm | cpio -idmv<br>./etc/depmod.d/kmod-sata_via.conf<br>./lib/modules/3.10.0-1160.el7.x86_64<br>./lib/modules/3.10.0-1160.el7.x86_64/extra<br>./lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via<br>./lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/sata_via.ko.xz<br>./usr/share/doc/kmod-sata_via-2.6<br>./usr/share/doc/kmod-sata_via-2.6/GPL-v2.0.txt</div><div><br></div><div>I copied the files to their specific locations:</div><div><br></div><div>cp ./etc/depmod.d/kmod-sata_via.conf /etc/depmod.d/</div><div>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/</div><div><br></div><div>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".</div><div><br></div><div>I then ran `depmod -a` and now it seems the OS recognizes the kmod sata_via driver:</div><div><br></div><div>[anaconda root@unknown001a6443e48f sata_via]# modinfo sata_via<br>filename: /lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/sata_via.ko.xz<br>version: 2.6<br>license: GPL<br>description: SCSI low-level driver for VIA SATA controllers<br>author: Jeff Garzik<br>retpoline: Y<br>rhelversion: 7.9<br>srcversion: D02B8C752BDC9941B11FCCB<br>alias: pci:v00001106d00009000sv*sd*bc*sc*i*<br>alias: pci:v00001106d00005287sv*sd*bc*sc*i*<br>alias: pci:v00001106d00007372sv*sd*bc*sc*i*<br>alias: pci:v00001106d00005372sv*sd*bc*sc*i*<br>alias: pci:v00001106d00003249sv*sd*bc*sc*i*<br>alias: pci:v00001106d00003149sv*sd*bc*sc*i*<br>alias: pci:v00001106d00000591sv*sd*bc*sc*i*<br>alias: pci:v00001106d00005337sv*sd*bc*sc*i*<br>depends: libata<br>vermagic: 3.10.0-1160.el7.x86_64 SMP mod_unload modversions<br>signer: The ELRepo Project (<a href="http://elrepo.org" target="_blank">http://elrepo.org</a>): ELRepo.org Secure Boot Key<br>sig_key: F3:65:AD:34:81:A7:B2:0E:34:27:B6:1B:2A:26:63:5B:83:FE:42:7B<br>sig_hashalgo: sha256<br>parm: vt6420_hotplug:Enable hot-plug support for VT6420 (0=Don't support, 1=support) (int)</div><div><br></div><div>So I then load the module (notice it does indeed appear to be finding the kmod module):</div><div><br></div><div>[anaconda root@unknown001a6443e48f 3.10.0-1160.el7.x86_64]# modprobe -v sata_via<br>insmod /lib/modules/3.10.0-1160.el7.x86_64/extra/sata_via/sata_via.ko.xz<br></div><div><br></div><div>But to my surprise, the disk speed test is behaving like I'm still using the old module!</div><div><br></div><div>[anaconda root@unknown001a6443e48f 3.10.0-1160.el7.x86_64]# hdparm -Tt /dev/sdc<br><br>/dev/sdc:<br> Timing cached reads: 2 MB in 6.39 seconds = 320.27 kB/sec<br> Timing buffered disk reads: 4 MB in 3.09 seconds = 1.30 MB/sec</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>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!</div><div><br></div><div>Thanks,</div><div>Tristan<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 20, 2021 at 7:18 PM Manuel Wolfshant <<a href="mailto:wolfy@nobugconsulting.ro" target="_blank">wolfy@nobugconsulting.ro</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 7/21/21 1:58 AM, Phil Perry wrote:<br>
> Hi Tristan,<br>
><br>
> That's great news, problem half solved!<br>
><br>
> Gmail decided to reject my off list email to you as it didn't like the <br>
> binary attachments, hence you never received it.<br>
><br>
> We have published the script we use to make our ISO images here:<br>
><br>
> <a href="https://github.com/elrepo/elrepo-scripts/blob/master/mkdd.sh" rel="noreferrer" target="_blank">https://github.com/elrepo/elrepo-scripts/blob/master/mkdd.sh</a><br>
><br>
> Just place the RPM and SRPM in the same directory, and run the script:<br>
><br>
> ./mkdd.sh kmod-foo-version-release.el7.elrepo.x86_64.rpm<br>
><br>
> which will create the ISO image for you, which you can then dd to a <br>
> usb drive.<br>
><br>
> Regarding the installation, I've only ever used the `inst.dd` method <br>
> when installing a driver for unsupported hardware. I think the issue <br>
> here is that the hardware *is* supported by the (buggy) kernel driver. <br>
> When the kmod driver is _replacing_ (updating) an existing kernel <br>
> driver, we use an /etc/depmod.d/kmod-sata_via.conf file to tell depmod <br>
> to override the in-kernel driver with our updated kmod driver. I <br>
> suspect that override process isn't working during the installation <br>
> hence the installer is using the existing kernel driver.<br>
><br>
> In terms of a solution, if the `inst.dd` method isn't working, I think <br>
> you would need to create custom CentOS installation media with a <br>
> patched kernel. It's simple enough to patch the kernel source code to <br>
> backport the sata_via driver as per our kmod, but I have no idea how <br>
> to then go about creating custom installation media with the patched <br>
> kernel.<br>
><br>
<br>
One can use the inst.stage2 anaconda parameter to load a different <br>
kernel. That's what I used when I was testing a debug kernel provided by <br>
RH when I found a bug in an SSD driver.<br>
<br>
<a href="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/chap-anaconda-boot-options" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/chap-anaconda-boot-options</a><br>
<br>
<br>
wolfy<br>
<br>
_______________________________________________<br>
elrepo mailing list<br>
<a href="mailto:elrepo@lists.elrepo.org" target="_blank">elrepo@lists.elrepo.org</a><br>
<a href="http://lists.elrepo.org/mailman/listinfo/elrepo" rel="noreferrer" target="_blank">http://lists.elrepo.org/mailman/listinfo/elrepo</a><br>
</blockquote></div>
</blockquote></div>