Re: [elrepo] centos 7 e1000e kmod loading kernel version

[Nick Howitt]

On 21/09/2021 17:27, Steve Cleveland wrote:

I've done some searching, but haven't found anything on this topic yet.

I have a newer workstation with the Intel I219-LM network controller. 
The included Intel driver does not support it. I found the elrepo DUD 
package that includes the current e1000e module.  Used that to get the 
nic working for the kickstart install.


But now when the OS loads, it keeps loading the system default version 
of the module.


[64.707908] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k

# modinfo e1000e
filename: 
/lib/modules/3.10.0-1168.42.2.el7.x86_64/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko.xz 


version: 3.2.6k

The kmod-e1000e package is installed:

# rpm -q kmod-e1000e
kmod-e1000e-3.8.4-3.el7_9.elrepo.x86_64

/etc/depmod.d/kmod-e1000e.conf is in place and looks right.

What am I missing?  This is my first time needing to use a kmod package 
replacing a system driver, so I may be missing a step.


Thanks,

  - Steve


Have you rebooted to have the new driver take effect?

Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] Demise of Centos 8 (as we know it today) plans...

[Nick Howitt]

  
  
On 18/01/2021 20:43, Phil Perry wrote:

  
  On 18/01/2021 18:18, neil watson wrote:
  
  Hi


Firstly thanks for all the work you do to support older kit (eg
older Dell RAID controllers!)


I've had a look through the archive and can't spot any comments
on the widely reported discontinuation of Centos 8 from the end
of the year...


I really hope that ElRepo will continue to support Centos-8-type
releases are that built to fill the gap - I know there are some
in the pipeline - as I can believe that, like Centos, other RHEL
derived distributions still won't have the "older" drivers that
ElRepo provides


Maybe there's a place for a notice on the website / Blog
explaining what you are planning?


Regards


Neil.


  
  
  Hi Neil,
  
  
  Thank you for your kind words!
  
  
  We are still in the phase of trying to figure out what these
  changes mean for us and how they will impact ELRepo users.
  
  
  ELRepo has always taken the stance that we support RHEL, and by
  extention that includes all RHEL compatible clones. Traditionally,
  this has included distributions such as CentOS and Scientific
  Linux (and any new clones assuming they retain compatibility),
  whilst other distributions such as ClearOS, although based on
  RHEL, make modifications to their kernel which renders many of our
  packages incompatible. This highlights just how important binary
  compatibility of the kernel is for ELRepo packages/users.
  
  
  Red Hat have chosen to discontinue CentOS Linux 8 at the end of
  2021. Red Hat have proposed CentOS Stream as it's replacement in
  many environments. Unfortunately for us, CentOS Stream, now being
  upstream of conventional RHEL releases, gets changes to the kernel
  which are scheduled for the next RHEL minor point release (their
  kernels diverge). These changes often break kernel ABI (kABI)
  compatibility and may cause ELRepo packages to no longer work.
  
  
  At present, kernel releases to Stream are relatively few (maybe
  once per month) but the intention is for them to significantly
  increase to maybe weekly and potentially even daily. The kmod
  standard that ELRepo uses to package and deliver drivers for RHEL
  is totally dependent on the stable kABI that RHEL affords.
  
  
  So what does this mean for ELRepo users in practice? Well,
  preliminary testing of the first kernel update to EL8.3 in CentOS
  Stream indicates that 13 out of 44 kmod packages tested were
  broken by the kernel update. I have not bothered testing the
  second updateas it's only going to get worse. It is simply not
  possible (for ELRepo) to deliver kmod packages against a
  constantly moving target such as the CentOS Stream kernel, and
  even if we could, these newly fixed packages would likely no
  longer be compatible with RHEL. We would be looking at a whole new
  repository or project for ELRepo-Stream and we do not have the
  resources to do that.
  
  
  ELRepo will continue to support RHEL and compatible clones.
  Unfortunately it does not look like CentOS Stream falls into that
  category at present. I have suggested that CentOS make the
  conventional RHEL kernels available in Stream alongside the newer
  Stream kernels for those who need that kABI stability and others
  have proposed other solutions. People who need that kABI
  compatibility also have the option of rebuilding the RHEL kernel
  for themselves for use on Stream. But for now, ELRepo are unable
  to officially support CentOS Stream kernels. In reality your
  package may continue to work but if/when it breaks, we will not be
  able to officially support it. Hopefully CentOS will be able to
  offer a solution that allows ELRepo packages to continue to work
  on CentOS Stream.
  
  
  ELRepo also offers kernel-ml and kernel-lt packages for EL8 and
  these can be used on CentOS-Stream to provide a conveniently
  packaged modern kernel (mainline or LTS) with native support for
  the legacy hardware Red Hat removed. These newer kernels may
  provide a convenient solution for some users whose hardware is not
  natively supported on CentOS Stream.
  
  
  Phil
  

Interesting reading. The new Centos stream really puts a spanner in
the works.

Can I please make a slight correction? Since about ClearOS 7.7,
ClearOS reverted to the upstream kernel unmodified so the ElRepo
packages are now normally directly installable. The only one I
compile differently is 

Re: [elrepo] RTL8125 driver for EL7

[Nick Howitt]

On 11/08/2020 20:09, Phil Perry wrote:


On 11/08/2020 19:32, Akemi Yagi wrote:

On Tue, Aug 11, 2020 at 10:59 AM Manuel Wolfshant
 wrote:


On 8/11/20 8:14 PM, Akemi Yagi wrote:

On Mon, Aug 10, 2020 at 2:58 PM Guidroz, Bryan
 wrote:

Greetings,

I'm not very familiar with how exactly this works, but I was 
pointed in this direction and am hoping someone can help me out.


I'm wanting to use ClearOS (https://www.clearos.com/) on an 
Odroid-H2+ (https://www.hardkernel.com/shop/odroid-h2plus/).
This SBC has dual Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE 
Ethernet adapters onboard.
ClearOS is a CentOS 7 derivative and does not currently include 
the R8125 driver.
I have compiled the driver on Fedora 32 and CentOS 8 and had no 
issues or errors.
I've been using this as my daily workstation (Fedora 32 with 
compiled driver) for about a week and everything has worked fine.


To compile the driver, I followed the instructions here: 
https://wiki.odroid.com/odroid-h2/hardware/install_ethernet_driver_on_h2plus


Using the the driver here: 
https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-pci-express-software


I'm not sure if you need any additional info, but I've included 
basic info below.

Thanks for any help you can provide.

Bryan

I'm not sure if I understood the situation. You need to build the
r8125 driver. It went fine with Fedora-32 and CentOS-8. But it failed
with ClearOS-7 and that's what you want to achieve?



I think that the idea was to provide the driver for RTL8125 via ElRepo
because stock kernel for RHEL 7 does not include it.


wolfy


OK, we could try it. One potential issue is that the ClearOS kernel is
not 100% binary compatible with RHEL. So the package will have to be
rebuilt for ClearOS.

Akemi


We have built a kmod-r8125 package and released it to the main elrepo 
repository. Packages are syncing to the mirrors and should be 
available shortly:


kmod-r8125-9.003.05-1.el7_8.elrepo.x86_64.rpm
r8125-kmod-9.003.05-1.el7_8.elrepo.src.rpm

Please would you test and let us know how you get on.

Thanks,

Phil

I'm a bit late to this thread but ClearOS uses an untouched kernel from 
Centos so it looks like a vanilla EL7 kernel


NIck

___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] Error installing kmod-rtl8812au-5.3.4-2.el7_8

[Nick Howitt]

  
  


On 10/06/2020 19:43, Phil Perry wrote:

On
  10/06/2020 16:35, Nick Howitt wrote:
  
  Hi Gents,

Thanks for all the great work you do. I've just updated a
machine to 7.8 and the drivers were there waiting.


One thing that has popped up is a depmod error on install:


    depmod: ERROR: fstatat(9, 88XXau.ko.xz): No such file or
directory


  
  
  Errors are never good. Something seems to have gone awry on your
  installation.
  
  
  

Looking for the file I get:


    [root@oldserver-h ~]# updatedb && locate
88XXau.ko.xz

   
/usr/lib/modules/3.10.0-1062.18.1.el7.x86_64/weak-updates/lib/modules/3.10.0-1062.1.1.el7.x86_64/weak-updates/lib/modules/3.10.0-1062.el7.x86_64/extra/rtl8812au/88XXau.ko.xz

   
/usr/lib/modules/3.10.0-1062.4.3.el7.x86_64/weak-updates/lib/modules/3.10.0-1062.el7.x86_64/extra/rtl8812au/88XXau.ko.xz

   
/usr/lib/modules/3.10.0-1062.9.1.el7.x86_64/weak-updates/lib/modules/3.10.0-1062.el7.x86_64/extra/rtl8812au/88XXau.ko.xz

    
  
  The above lines should not be there. The new version 5.3.4-2.el7_8
  package is only compatible with el7.8 - it is not backward
  compatible with el7.7 series kernels.
  
  
  /usr/lib/modules/3.10.0-1127.10.1.el7.x86_64/weak-updates/rtl8812au/88XXau.ko.xz

   
/usr/lib/modules/3.10.0-1127.8.2.el7.x86_64/weak-updates/rtl8812au/88XXau.ko.xz

   
/usr/lib/modules/3.10.0-1127.el7.x86_64/extra/rtl8812au/88XXau.ko.xz



It seems that the module is going in a different location, but I
have to admit the old location looks a whacky!


The modules do appear to be loading.


  
  
  I would suggest you uninstall the kmod package and try
  reinstalling it, hopefully that succeeds without depmod errors and
  the above references to 3.10.0-1062 series kernels are gone. Also
  try running 'depmod -a', again hopefully without error.
  
  
  Let us know if that doesn't fix things.
  
  

It looks like I had more issues. I had to run
yum-complete-transactions. Then I noticed both kmod-zd1211rw 1.0.7
and 1.0.8 were installed (I updated that at the same time as the
88XXau), so I ended up removing both the zd1211rw versions and the
88XXau and reinstalling them. They have installed cleanly.

The stupid path against the 1062 kernel is still there
(/usr/lib/modules/3.10.0-1062.18.1.el7.x86_64/weak-updates/lib/modules/3.10.0-1062.1.1.el7.x86_64/weak-updates/lib/modules/3.10.0-1062.el7.x86_64/extra/rtl8812au)
but the symlink at the end is broken (as you'd expect) so I'll
manually remove the path.

Nick
  


___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

[elrepo] Error installing kmod-rtl8812au-5.3.4-2.el7_8

[Nick Howitt]

Hi Gents,
Thanks for all the great work you do. I've just updated a machine to 7.8 
and the drivers were there waiting.


One thing that has popped up is a depmod error on install:

   depmod: ERROR: fstatat(9, 88XXau.ko.xz): No such file or directory


Looking for the file I get:

   [root@oldserver-h ~]# updatedb && locate 88XXau.ko.xz
   
/usr/lib/modules/3.10.0-1062.18.1.el7.x86_64/weak-updates/lib/modules/3.10.0-1062.1.1.el7.x86_64/weak-updates/lib/modules/3.10.0-1062.el7.x86_64/extra/rtl8812au/88XXau.ko.xz
   
/usr/lib/modules/3.10.0-1062.4.3.el7.x86_64/weak-updates/lib/modules/3.10.0-1062.el7.x86_64/extra/rtl8812au/88XXau.ko.xz
   
/usr/lib/modules/3.10.0-1062.9.1.el7.x86_64/weak-updates/lib/modules/3.10.0-1062.el7.x86_64/extra/rtl8812au/88XXau.ko.xz
   
/usr/lib/modules/3.10.0-1127.10.1.el7.x86_64/weak-updates/rtl8812au/88XXau.ko.xz
   
/usr/lib/modules/3.10.0-1127.8.2.el7.x86_64/weak-updates/rtl8812au/88XXau.ko.xz
   /usr/lib/modules/3.10.0-1127.el7.x86_64/extra/rtl8812au/88XXau.ko.xz


It seems that the module is going in a different location, but I have to 
admit the old location looks a whacky!


The modules do appear to be loading.

Regards,

Nick

___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

[elrepo] Driver for rtl8812au, please?

[Nick Howitt]

  
  
Hi Gents,

I've been trying to find this for a while now and I've had some help
to find a good source. Using
https://github.com/cccooo/rtl8812au-centos-7.6.git and changing the
Makefile, line 220 to "ifeq ($(REDHAT_VER), 7.7)", the module
compiles cleanly and creates an 88XXau.ko module. I assume it would
have compiled cleanly directly with Centos 7.6.

Is there any chance of producing a kmod compatible version?

Many thanks,

Nick
  


___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] will elrepo do mass rebuild for EL 7.7

[Nick Howitt]

Try just using the latest version you can see. many of the drivers 
probably don't need recompiling for 7.7. I have not tried 7.7 yet, but 
as an example, kmod-r8168-8.046.00-1.el7_5 works in 7.5 and 7.6 so there 
was no need to recompile it for 7.6.


On 30/08/2019 04:38, d tbsky wrote:

Hi:
 I saw there are few drivers for EL 7.7 currently. RHEL 7.7/SL 7.7
both released, but not Centos 7.7. will elrepo update most drivers to
7.7 later, or I need to create ticket(like kmod-drbd) ?

thanks a lot for help!
___
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

Re: [elrepo] Announcement: EL6 and EL7 Updated kmod-r8168 Release [8.046.00-1]

[Nick Howitt]

  
  


On 11/09/2018 16:49, Alan Bartlett
  wrote:


  
Big hints . . .

--define 'dist .el6_10.clearos'

--define 'dist .el7_5.clearos'

Use the above defines on your rpmbuild or mock command lines.

Alan.



Thanks. I am still learning this. I had it set up in
/root/.rpmmacros but for the point releases I was having to change
the spec file.
  

___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] Announcement: EL6 and EL7 Updated kmod-r8168 Release [8.046.00-1]

[Nick Howitt]

  
  


On 10/09/2018 20:08, Phil Perry wrote:


  Also worth noting is that if you compile
these from the src.rpm, neither the 6_10 nor the 7_5 packages
get the 6_10 or the 7_5 tag in the generated rpm. With the 7.4
packages you overwrote the Release parameter in the
r8168-kmod.spec file.


  
  
  Yes, we recently reverted this as others were rebuilding our SRPMs
  without updating the dist tag and producing packages with 'elrepo'
  in the release thus creating support load and headaches for us. We
  now set dist as we see fit at build time. Similarly, you may do as
  you see fit when you rebuild as they become your packages, not
  ours. The only thing we ask is please do not use/replicate
  'elrepo' in the release as they are no longer elrepo packages.
  

Guilty as charged! I'll change these one to clearos6_10.njh and
clearos7_5.njh although I am wondering about building straight
through again as you have, in which case it will become clearos6.njh
and clearos7.njh
  

___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] Announcement: EL6 and EL7 Updated kmod-r8168 Release [8.046.00-1]

[Nick Howitt]

  
  
On 09/09/2018 13:02, Phil Perry wrote:

  
  On 09/09/18 12:39, Nick Howitt wrote:
  
  Thanks for this.

The el6 version compiles cleanly with a 6.9 kernel. Do you know
if the package is in any way limited to 6.10 kernels as I don't
have a current 6.10 installation I can test against.


Regards,


Nick


  
  
  The module only weak links against 6.10 kernels when build against
  6.10:
  
  
  $ find /lib/modules/ -name r8168.ko
  
  /lib/modules/2.6.32-754.el6.x86_64/extra/r8168/r8168.ko
  
  /lib/modules/2.6.32-754.2.1.el6.x86_64/weak-updates/r8168/r8168.ko
  
  /lib/modules/2.6.32-754.3.5.el6.x86_64/weak-updates/r8168/r8168.ko
  
  
  due to the new retpoline __x86_indirect_thunk_* functions:
  
  
  $ rpm -q --requires kmod-r8168 | grep __x86_indirect_thunk_
  
  kernel(__x86_indirect_thunk_r10) = 0x7e526bfa
  
  kernel(__x86_indirect_thunk_r11) = 0xbfdcb43a
  
  kernel(__x86_indirect_thunk_r8) = 0x1ed8b599
  
  kernel(__x86_indirect_thunk_rax) = 0x2ea2c95c
  
  kernel(__x86_indirect_thunk_rcx) = 0xc29957c3
  
  kernel(__x86_indirect_thunk_rdx) = 0xb601be4c
  
  
  hence the .el6_10.elrepo dist tag used to signify the package is
  specific to 6.10.
  
  
  I can't answer as to what you are doing if you are rebuilding
  against older non-RHEL compatible kernels, so your guess is as
  good as mine.
  
  
  ___
  
  elrepo mailing list
  
  elrepo@lists.elrepo.org
  
  http://lists.elrepo.org/mailman/listinfo/elrepo
  

Hi Phil

Wacky but it looks like it will weak-link forwards from
2.6.32-690.30 when compiled with a 2.6.32-690.30.1 kernel, but it
will not weak-link backwards. Anyway, to avoid possible issues I
have set a kernel dependency for >= 2.6.32-754. You did that type
of Requires in the 7.5 src.rpm but not the 6.10.
Also worth noting is that if you compile these from the src.rpm,
neither the 6_10 nor the 7_5 packages get the 6_10 or the 7_5 tag in
the generated rpm. With the 7.4 packages you overwrote the Release
parameter in the r8168-kmod.spec file.

Regards,

Nick

  

___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] Announcement: EL6 and EL7 Updated kmod-r8168 Release [8.046.00-1]

[Nick Howitt]

  
  
Thanks for this.
The el6 version compiles cleanly with a 6.9 kernel. Do you know if
the package is in any way limited to 6.10 kernels as I don't have a
current 6.10 installation I can test against.

Regards,

Nick

On 08/09/2018 20:46, Alan Bartlett
  wrote:


  
Announcing the release of updated kmod-r8168 packages into the EL6 and
EL7 elrepo repositories:

http://elrepo.org/tiki/kmod-r8168

This package provides an updated r8168 kernel module for Realtek
RTL8168/RTL8111, RTL8168B/RTL8111B, RTL8168C/RTL8111C,
RTL8168D/RTL8111D, RTL8168E/RTL8111E and RTL8168F/RTL8111F Gigabit
Ethernet controllers, version 8.046.00

It is built to depend upon the specific ABI provided by a range of
releases of the same variant of the Linux kernel and not on any one
specific build.

The following files are currently synchronising to our mirror sites:

EL6:

x86
kmod-r8168-8.046.00-1.el6_10.elrepo.i686.rpm

x86_64
kmod-r8168-8.046.00-1.el6_10.elrepo.x86_64.rpm

SRPMS
r8168-kmod-8.046.00-1.el6_10.elrepo.src.rpm

EL7:

x86_64
kmod-r8168-8.046.00-1.el7_5.elrepo.x86_64.rpm

SRPMS
r8168-kmod-8.046.00-1.el7_5.elrepo.src.rpm

You may update your system by:

yum --disablerepo=\* --enablerepo=elrepo update kmod-r8168

Thank you,

The ELRepo Team.
___
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

Re: [elrepo] kmod-tpe crashes

[Nick Howitt]

  
  
And its crashed again on the new kernel. I'll post the info
requested tomorrow.

Nick

On 07/07/2018 10:19, Nick Howitt wrote:


  
  Hi Phil,
  
  I'll temporarily put this on hold as the distro has just pushed
  out a new kernel, 3.10.0-862.6.3.v7.x86_64. I'll have to see if it
  still crashes or I could end up wasting everybody's time. The VM
  has started successfully twice now.
  
  Regards,
  
  Nick
  
  
  On 06/07/2018 20:05, Phil Perry wrote:
  
  

On 04/07/18 18:18, Akemi Yagi wrote:

On Wed, Jul 4, 2018 at 3:53 AM, Nick
  Howitt  wrote:
  
  Hi,


Following a thread I saw here I am using kmod-tpe in VM in
Virtualbox. The

VM is ClearOS 7.5 beta so is running kernel
3.10.0-862.3.2.v7.x86_64 and I

am getting intermittent kernel dumps on bootup. More often
than not boot

goes OK, but a number of times I get a kernel panic.
Unfortunately I can

only get an image of the frozen panicked screen as I don't
know how to do a

serial dump from VB to the PC. I'll attach the image and
hope you get it.


What is the best approach on this? If it is the right site,

https://github.com/cormander/tpe-lkm seems very quiet.


Nick

  
  
  The maintainer of kmod-tpe (Phil) is in close contact with
  Corey
  
  Henderson (cormander). Phil is away now but will be back in a
  couple
  
  of days. In the meantime it would help if you file a bug
  report at
  
  http://elrepo.org/bugs so that we can track it there. I am not
  sure if
  
  the ClearOS kernel is 100% binary compatible with RHEL though.
  What
  
  was the last kernel version that worked?
  
  
  Akemi
  



Hi Nick,


Corey, the author of tpe, asked you open an issue with him and
he will try to assist you directly (see below):


https://github.com/cormander/tpe-lkm/issues/new


"Have him include the URL to download the .iso or other file he
installed his VM with so I can get set up with a similar
environment to test".


Regards,


Phil


___

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
  


  

___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] kmod-tpe crashes

[Nick Howitt]

On 07/07/2018 10:26, Trevor Hemsley wrote:

On 07/07/18 10:19, Nick Howitt wrote:

Hi Phil,
I'll temporarily put this on hold as the distro has just pushed out a
new kernel, 3.10.0-862.6.3.v7.x86_64. I'll have to see if it still
crashes or I could end up wasting everybody's time. The VM has started
successfully twice now.
Regards,
Nick

Did you rebuild kmod-tpe against the 7.5 kernel source or are you still
using a kmod built against 7.4 (or earlier)?

Trevor
I built it against our first 7.5 kernel (3.10.0-862.2.3.v7.x86_64) then, 
because of the crashing, built it again against 3.10.0-862.3.2.v7.x86_64


Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] kmod-tpe crashes

[Nick Howitt]

Hi Phil,
I'll temporarily put this on hold as the distro has just pushed out a 
new kernel, 3.10.0-862.6.3.v7.x86_64. I'll have to see if it still 
crashes or I could end up wasting everybody's time. The VM has started 
successfully twice now.

Regards,
Nick

On 06/07/2018 20:05, Phil Perry wrote:


On 04/07/18 18:18, Akemi Yagi wrote:

On Wed, Jul 4, 2018 at 3:53 AM, Nick Howitt  wrote:

Hi,

Following a thread I saw here I am using kmod-tpe in VM in 
Virtualbox. The
VM is ClearOS 7.5 beta so is running kernel 3.10.0-862.3.2.v7.x86_64 
and I
am getting intermittent kernel dumps on bootup. More often than not 
boot
goes OK, but a number of times I get a kernel panic. Unfortunately I 
can
only get an image of the frozen panicked screen as I don't know how 
to do a
serial dump from VB to the PC. I'll attach the image and hope you 
get it.


What is the best approach on this? If it is the right site,
https://github.com/cormander/tpe-lkm seems very quiet.

Nick


The maintainer of kmod-tpe (Phil) is in close contact with Corey
Henderson (cormander). Phil is away now but will be back in a couple
of days. In the meantime it would help if you file a bug report at
http://elrepo.org/bugs so that we can track it there. I am not sure if
the ClearOS kernel is 100% binary compatible with RHEL though. What
was the last kernel version that worked?

Akemi



Hi Nick,

Corey, the author of tpe, asked you open an issue with him and he will 
try to assist you directly (see below):


https://github.com/cormander/tpe-lkm/issues/new

"Have him include the URL to download the .iso or other file he 
installed his VM with so I can get set up with a similar environment 
to test".


Regards,

Phil

___
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

Re: [elrepo] kmod-tpe crashes

[Nick Howitt]

On 04/07/2018 18:18, Akemi Yagi wrote:

On Wed, Jul 4, 2018 at 3:53 AM, Nick Howitt  wrote:

Hi,

Following a thread I saw here I am using kmod-tpe in VM in Virtualbox. The
VM is ClearOS 7.5 beta so is running kernel 3.10.0-862.3.2.v7.x86_64 and I
am getting intermittent kernel dumps on bootup. More often than not boot
goes OK, but a number of times I get a kernel panic. Unfortunately I can
only get an image of the frozen panicked screen as I don't know how to do a
serial dump from VB to the PC. I'll attach the image and hope you get it.

What is the best approach on this? If it is the right site,
https://github.com/cormander/tpe-lkm seems very quiet.

Nick

The maintainer of kmod-tpe (Phil) is in close contact with Corey
Henderson (cormander). Phil is away now but will be back in a couple
of days. In the meantime it would help if you file a bug report at
http://elrepo.org/bugs so that we can track it there. I am not sure if
the ClearOS kernel is 100% binary compatible with RHEL though. What
was the last kernel version that worked?

Akemi
Afaik, the ClearOS kernel is an el7 kernel patched for IMQ only. It does 
mean I have to recompile all the Elrepo sources because your compiled 
ones don't work on ClearOS - I've been doing that for years for the NIC 
drivers. I only recently started using tpe and only on a play VM which 
is not often on. I had no problem with any of the 7.4 kernels, but get a 
fair number of crashes with the 7.5 kernel. It has just crashed now as I 
booted up to check something before writing the e-mail, but the VM then 
worked on a reboot. I'm just registering an account to file a bug. The 
annoying thing is that I can't get a text dump; just a screenshot and I 
can't scroll back. I believe there is a way of enabling a serial port 
and redirecting the output there but I don't know the details.


Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

[elrepo] kmod-tpe crashes

[Nick Howitt]

Hi,

Following a thread I saw here I am using kmod-tpe in VM in Virtualbox. 
The VM is ClearOS 7.5 beta so is running kernel 3.10.0-862.3.2.v7.x86_64 
and I am getting intermittent kernel dumps on bootup. More often than 
not boot goes OK, but a number of times I get a kernel panic. 
Unfortunately I can only get an image of the frozen panicked screen as I 
don't know how to do a serial dump from VB to the PC. I'll attach the 
image and hope you get it.


What is the best approach on this? If it is the right site, 
https://github.com/cormander/tpe-lkm seems very quiet.


Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

[elrepo] zd1211rw driver for EL7.5 confusion

[Nick Howitt]

Hi gents,
I had the zd1211rw driver compiled for 7.4, but it did not do the weak 
updates bit to the 7.5 kernel. Recompiling without any source changes it 
gave no errors and doing a reinstall has it working with the 7.5 kernel. 
This has me confused. Does it mean that other drivers need to be 
recompiled against 7.5 even though you have not released a specific 7.5 
version (e.g aic7xxx)? Or is it just a question of "suck it and see"?

Regards,
Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] Dual boot rhel 7.5 - gui not starting

[Nick Howitt]

Symlink them?

On 01/06/2018 04:50, John Adegbile wrote:
So I scrutinized my Xorg.log file as suggested and found some lines 
showing failures:


/[    28.568] (EE) Failed to load 
/usr/lib64/xorg/modules/extensions/nvidia/libglx.so: 
libnvidia-tls.so.390.59: cannot open shared object file: No such file 
or directory/

/[    28.568] (II) UnloadModule: "glx"/
/[    28.568] (II) Unloading glx/
/[    28.568] (EE) Failed to load module "glx" (loader failed, 7)/
/.../
/.../
/[    28.700] (EE) [drm] Failed to open DRM device for (null): -2/
/[    28.710] (II) modeset(0): using drv /dev/dri/card1/
/[    28.710] (WW) Falling back to old probe method for fbdev/

I checked the directories and the missing shared object is actually in 
/usr/lib64/nvidia. However, I have configured my bumblebee.conf file 
exactly as specified in the bumblebee wiki which has the 
XorgModulePath specifying the directory path which fails above.


I don't think I should be attempting to change the directory path for 
XorgModulePath to point to /usr/lib64/nvidia since the bumblebee wiki 
does not say to do that.



On Tue, 29 May 2018 at 09:58, Akemi Yagi > wrote:


On Sat, May 26, 2018 at 4:40 PM, Akemi Yagi mailto:amy...@gmail.com>> wrote:
> On Sat, May 26, 2018 at 2:45 PM, John Adegbile
mailto:johnadegb...@gmail.com>> wrote:
>>
>> On Sat, 26 May 2018 at 01:13, Akemi Yagi mailto:amy...@gmail.com>> wrote:
>>>
>>> On Fri, May 25, 2018 at 7:20 PM, John Adegbile
mailto:johnadegb...@gmail.com>>
>>> wrote:
>>> > Hello,
>>> >
>>> > I am struggling a bit to get a GUI installation completed on
my MSI
>>> > GS63VR
>>> > laptop. It comes with windows 10 and I have dual booted with
RHEL 7.5 .
>>> > I
>>> > have completed the rhel installation and have installed the
nvidia
>>> > drivers
>>> > from elrepo.
>>> >
>>> > I can't get the GUI to work though. Would someone kindly be
able to give
>>> > me
>>> > some pointers as to where I'm going wrong? I have enabled
default
>>> > graphical.target via systemctl but the GUI does not launch.
The error I
>>> > get
>>> > when I attempt to run startx manually is:
>>> >
>>> > [  1740.462] (EE) Screen(s) found, but none have a usable
configuration.
>>> > Fatal server error:
>>> > [  1740.462] (EE) no screens found(EE)
>>> > [  1740.463] (EE)
>>> >
>>> > Output of lspci is:
>>> > 00:02.0 VGA compatible controller: Intel Corporation Device
591b (rev
>>> > 04)
>>> > 01:00.0 VGA compatible controller: NVIDIA Corporation GP106M
[GeForce
>>> > GTX
>>> > 1060 Mobile] (rev a1)
>>> >
>>> > Output of nvidia-detect is:
>>> > Probing for supported NVIDIA devices...
>>> > [10de:1c20] NVIDIA Corporation GP106M [GeForce GTX 1060 Mobile]
>>> > This device requires the current 390.59 NVIDIA driver
kmod-nvidia
>>> > [8086:591b] Intel Corporation Device 591b
>>> >
>>> > RPMs installed:
>>> > nvidia-x11-drv-390.59-1.el7_5.elrepo.x86_64
>>> > yum-plugin-nvidia-1.0.2-1.el7.elrepo.noarch
>>> > kmod-nvidia-390.59-1.el7_5.elrepo.x86_64
>>> > nvidia-detect-390.59-1.el7.elrepo.x86_64
>>> >
>>> > uname -a:
>>> > 3.10.0-862.3.2.el7.x86_64
>>> >
>>> > Thanks in advance
>>> >
>>> > J
>>>
>>> You seem to have two graphics devices, an integrated graphics
(Intel)
>>> and an Nvidia card. Can you disable the former in the BIOS? If
this is
>>> not possible, you need to make use of the Nvidia Optimus
technology.
>>> For detailed instructions, please see the bumblebee wiki page at:
>>>
>>> http://elrepo.org/tiki/bumblebee
>>>
>>> Akemi
>
>> Thanks for the tip.
>>
>> I installed and configured bumblebee (using primus as an
alternative to
>> optirun). I followed the instructions and machine now hangs
when I get to:
>> [OK] Started GNOME display Manager.
>> [OK] Started Virtualization daemon.
>
> Did you see any error message while installing the required
packages?
> No steps missed when configuring it?
>
> Not using it myself, I cannot provide better support than referring
> you to what has already been written. There is an instruction note
> given by a CentOS user:
>
>
https://www.centos.org/forums/viewtopic.php?f=49=61162=10#p266381
>
> It's basically the same except the addition of the last step (10).
>
> Akemi

I'm copying a message from Nicolas Thierry-Mieg below. Hope this helps
you figure out why things are not working.

Akemi

"you might have some useful info in /var/log/Xorg.*

I had set up bumblebee on my son's laptop in the past and had to move
some things around, because [some reason, can't remember the details
but it was something like X not looking in the correct folders for the
2 

Re: [elrepo] r8169 driver for 7.5

[Nick Howitt]

The in-kernel driver does work but I have a problem. My box has both an
r8168 and r8169 card in it. The kmod-r8168 blacklists the r8169 driver to
stop it from loading. If I remove the blacklist, it sometimes loads against
the r8168 card and sometimes it does not. Installing the kmod-r8169 driver
removes the 8168 PCI ID from its compatibility list. This allows me to
remove the blacklist and have both drivers automatically load against the
correct NIC's. I did try taking this up on the lists with the 7.4 upgrade,
suggesting the r8168 driver stopped blacklisting the r8169 and instead
installed the kmod-r8169 as a dependency, but I was told no.

Regards, Nick

OK, we have released the kmod-r8169 package built against the 7.5
kernel to the elrepo-testing repo:

kmod-r8169-6.020.00-3.el7_5.elrepo.x86_64.rpm

Can you give it a try?

Akemi

Thanks. I have it compiled and running (after removing the blacklist 
file from the r8168 driver).


Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] r8169 driver for 7.5

[Nick Howitt]

On 22/05/2018 18:02, Akemi Yagi wrote:

On Tue, May 22, 2018 at 4:53 AM, Nick Howitt <n...@howitts.co.uk> wrote:

Hi Phil,

Is there any chance of updating the r8169 driver to be compatible with 7.5?
I am getting the following errors:

/home/build/rpmbuild/BUILD/r8169-6.020.00/src/r8169_n.c:2617:9:
error: unknown field 'ndo_change_mtu' specified in initializer
  .ndo_change_mtu  = rtl8169_change_mtu,

That build error can be fixed by changing

.ndo_change_mtu

to

.ndo_change_mtu_rh74
(Thanks to pgreco for the fix)

By the way does the in-kernel r8169 driver not work for you?

Akemi
The in-kernel driver does work but I have a problem. My box has both an 
r8168 and r8169 card in it. The kmod-r8168 blacklists the r8169 driver 
to stop it from loading. If I remove the blacklist, it sometimes loads 
against the r8168 card and sometimes it does not. Installing the 
kmod-r8169 driver removes the 8168 PCI ID from its compatibility list. 
This allows me to remove the blacklist and have both drivers 
automatically load against the correct NIC's. I did try taking this up 
on the lists with the 7.4 upgrade, suggesting the r8168 driver stopped 
blacklisting the r8169 and instead installed the kmod-r8169 as a 
dependency, but I was told no.


Regards, Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

[elrepo] r8169 driver for 7.5

[Nick Howitt]

Hi Phil,

Is there any chance of updating the r8169 driver to be compatible with 
7.5? I am getting the following errors:


   /home/build/rpmbuild/BUILD/r8169-6.020.00/src/r8169_n.c:2617:9:
   error: unknown field 'ndo_change_mtu' specified in initializer
 .ndo_change_mtu  = rtl8169_change_mtu,
 ^
   /home/build/rpmbuild/BUILD/r8169-6.020.00/src/r8169_n.c:2617:9:
   warning: missing braces around initializer [-Wmissing-braces]
   /home/build/rpmbuild/BUILD/r8169-6.020.00/src/r8169_n.c:2617:9:
   warning: (near initialization for 'rtl8169_netdev_ops.')
   [-Wmissing-braces]
   /home/build/rpmbuild/BUILD/r8169-6.020.00/src/r8169_n.c:2617:9:
   warning: initialization from incompatible pointer type [enabled by
   default]
   /home/build/rpmbuild/BUILD/r8169-6.020.00/src/r8169_n.c:2617:9:
   warning: (near initialization for
   'rtl8169_netdev_ops..ndo_get_stats64') [enabled by default]
   make[1]: ***
   [/home/build/rpmbuild/BUILD/r8169-6.020.00/src/r8169_n.o] Error 1
   make: *** [_module_/home/build/rpmbuild/BUILD/r8169-6.020.00/src]
   Error 2
   make: Leaving directory `/usr/src/kernels/3.10.0-862.2.3.el7.x86_64'
   error: Bad exit status from /var/tmp/rpm-tmp.BnTLU8 (%build)


This was one which slipped through the net with 7.4 in that it was 
updated for 7.4 compatibility but never got the 7_4 in the name.


Thanks

Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] USB wireless adapter not working (4.15)

[Nick Howitt]

I have no idea. I don't use Ubuntu. Perhaps their wpa_supplicant.conf 
has a line calling nl80211,wicd. You can do that with the D switch as well.


On 17/03/2018 17:38, Mahmood Naderan wrote:

So why ubuntu work without problem then?!



On Mar 17, 2018 20:14, "Alan Bartlett"

>>>r8188eu

Just coming back to this problem to explain the situation for
Mahmood . . .

The tests you have performed show that the vanilla r8188eu driver
(from upstream, at kernel.org ) has been
identified and correctly
loaded into the running kernel-ml. In essence, there is no problem
with the kernel-ml package. The problem arises with the way userland
support software that is shipped with RHEL 7 (and, thus, part of
Scientific Linux 7 and CentOS 7) interacts with the driver.

Ideally Realtek should update their r8188eu driver code and submit it
for inclusion in the upstream kernel sources (at kernel.org
). Until
that time occurs, modifications to the userland utilities called will
be necessary to use the driver module for your USB dongle.

Alan.
___
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


___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] USB wireless adapter not working (4.15)

[Nick Howitt]

No. The whole point of the link is to use the wext driver instead of the 
default nl80211 so use -Dwext. Also they have bypassed the 
/etc/wpa_supplicant/wpa_supplicant.conf file and coded the SSID and 
password directly, so try:


   wpa_supplicant -B -Dwext -c <(wpa_passphrase "ESSID" "PASSWORD") -i
   wlp36s0f3u3

or, perhaps:

   wpa_supplicant -i wlp36s0f3u3 -Dwext -c
   /etc/wpa_supplicant/wpa_supplicant.conf -B

Note I've never done any of this before myself but I've been researching 
it a bit recently for other reasons


Nick

On 17/03/2018 12:00, Mahmood Naderan wrote:

Since there is no internet connection on that machine, the only way is
to stick with wpa_supplicant. In the link that Nick provided, the
command is

wpa_supplicant -B -Dwext -c <(wpa_passphrase "ESSID" "PASSWORD") -i wlan0

Mine was

wpa_supplicant -i wlp36s0f3u3 -c /etc/wpa_supplicant/wpa_supplicant.conf -B

Should I change -c option?
Moreover, should I use -Dr8188eu ?


Regards,
Mahmood




On Sat, Mar 17, 2018 at 2:50 PM, Phil Perry  wrote:

For anyone venturing down this route, I note the nux-desktop repo has the
wicd packages :-)


___
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


___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] USB wireless adapter not working (4.15)

[Nick Howitt]

That was a bit unfair to blame wpa_supplicant. It would be nice if 
Realtek could release an nl80211 compatible driver rather than one for 
the deprecated wext driver.


On 17/03/2018 09:45, Nick Howitt wrote:


Possible link: 
http://www.thelinuxrain.com/articles/getting-realtek-8188eu-wireless-adapters-to-work-in-linux-and-possibly-other-wireless-realtek-chipsets. 
The issue appears to be wpa_supplicant. Google "r8188eu wpa_supplicant"


Nick

On 17/03/2018 09:39, Mahmood Naderan wrote:

So the output is

Bus 005 Device 006: ID 2001:3310 D-Link Corp.
$ grep -i 2001 /lib/modules/$(uname -r)/modules.alias | grep -i 3310
alias usb:v2001p3310d*dc*dsc*dp*ic*isc*ip*in* r8188eu
$ uname -r
4.15.10-1.el7.elrepo.x86_64
$ lsmod | head
Module  Size  Used by
r8188eu   421888  0
cfg80211  618496  1 r8188eu
rfkill 28672  1 cfg80211
fuse  102400  3
xt_CHECKSUM    16384  1
ipt_MASQUERADE 16384  3
nf_nat_masquerade_ipv4    16384  1 ipt_MASQUERADE
tun    36864  1
ip6t_rpfilter  16384  1



As I run the wpa_supplicant, I get an error where there is a problem
with initializing the driver.


$ ifconfig -a | grep -A 5 wl
wlp36s0f3u3: flags=4098<BROADCAST,MULTICAST>  mtu 1500
 ether 10:62:eb:30:9c:34  txqueuelen 1000  (Ethernet)
 RX packets 0  bytes 0 (0.0 B)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 0  bytes 0 (0.0 B)
 TX errors 0  dropped 0 overruns 0  carrier 0 collisions 0
$ sudo wpa_supplicant -i wlp36s0f3u3 -c
/etc/wpa_supplicant/wpa_supplicant.conf -B
Successfully initialized wpa_supplicant
nl80211: Driver does not support authentication/association or 
connect commands

nl80211: deinit ifname=wlp36s0f3u3 disabled_11b_rates=0
wlp36s0f3u3: Failed to initialize driver interface



Regards,
Mahmood




On Fri, Mar 16, 2018 at 10:12 PM, Alan Bartlett <a...@elrepo.org> wrote:
On 15 March 2018 at 16:54, Mahmood Naderan <mahmood...@gmail.com> 
wrote:

Hi,
I upgraded the default 3.10 on centos 7 to 4.15 via the elrepo rpm
packages. I have a D-Link DWA 123 wireless dongle which is working on
ubuntu with kernel 4.10. However, with centos 7 it doesn't work and
the blue LED is off. As I attach the adapter, I see the following
messages in the log




Any idea to fix that? Does kernel correctly load the module?

Regards,
Mahmood

My suggestion is that you --

* First upgrade to kernel-ml-4.15.10-1.el7.elrepo, which was released
yesterday. [1]

* Once the system has been rebooted and with the wireless dongle
unplugged, capture the state of the USB sub-systems; lsusb > usb-1.txt

* Now plug in the USB wireless dongle and, once again capture the
state of the USB sub-systems; lsusb > usb-2.txt

* Perform a diff on those two textual files and note the Vendor and
Device ID pairing for the wireless dongle.

* Perform a "double grep" on the modules.alias file for the Vendor and
Device ID pairing. Note the module name displayed, if any.

Real-world example --

[Duo2 tmp]$ lsusb > usb-1.txt
[Duo2 tmp]$ lsusb > usb-2.txt
[Duo2 tmp]$ diff usb-1.txt usb-2.txt
0a1

Bus 002 Device 002: ID 0b95:7720 ASIX Electronics Corp. AX88772
[Duo2 tmp]$ grep -i 0b95 /lib/modules/$(uname -r)/modules.alias | 
grep -i 7720

alias usb:v0B95p7720d*dc*dsc*dp*ic*isc*ip*in* asix
[Duo2 tmp]$

The Vendor and Device ID pairing for the device used in my example is
0b95:7720 and, via the double grep, we see that the asix module is
required.

With the required module known, it should be easy to see if it has
been loaded; lsmod | head

Alan.

[1] http://lists.elrepo.org/pipermail/elrepo/2018-March/004164.html
___
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


___
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

Re: [elrepo] USB wireless adapter not working (4.15)

[Nick Howitt]

Possible link: 
http://www.thelinuxrain.com/articles/getting-realtek-8188eu-wireless-adapters-to-work-in-linux-and-possibly-other-wireless-realtek-chipsets. 
The issue appears to be wpa_supplicant. Google "r8188eu wpa_supplicant"


Nick

On 17/03/2018 09:39, Mahmood Naderan wrote:

So the output is

Bus 005 Device 006: ID 2001:3310 D-Link Corp.
$ grep -i 2001 /lib/modules/$(uname -r)/modules.alias | grep -i 3310
alias usb:v2001p3310d*dc*dsc*dp*ic*isc*ip*in* r8188eu
$ uname -r
4.15.10-1.el7.elrepo.x86_64
$ lsmod | head
Module  Size  Used by
r8188eu   421888  0
cfg80211  618496  1 r8188eu
rfkill 28672  1 cfg80211
fuse  102400  3
xt_CHECKSUM16384  1
ipt_MASQUERADE 16384  3
nf_nat_masquerade_ipv416384  1 ipt_MASQUERADE
tun36864  1
ip6t_rpfilter  16384  1



As I run the wpa_supplicant, I get an error where there is a problem
with initializing the driver.


$ ifconfig -a | grep -A 5 wl
wlp36s0f3u3: flags=4098  mtu 1500
 ether 10:62:eb:30:9c:34  txqueuelen 1000  (Ethernet)
 RX packets 0  bytes 0 (0.0 B)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 0  bytes 0 (0.0 B)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
$ sudo wpa_supplicant -i wlp36s0f3u3 -c
/etc/wpa_supplicant/wpa_supplicant.conf -B
Successfully initialized wpa_supplicant
nl80211: Driver does not support authentication/association or connect commands
nl80211: deinit ifname=wlp36s0f3u3 disabled_11b_rates=0
wlp36s0f3u3: Failed to initialize driver interface



Regards,
Mahmood




On Fri, Mar 16, 2018 at 10:12 PM, Alan Bartlett  wrote:

On 15 March 2018 at 16:54, Mahmood Naderan  wrote:

Hi,
I upgraded the default 3.10 on centos 7 to 4.15 via the elrepo rpm
packages. I have a D-Link DWA 123 wireless dongle which is working on
ubuntu with kernel 4.10. However, with centos 7 it doesn't work and
the blue LED is off. As I attach the adapter, I see the following
messages in the log




Any idea to fix that? Does kernel correctly load the module?

Regards,
Mahmood

My suggestion is that you --

* First upgrade to kernel-ml-4.15.10-1.el7.elrepo, which was released
yesterday. [1]

* Once the system has been rebooted and with the wireless dongle
unplugged, capture the state of the USB sub-systems; lsusb > usb-1.txt

* Now plug in the USB wireless dongle and, once again capture the
state of the USB sub-systems; lsusb > usb-2.txt

* Perform a diff on those two textual files and note the Vendor and
Device ID pairing for the wireless dongle.

* Perform a "double grep" on the modules.alias file for the Vendor and
Device ID pairing. Note the module name displayed, if any.

Real-world example --

[Duo2 tmp]$ lsusb > usb-1.txt
[Duo2 tmp]$ lsusb > usb-2.txt
[Duo2 tmp]$ diff usb-1.txt usb-2.txt
0a1

Bus 002 Device 002: ID 0b95:7720 ASIX Electronics Corp. AX88772

[Duo2 tmp]$ grep -i 0b95 /lib/modules/$(uname -r)/modules.alias | grep -i 7720
alias usb:v0B95p7720d*dc*dsc*dp*ic*isc*ip*in* asix
[Duo2 tmp]$

The Vendor and Device ID pairing for the device used in my example is
0b95:7720 and, via the double grep, we see that the asix module is
required.

With the required module known, it should be easy to see if it has
been loaded; lsmod | head

Alan.

[1] http://lists.elrepo.org/pipermail/elrepo/2018-March/004164.html
___
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


___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] Updated 8818AU driver, please

[Nick Howitt]

On 05/03/2018 22:51, Phil Perry wrote:

On 05/03/18 20:29, Nick Howitt wrote:



On 05/03/2018 20:24, Nick Howitt wrote:



On 05/03/2018 20:16, Phil Perry wrote:

On 05/03/18 09:35, Nick Howitt wrote:

Hi,

I have a little USB 802.11ac dongle that I'm trying to get going 
in my server. lsusb gives:


    Bus 002 Device 002: ID 0bda:a811 Realtek Semiconductor Corp.
    RTL8811AU 802.11a/b/g/n/ac WLAN Adapter


I've had a look at the current kmod driver which is version 
8188eu-kmod-4.1.4_6773.20130222-3 and it does not cover the USB 
ID. Looking at the spec file in the src rpm it points me to 
https://github.com/lwfinger/rtl8188eu but there is no useful 
update there.


There appear to be a few sources for this driver such as 
https://github.com/abperiasamy/rtl8812AU_8821AU_linux and 
https://github.com/diederikdehaas/rtl8812AU which both cover the 
USB ID. Are you able to work your magic on one of these or any 
other relevant version you can find?


Many thanks,

Nick



Sure, I can take a look but it probably won't be before the weekend.

Do either of those driver sources compile / work for you? The first 
one looks more maintained so I'd probably start with that. I 
couldn't find any linux driver/source on the Realtek website for 
your device, only for Windows. I wonder where these (above) driver 
sources originated?


Phil
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Hi Phil,
I have not tried compiling anything because I don't know what magic 
you do. I can give it a go and see what happens. I am puzzled about 
the sources because I tried searching github for rtl8188au and only 
the lwfinger sources appeared so I must searching incorrectly. I 
agree about the realtek site. I tried searching there as well.

Yours puzzled,
Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo
Google-fu working better: 
https://github.com/zebulon2/rtl8812au-driver-5.2.20 and 
https://github.com/gordboy/rtl8812au. I've never compiled dkms stuff 
before 


Nick


These are originally imported from Realtek. For example, see the 
Realtek changelog from your last link:


https://github.com/gordboy/rtl8812au/blob/a20632c756bd8bd84eb1cb93ac6609d11cd87343/Realtek_Changelog.txt 



Still, briefly looking at the code I anticipate huge issues getting 
the code to build on el7. The issue is the code uses many conditionals 
based on the linux kernel version. The code views the el7 kernel as a 
3.10 kernel, but Red Hat has backported the wireless stack from 
kernel-4.11 in el7.4 which is most likely why your builds fail.


To be brutally honest, it's generally not worth the effort trying to 
fix this, as even if we do fix it, it will break again next month when 
Red Hat release el7.5 with a backported wireless stack based upon 
kernel-4.14. Rather than me/us trying to fix it, I would request 
Realtek provide a driver that supports RHEL and let them do the hard 
work, or not buy their hardware.


I would put your unsupported hardware back in it's box and stick it on 
a shelf until such time as it is natively supported, and buy something 
that works out of the box. For example, I recently purchased an Edimax 
N150 nano USB adapter (EW-7811Un) for less than $10 on Amazon which is 
natively supported and works fine out of the box on el7 (based on 
Realtek RTL8188CUS chipset, uses the rtl8192cu driver), replacing a 
failing internal WiFi adapter in my laptop.



___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo
I'm giving up. I've found references to v4.3.8 compiling OK. I found 
those at 
https://github.com/ulli-kroll/rtl8821au/tree/original/v4.3.8/vanilla and 
they compile with a couple of warnings. I can modprobe the resulting .ko 
but it is never used or associated with the NIC so ifcfg files never get 
created and so on.


I'm just looking out for a cheap adaptor to play with to try out n and 
ac 5GHz configurations on the server. I'll start hunting again. I 
thought I had it sorted, but it is hard to get the PCI/USB ID's in 
advance of buying the adaptor.


Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] Updated 8818AU driver, please

[Nick Howitt]

On 05/03/2018 20:29, Nick Howitt wrote:



On 05/03/2018 20:24, Nick Howitt wrote:



On 05/03/2018 20:16, Phil Perry wrote:

On 05/03/18 09:35, Nick Howitt wrote:

Hi,

I have a little USB 802.11ac dongle that I'm trying to get going in 
my server. lsusb gives:


    Bus 002 Device 002: ID 0bda:a811 Realtek Semiconductor Corp.
    RTL8811AU 802.11a/b/g/n/ac WLAN Adapter


I've had a look at the current kmod driver which is version 
8188eu-kmod-4.1.4_6773.20130222-3 and it does not cover the USB ID. 
Looking at the spec file in the src rpm it points me to 
https://github.com/lwfinger/rtl8188eu but there is no useful update 
there.


There appear to be a few sources for this driver such as 
https://github.com/abperiasamy/rtl8812AU_8821AU_linux and 
https://github.com/diederikdehaas/rtl8812AU which both cover the 
USB ID. Are you able to work your magic on one of these or any 
other relevant version you can find?


Many thanks,

Nick



Sure, I can take a look but it probably won't be before the weekend.

Do either of those driver sources compile / work for you? The first 
one looks more maintained so I'd probably start with that. I 
couldn't find any linux driver/source on the Realtek website for 
your device, only for Windows. I wonder where these (above) driver 
sources originated?


Phil
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Hi Phil,
I have not tried compiling anything because I don't know what magic 
you do. I can give it a go and see what happens. I am puzzled about 
the sources because I tried searching github for rtl8188au and only 
the lwfinger sources appeared so I must searching incorrectly. I 
agree about the realtek site. I tried searching there as well.

Yours puzzled,
Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo
Google-fu working better: 
https://github.com/zebulon2/rtl8812au-driver-5.2.20 and 
https://github.com/gordboy/rtl8812au. I've never compiled dkms stuff 
before 


Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

The one I just found is a fail:

   [root@7 rtl8812au-driver-5.2.20]# make
   make ARCH=x86_64 CROSS_COMPILE= -C
   /lib/modules/3.10.0-693.17.1.v7.x86_64/build
   M=/usr/src/rtl8812au-driver-5.2.20  modules
   make[1]: Entering directory `/usr/src/kernels/3.10.0-693.17.1.v7.x86_64'
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_cmd.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_security.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_debug.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_io.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_ioctl_query.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_ioctl_set.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_ieee80211.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_mlme.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_mlme_ext.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_mi.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_wlan_util.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_vht.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_pwrctrl.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_rf.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_recv.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_sta_mgt.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_ap.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_xmit.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_p2p.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_rson.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_tdls.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_br_ext.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_iol.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_sreset.o
  CC [M] /usr/src/rtl8812au-driver-5.2.20/core/rtw_btcoex_wifionly.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_btcoex.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_beamforming.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/rtw_odm.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/core/efuse/rtw_efuse.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/os_dep/osdep_service.o
  CC [M]  /usr/src/rtl8812au-driver-5.2.20/os_dep/linux/os_intfs.o
   /usr/src/rtl8812au-driver-5.2.20/os_dep/linux/os_intfs.c:1418:2:
   warning: initialization from incompatible pointer type [enabled by
   default]
  .ndo_select_queue = rtw_select_queue,
  ^
   /usr/src/rtl8812au-driver-5.2.20/os_dep/linux/os_intfs.c:1418:2:
   warning: (near initialization for
   ‘rtw_netdev_ops..ndo_select_queue’) [enabled by default]
  CC [M]  /usr/src/rtl8812au-driver-5.2.20

Re: [elrepo] Updated 8818AU driver, please

[Nick Howitt]

On 05/03/2018 20:24, Nick Howitt wrote:



On 05/03/2018 20:16, Phil Perry wrote:

On 05/03/18 09:35, Nick Howitt wrote:

Hi,

I have a little USB 802.11ac dongle that I'm trying to get going in 
my server. lsusb gives:


    Bus 002 Device 002: ID 0bda:a811 Realtek Semiconductor Corp.
    RTL8811AU 802.11a/b/g/n/ac WLAN Adapter


I've had a look at the current kmod driver which is version 
8188eu-kmod-4.1.4_6773.20130222-3 and it does not cover the USB ID. 
Looking at the spec file in the src rpm it points me to 
https://github.com/lwfinger/rtl8188eu but there is no useful update 
there.


There appear to be a few sources for this driver such as 
https://github.com/abperiasamy/rtl8812AU_8821AU_linux and 
https://github.com/diederikdehaas/rtl8812AU which both cover the USB 
ID. Are you able to work your magic on one of these or any other 
relevant version you can find?


Many thanks,

Nick



Sure, I can take a look but it probably won't be before the weekend.

Do either of those driver sources compile / work for you? The first 
one looks more maintained so I'd probably start with that. I couldn't 
find any linux driver/source on the Realtek website for your device, 
only for Windows. I wonder where these (above) driver sources 
originated?


Phil
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Hi Phil,
I have not tried compiling anything because I don't know what magic 
you do. I can give it a go and see what happens. I am puzzled about 
the sources because I tried searching github for rtl8188au and only 
the lwfinger sources appeared so I must searching incorrectly. I agree 
about the realtek site. I tried searching there as well.

Yours puzzled,
Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo
Google-fu working better: 
https://github.com/zebulon2/rtl8812au-driver-5.2.20 and 
https://github.com/gordboy/rtl8812au. I've never compiled dkms stuff 
before 


Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] Updated 8818AU driver, please

[Nick Howitt]

On 05/03/2018 20:16, Phil Perry wrote:

On 05/03/18 09:35, Nick Howitt wrote:

Hi,

I have a little USB 802.11ac dongle that I'm trying to get going in 
my server. lsusb gives:


    Bus 002 Device 002: ID 0bda:a811 Realtek Semiconductor Corp.
    RTL8811AU 802.11a/b/g/n/ac WLAN Adapter


I've had a look at the current kmod driver which is version 
8188eu-kmod-4.1.4_6773.20130222-3 and it does not cover the USB ID. 
Looking at the spec file in the src rpm it points me to 
https://github.com/lwfinger/rtl8188eu but there is no useful update 
there.


There appear to be a few sources for this driver such as 
https://github.com/abperiasamy/rtl8812AU_8821AU_linux and 
https://github.com/diederikdehaas/rtl8812AU which both cover the USB 
ID. Are you able to work your magic on one of these or any other 
relevant version you can find?


Many thanks,

Nick



Sure, I can take a look but it probably won't be before the weekend.

Do either of those driver sources compile / work for you? The first 
one looks more maintained so I'd probably start with that. I couldn't 
find any linux driver/source on the Realtek website for your device, 
only for Windows. I wonder where these (above) driver sources originated?


Phil
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Hi Phil,
I have not tried compiling anything because I don't know what magic you 
do. I can give it a go and see what happens. I am puzzled about the 
sources because I tried searching github for rtl8188au and only the 
lwfinger sources appeared so I must searching incorrectly. I agree about 
the realtek site. I tried searching there as well.

Yours puzzled,
Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

[elrepo] Updated 8818AU driver, please

[Nick Howitt]

Hi,

I have a little USB 802.11ac dongle that I'm trying to get going in my 
server. lsusb gives:


   Bus 002 Device 002: ID 0bda:a811 Realtek Semiconductor Corp.
   RTL8811AU 802.11a/b/g/n/ac WLAN Adapter


I've had a look at the current kmod driver which is version 
8188eu-kmod-4.1.4_6773.20130222-3 and it does not cover the USB ID. 
Looking at the spec file in the src rpm it points me to 
https://github.com/lwfinger/rtl8188eu but there is no useful update there.


There appear to be a few sources for this driver such as 
https://github.com/abperiasamy/rtl8812AU_8821AU_linux and 
https://github.com/diederikdehaas/rtl8812AU which both cover the USB ID. 
Are you able to work your magic on one of these or any other relevant 
version you can find?


Many thanks,

Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] r8101 driver update

[Nick Howitt]

  
  
Hi Phil,

Please don't worry about this one. lspci said it was "RTL8101/2/6E
PCI Express Fast/Gigabit Ethernet controller" but googling further
says the RTL8102, 8102 and 8106 are 10/100 only which is no use.

Regards,

Nick

On 31/01/2018 08:20, Nick Howitt wrote:

Hi
  Phil,
  
  
  Is there any chance of updating the r8101 driver for el7 x64? I
  think this is another one which broke with the 7.4 kernel:
  
  
     /home/build/rpmbuild/BUILD/r8101-1.027.00/src/r8101_n.c: In
  function
  
     'rtl8101_start_xmit':
  
    
  /home/build/rpmbuild/BUILD/r8101-1.027.00/src/r8101_n.c:11430:12:
  
     error: 'struct net_device' has no member named 'trans_start'
  
       dev->trans_start = jiffies;
  
          ^
  
  
  Many thanks,
  
  
  Nick
  
  ___
  
  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

[elrepo] r8101 driver update

[Nick Howitt]

Hi Phil,

Is there any chance of updating the r8101 driver for el7 x64? I think 
this is another one which broke with the 7.4 kernel:


   /home/build/rpmbuild/BUILD/r8101-1.027.00/src/r8101_n.c: In function
   'rtl8101_start_xmit':
   /home/build/rpmbuild/BUILD/r8101-1.027.00/src/r8101_n.c:11430:12:
   error: 'struct net_device' has no member named 'trans_start'
 dev->trans_start = jiffies;
    ^

Many thanks,

Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] niu driver

[Nick Howitt]

  
  
Hi Alan,

I've had positive feedback that the niu driver is working.

Thanks,

Nick

On 23/11/2017 22:10, Nick Howitt wrote:


  
  Brilliant. I was watching different mirrors. I can see it now.
  
  Nick
  
  
  On 23/11/2017 22:09, Alan Bartlett wrote:
  
  On 23 November 2017 at 22:05, Nick Howitt
<n...@howitts.co.uk> wrote:

Thanks very much for your efforts. It
  has not sync'd to the mirrors yet so
  
  I'll have to wait until tomorrow.
  
  Regards,
  
  Nick
  

In the UK it is already available from --


http://mirrors.coreix.net/elrepo/testing/el7/


Alan.

___

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
  


  

___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] niu driver

[Nick Howitt]

Thanks very much for your efforts. It has not sync'd to the mirrors yet 
so I'll have to wait until tomorrow.

Regards,
Nick

On 23/11/2017 20:36, Phil Perry wrote:


On 23/11/17 19:35, Alan Bartlett wrote:

On 23 November 2017 at 19:02, Nick Howitt <n...@howitts.co.uk> wrote:

Hi Alan,
If it covers the right PCI ID that would be brilliant, thanks.
Nick



Using the "double grep" technique, I can see that the 108e:abcd
Vendor:Device id pairing is an alias for that Sun Ethernet 10 Mbps
driver.

[code]
[Duo1 ~]# grep -i 108e /lib/modules/*/modules.alias | grep -i abcd
/lib/modules/4.14.1-1.el7.elrepo.x86_64/modules.alias:alias
pci:v108EdABCDsv*sd*bc*sc*i* niu
/lib/modules/4.4.100-1.el7.elrepo.x86_64/modules.alias:alias
pci:v108EdABCDsv*sd*bc*sc*i* niu
[Duo1 ~]#



Nick,

Further to Alan's investigations, I have backported the niu driver for 
you:


kmod-niu-1.1-1.el7_4.elrepo.x86_64.rpm
niu-kmod-1.1-1.el7_4.elrepo.src.rpm

Packages are uploading to our mirrors now and should be available from 
the testing repository shortly.


Please would you have your user test and report back if they work as 
expected, at which point I will promote to our main repository.


yum --enablerepo=elrepo-testing install kmod-niu

Thanks

Phil

___
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

Re: [elrepo] niu driver

[Nick Howitt]

Hi Alan,
If it covers the right PCI ID that would be brilliant, thanks. 
Nick

On 23 November 2017 18:38:32 GMT+00:00, Alan Bartlett <a...@elrepo.org> wrote:
>
>On 23 November 2017 at 17:23, Nick Howitt <n...@howitts.co.uk> wrote:
>> Hi Alan,
>>
>> I should have been more specific. It would be for ClearOS7 64-bit.
>The EL7
>> kernel is not quite compatible with ClearOS (it currently breaks our
>QoS as
>> we patch the kernel for IMQ devices) and it is not for me either. I
>will
>> link the requester to this thread, and if he is willing to put in the
>> legwork, I'd be happy to compile any resulting srpm against our
>kernel for
>> him.
>>
>> Thanks,
>>
>> Nick
>
>Hi Nick,
>
>Looking on my RHEL7 system that also has kernel-lt and kernel-ml
>installed I see the following --
>
>[Duo1 ~]# find /lib/modules -name niu.ko | sort
>/lib/modules/4.14.1-1.el7.elrepo.x86_64/kernel/drivers/net/ethernet/sun/niu.ko
>/lib/modules/4.4.100-1.el7.elrepo.x86_64/kernel/drivers/net/ethernet/sun/niu.ko
>[Duo1 ~]#
>
>So it is just a module that is not supported natively with the
>distribution EL7 kernel. It is one of those modules that are supported
>by the distribution EL6 kernel but which have not been configured for
>the EL7 kernel.
>
>As always, no promises but we will see what can be done for you.
>
>Alan.
>___
>elrepo mailing list
>elrepo@lists.elrepo.org
>http://lists.elrepo.org/mailman/listinfo/elrepo

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] niu driver

[Nick Howitt]

Hi Alan,

I should have been more specific. It would be for ClearOS7 64-bit. The 
EL7 kernel is not quite compatible with ClearOS (it currently breaks our 
QoS as we patch the kernel for IMQ devices) and it is not for me either. 
I will link the requester to this thread, and if he is willing to put in 
the legwork, I'd be happy to compile any resulting srpm against our 
kernel for him.


Thanks,

Nick

On 2017-11-23 16:44, Alan Bartlett wrote:

On 23 November 2017 at 13:34, Nick Howitt <n...@howitts.co.uk> wrote:

Hi,

I am looking for a driver for the PCI ID 108e:abcd and I think I need 
the
niu driver. This is not currently provided by ElRepo. Do you know if 
it is
the correct driver and, if it is, what are the chances of it being 
provided?


Thanks,

Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo


We can try to help you . . . but first you must help us.

For which operating system, EL7 or EL6? And in the case of the latter,
which architecture, just one or both i.e. 32- & 64-bit?

Your next step, please, would be to temporarily install the kernel-lt
package, boot it and check for the required device functionality. If
successful, please show the output returned for the device from an
lspci -nnv command. If unsuccessful, remove the kernel-lt package and
temporarily install the kernel-ml package. Repeat the testing, etc.

Alan.
___
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

[elrepo] niu driver

[Nick Howitt]

Hi,

I am looking for a driver for the PCI ID 108e:abcd and I think I need 
the niu driver. This is not currently provided by ElRepo. Do you know if 
it is the correct driver and, if it is, what are the chances of it being 
provided?


Thanks,

Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] r8101/r8168/r8169 suggestion

[Nick Howitt]

On 26/10/2017 19:31, Phil Perry wrote:


On 26/10/17 17:25, Nick Howitt wrote:



On 26/10/2017 17:18, Manuel Wolfshant wrote:
On October 26, 2017 5:41:25 PM GMT+03:00, Nick Howitt 
<n...@howitts.co.uk> wrote:

Hi,

Can I suggest a change to the packaging of the above three drivers? 
I'd


like to suggest the three drivers are all made dependants of each 
other


and that the file \usr\lib\modprobe.d\blacklist-r8169.conf is removed

>from the r8101 and r8168 drivers? My reasoning is as follows:

The stock driver covers the following PCI ID's:
pci:v0001d8168sv*sd2410bc*sc*i*
pci:v1737d1032sv*sd0024bc*sc*i*
pci:v16ECd0116sv*sd*bc*sc*i*
pci:v1259dC107sv*sd*bc*sc*i*
pci:v1186d4302sv*sd*bc*sc*i*
pci:v1186d4300sv*sd*bc*sc*i*
pci:v1186d4300sv1186sd4B10bc*sc*i*
pci:v10ECd8169sv*sd*bc*sc*i*
pci:v10ECd8168sv*sd*bc*sc*i*
pci:v10ECd8167sv*sd*bc*sc*i*
pci:v10ECd8136sv*sd*bc*sc*i*
pci:v10ECd8129sv*sd*bc*sc*i*


The kmod-r8101 covers:
pci:v10ECd8136sv*sd*bc*sc*i*


The kmod-r8168 covers:
pci:v1186d4300sv1186sd4B10bc*sc*i*
pci:v10ECd8161sv*sd*bc*sc*i*
pci:v10ECd8168sv*sd*bc*sc*i*


And the kmod-r8169 covers:
pci:v1186d4302sv*sd*bc*sc*i*
pci:v1186d4300sv*sd*bc*sc*i*
pci:v1186d4300sv1186sd4C00bc*sc*i*
pci:v1186d4302sv1186sd4302bc*sc*i*
pci:v1186d4300sv1186sd4300bc*sc*i*
pci:v10ECd8169sv*sd*bc*sc*i*
pci:v10ECd8167sv*sd*bc*sc*i*


This leaves the following unknown in the ElRepo database:
pci:v16ECd0116sv*sd*bc*sc*i*
pci:v1259dC107sv*sd*bc*sc*i*
pci:v10ECd8129sv*sd*bc*sc*i*


And the following known and not supplied (sk98lin) by ElRepo:
pci:v1737d1032sv*sd0024bc*sc*i*


The current situation is that if you install either the kmod-r8101 or
kmod-r8168 then you can no longer use any NIC covered by the original
r8169 or the kmod-r8168 drivers, because the r8169 is blacklisted. If
the blacklist were removed and the dependencies added as I suggest (or
the drivers were packaged as one) then the
kmod-r8101/kmod-r8168/kmod-r8169 combo becomes a proper drop-in
replacement for the stock r8169 and it becomes possible, for example,
to
run r8168 and r8169 cards at the same time with the ElRepo drivers. (I
know as I do it, but had to resort to modprobing the r8169 until I
discovered it was blacklisted).

The 3 drivers are independent of each other so I do not think that 
they should depend on each other.
I'd rathet see documented that the blacklisting of stock r8169 can 
be removed if one really insists on combining stock and elrepo drivers.


But frankly you are the first person that I know of who needs that. 
Everybody else I know of either uses Intel/BRCM /Cavium 
cards/chipsets or relies on more or less identical Realtek ones.
Agreed, they are independent of each other, but only as a set do they 
replace the stock r8169. Anyone installed on its own removes NIC 
compatibility. If they are properly independent, I would have thought 
they should not blacklist the r8169.



The distro driver is a unified r8169 driver providing support for 
multiple devices, and users should use this where possible, and file 
bugs upstream with Red Hat where the driver does not work as expected.


In cases where the distro unified r8169 driver does not meet users 
needs / expectations, then we make available 3 individual OEM drivers 
(r8101, r8168, r8169) that largely support the devices supported by 
the unified r8169 driver.


The OEM kmod-r8169 driver is a simple drop in replacement for the 
distro driver of the same name. Because both kmod-r8101 and kmod-r8168 
drivers *replace* the distro r8169 driver, we must blacklist r8169 to 
prevent it loading and binding the device.


Users running edge case scenarios (multiple different Realtek based 
NICs??) are able to remove the blacklisting by deleting or editing the 
blacklist file and rebuilding the initramfs if required.


I agree with Manuel, the 3 elrepo kmod drivers are independent of each 
other. The user is free to install as many (or few) of them as 
required, but if installing more than one be aware some manual 
configuration may be required.


OK. I'll let it go. One last side effect of this blacklisting, is that 
if a user upgrades to say a 7.4 kernel, the latest kmod-r8168 driver 
replaces the previous one compatible the 7.3 kernel. If the user then 
reboots back to the 7.3 kernel he will have no NIC driver available. If 
the blacklist weren't there, the r8168 NIC could fall back to using the 
stock r8169 driver and at least have connectivity.





___
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

Re: [elrepo] r8101/r8168/r8169 suggestion

[Nick Howitt]

On 26/10/2017 17:18, Manuel Wolfshant wrote:

On October 26, 2017 5:41:25 PM GMT+03:00, Nick Howitt <n...@howitts.co.uk> 
wrote:

Hi,

Can I suggest a change to the packaging of the above three drivers? I'd

like to suggest the three drivers are all made dependants of each other

and that the file \usr\lib\modprobe.d\blacklist-r8169.conf is removed

>from the r8101 and r8168 drivers? My reasoning is as follows:

The stock driver covers the following PCI ID's:
pci:v0001d8168sv*sd2410bc*sc*i*
pci:v1737d1032sv*sd0024bc*sc*i*
pci:v16ECd0116sv*sd*bc*sc*i*
pci:v1259dC107sv*sd*bc*sc*i*
pci:v1186d4302sv*sd*bc*sc*i*
pci:v1186d4300sv*sd*bc*sc*i*
pci:v1186d4300sv1186sd4B10bc*sc*i*
pci:v10ECd8169sv*sd*bc*sc*i*
pci:v10ECd8168sv*sd*bc*sc*i*
pci:v10ECd8167sv*sd*bc*sc*i*
pci:v10ECd8136sv*sd*bc*sc*i*
pci:v10ECd8129sv*sd*bc*sc*i*


The kmod-r8101 covers:
pci:v10ECd8136sv*sd*bc*sc*i*


The kmod-r8168 covers:
pci:v1186d4300sv1186sd4B10bc*sc*i*
pci:v10ECd8161sv*sd*bc*sc*i*
pci:v10ECd8168sv*sd*bc*sc*i*


And the kmod-r8169 covers:
pci:v1186d4302sv*sd*bc*sc*i*
pci:v1186d4300sv*sd*bc*sc*i*
pci:v1186d4300sv1186sd4C00bc*sc*i*
pci:v1186d4302sv1186sd4302bc*sc*i*
pci:v1186d4300sv1186sd4300bc*sc*i*
pci:v10ECd8169sv*sd*bc*sc*i*
pci:v10ECd8167sv*sd*bc*sc*i*


This leaves the following unknown in the ElRepo database:
pci:v16ECd0116sv*sd*bc*sc*i*
pci:v1259dC107sv*sd*bc*sc*i*
pci:v10ECd8129sv*sd*bc*sc*i*


And the following known and not supplied (sk98lin) by ElRepo:
pci:v1737d1032sv*sd0024bc*sc*i*


The current situation is that if you install either the kmod-r8101 or
kmod-r8168 then you can no longer use any NIC covered by the original
r8169 or the kmod-r8168 drivers, because the r8169 is blacklisted. If
the blacklist were removed and the dependencies added as I suggest (or
the drivers were packaged as one) then the
kmod-r8101/kmod-r8168/kmod-r8169 combo becomes a proper drop-in
replacement for the stock r8169 and it becomes possible, for example,
to
run r8168 and r8169 cards at the same time with the ElRepo drivers. (I
know as I do it, but had to resort to modprobing the r8169 until I
discovered it was blacklisted).


The 3 drivers are independent of each other so I do not think that they should 
depend on each other.
I'd rathet see documented that the blacklisting of stock r8169 can be removed 
if one really insists on combining stock and elrepo drivers.

But frankly you are the first person that I know of who needs that. Everybody 
else I know of either uses Intel/BRCM /Cavium cards/chipsets or relies on more 
or less identical Realtek ones.
Agreed, they are independent of each other, but only as a set do they 
replace the stock r8169. Anyone installed on its own removes NIC 
compatibility. If they are properly independent, I would have thought 
they should not blacklist the r8169.

___
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

[elrepo] r8101/r8168/r8169 suggestion

[Nick Howitt]

Hi,

Can I suggest a change to the packaging of the above three drivers? I'd 
like to suggest the three drivers are all made dependants of each other 
and that the file \usr\lib\modprobe.d\blacklist-r8169.conf is removed 
from the r8101 and r8168 drivers? My reasoning is as follows:


The stock driver covers the following PCI ID's:
pci:v0001d8168sv*sd2410bc*sc*i*
pci:v1737d1032sv*sd0024bc*sc*i*
pci:v16ECd0116sv*sd*bc*sc*i*
pci:v1259dC107sv*sd*bc*sc*i*
pci:v1186d4302sv*sd*bc*sc*i*
pci:v1186d4300sv*sd*bc*sc*i*
pci:v1186d4300sv1186sd4B10bc*sc*i*
pci:v10ECd8169sv*sd*bc*sc*i*
pci:v10ECd8168sv*sd*bc*sc*i*
pci:v10ECd8167sv*sd*bc*sc*i*
pci:v10ECd8136sv*sd*bc*sc*i*
pci:v10ECd8129sv*sd*bc*sc*i*


The kmod-r8101 covers:
pci:v10ECd8136sv*sd*bc*sc*i*


The kmod-r8168 covers:
pci:v1186d4300sv1186sd4B10bc*sc*i*
pci:v10ECd8161sv*sd*bc*sc*i*
pci:v10ECd8168sv*sd*bc*sc*i*


And the kmod-r8169 covers:
pci:v1186d4302sv*sd*bc*sc*i*
pci:v1186d4300sv*sd*bc*sc*i*
pci:v1186d4300sv1186sd4C00bc*sc*i*
pci:v1186d4302sv1186sd4302bc*sc*i*
pci:v1186d4300sv1186sd4300bc*sc*i*
pci:v10ECd8169sv*sd*bc*sc*i*
pci:v10ECd8167sv*sd*bc*sc*i*


This leaves the following unknown in the ElRepo database:
pci:v16ECd0116sv*sd*bc*sc*i*
pci:v1259dC107sv*sd*bc*sc*i*
pci:v10ECd8129sv*sd*bc*sc*i*


And the following known and not supplied (sk98lin) by ElRepo:
pci:v1737d1032sv*sd0024bc*sc*i*


The current situation is that if you install either the kmod-r8101 or 
kmod-r8168 then you can no longer use any NIC covered by the original 
r8169 or the kmod-r8168 drivers, because the r8169 is blacklisted. If 
the blacklist were removed and the dependencies added as I suggest (or 
the drivers were packaged as one) then the 
kmod-r8101/kmod-r8168/kmod-r8169 combo becomes a proper drop-in 
replacement for the stock r8169 and it becomes possible, for example, to 
run r8168 and r8169 cards at the same time with the ElRepo drivers. (I 
know as I do it, but had to resort to modprobing the r8169 until I 
discovered it was blacklisted).


Regards,

Nick

___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] More 7.4 incompatible drivers

[Nick Howitt]

Hi Again,

It looks like the kmod-r8101 also needs to be added to the incompatible 
driver list:


   make: Entering directory `/usr/src/kernels/3.10.0-693.2.2.v7.x86_64'
  CC [M]  /home/build/rpmbuild/BUILD/r8101-1.027.00/src/r8101_n.o
   /home/build/rpmbuild/BUILD/r8101-1.027.00/src/r8101_n.c: In function
   'rtl8101_start_xmit':
   /home/build/rpmbuild/BUILD/r8101-1.027.00/src/r8101_n.c:11430:12:
   error: 'struct net_device' has no member named 'trans_start'
 dev->trans_start = jiffies;
    ^
   make[1]: ***
   [/home/build/rpmbuild/BUILD/r8101-1.027.00/src/r8101_n.o] Error 1
   make: *** [_module_/home/build/rpmbuild/BUILD/r8101-1.027.00/src]
   Error 2
   make: Leaving directory `/usr/src/kernels/3.10.0-693.2.2.v7.x86_64'
   error: Bad exit status from /var/tmp/rpm-tmp.q2MdHK (%build)

I don't particularly need it but I wanted to make a proposal about the 
r8168 and r8169 drivers from my previous correspondence and I needed the 
PCI-ID's from this one for completeness.


Regards,

Nick

On 07/10/2017 21:51, Nick Howitt wrote:

One correction below.

From the testing I've done this evening, removing the blacklisting is 
important and it make sense to make the kmod-r8168 require the kmod-r8169.


The situation is this. If you update to the two latest r8168 and r8169 
drivers, all weak links to older (7.3) kernels are removed. If you 
then boot to one of the older kernels, neither NIC get a driver as the 
stock r8169 is blacklisted. If the blacklist is not there then booting 
to the old kernel has both NICs still working on the stock r8169 
driver - not ideal for the r8168 card but better than nothing and at 
least both NICs are working. In the new kernel there is no need for 
the blacklist either as the kmod-r8169 cannot load against the r8168 
card because of the altered PCI ID's and, without the blacklist, it 
will load correctly against r8169 cards.


On 07/10/2017 13:06, Nick Howitt wrote:



On 07/10/2017 12:35, Phil Perry wrote:


On 06/10/17 13:45, Nick Howitt wrote:

Hi Phil,

One thing I noticed in the summer last year but did not isolate at 
all was that when I was running both the r8168 and r8169 drivers in 
a box which had both cards, the 8169 NIC would not come up on boot 
and had to be modprobed after boot. I got round it by:




That may be because our kmod-r8168 blacklists the r8169 driver from 
loading and binding the device (see below).


Hmm. That sounds dangerous and messes things up when you have both 
cards, or, in my case a motherboard with an r8168 on-board NIC and a 
PCI r8169 NIC. I did not realise you blacklisted the r8169. I have a 
suggestion. The kmod-r8169 driver comes with PCI-IDs removed for the 
r8168 so it will never load against the r8168. If you remove the 
blacklisting of the r8169 from the r8168 package, but instead put a 
dependency on the kmod-r8169 driver, then you have utopia. If you 
install the r8169 it will force the installation of the r8169 as well 
and in an environment with both NICs, both drivers will load against 
the correct NIC.
Should read: If you install the r8168, it will force the installation 
of the r8169 as well and in an environment with both NICs, both 
drivers will load against the correct NIC.

echo "modprobe r8169" > /etc/sysconfig/modules/r8169.modules
chmod +x /etc/sysconfig/modules/r8169.modules
 > This got the driver to load much earlier in the boot sequence.

The person who tested the via-rhine driver found the same here: 
https://www.clearos.com/clearfoundation/social/community/clearos-7-4-beta#reply-190651 
(and the following post) with drivers compiled for 7.4.




What does lsinitrd say for the kernel in question? Are the 
appropriate drivers present in the initramfs?
I'm about to rebuild my old box so I'll have a look. I've never used 
the command before


IIRC, the issue with r8168/9 is complicated by the fact that the 
distro kernel r8169 driver is a unified driver that supports some 
hardware also supported by the kmod-r8168 driver, so the two are not 
designed to be used together as they may compete to bind the same 
device on boot.
Yes, the stock r8169 driver has the PCI IDs for the r8168. I *think* 
if you install the kmod-r8169 it takes precedence over the stock. 
Certainly a modinfo only returns results for the kmod driver


My network config/admin skills are not great. Maybe there is a way 
to designate/bind a specific driver to a device to ensure you get 
the expected behaviour?


I don't have the knowledge either, but I think what I proposed would 
work

___
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




___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mail

Re: [elrepo] More 7.4 incompatible drivers

[Nick Howitt]

  
  
One correction below.

From the testing I've done this evening, removing the blacklisting
is important and it make sense to make the kmod-r8168 require the
kmod-r8169.

The situation is this. If you update to the two latest r8168 and
r8169 drivers, all weak links to older (7.3) kernels are removed. If
you then boot to one of the older kernels, neither NIC get a driver
as the stock r8169 is blacklisted. If the blacklist is not there
then booting to the old kernel has both NICs still working on the
stock r8169 driver - not ideal for the r8168 card but better than
nothing and at least both NICs are working. In the new kernel there
is no need for the blacklist either as the kmod-r8169 cannot load
against the r8168 card because of the altered PCI ID's and, without
the blacklist, it will load correctly against r8169 cards.

On 07/10/2017 13:06, Nick Howitt wrote:


  
  
  On 07/10/2017 12:35, Phil Perry wrote:
  
  

On 06/10/17 13:45, Nick Howitt wrote:

Hi Phil,
  
  
  One thing I noticed in the summer last year but did not
  isolate at all was that when I was running both the r8168 and
  r8169 drivers in a box which had both cards, the 8169 NIC
  would not come up on boot and had to be modprobed after boot.
  I got round it by:
  
  


That may be because our kmod-r8168 blacklists the r8169 driver
from loading and binding the device (see below).


  
  Hmm. That sounds dangerous and messes things up when you have both
  cards, or, in my case a motherboard with an r8168 on-board NIC and
  a PCI r8169 NIC. I did not realise you blacklisted the r8169. I
  have a suggestion. The kmod-r8169 driver comes with PCI-IDs
  removed for the r8168 so it will never load against the r8168. If
  you remove the blacklisting of the r8169 from the r8168 package,
  but instead put a dependency on the kmod-r8169 driver, then you
  have utopia. If you install the r8169 it will force the
  installation of the r8169 as well and in an environment with both
  NICs, both drivers will load against the correct NIC.
  

Should read: If you install the r8168, it will force the
installation of the r8169 as well and in an environment with both
NICs, both drivers will load against the correct NIC. 

  
echo "modprobe r8169" >
  /etc/sysconfig/modules/r8169.modules
  
  chmod +x /etc/sysconfig/modules/r8169.modules
  
   > This got the driver to load much earlier in the boot
  sequence.
  
  
  The person who tested the via-rhine driver found the same
  here:
https://www.clearos.com/clearfoundation/social/community/clearos-7-4-beta#reply-190651
  (and the following post) with drivers compiled for 7.4.
  
  


What does lsinitrd say for the kernel in question? Are the
appropriate drivers present in the initramfs?

  
  I'm about to rebuild my old box so I'll have a look. I've never
  used the command before
  
  

IIRC, the issue with r8168/9 is complicated by the fact that the
distro kernel r8169 driver is a unified driver that supports
some hardware also supported by the kmod-r8168 driver, so the
two are not designed to be used together as they may compete to
bind the same device on boot.

  
  Yes, the stock r8169 driver has the PCI IDs for the r8168. I
  *think* if you install the kmod-r8169 it takes precedence over the
  stock. Certainly a modinfo only returns results for the kmod
  driver
  
  

My network config/admin skills are not great. Maybe there is a
way to designate/bind a specific driver to a device to ensure
you get the expected behaviour?


  
  I don't have the knowledge either, but I think what I proposed
  would work
  
  ___

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
  


  

___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] More 7.4 incompatible drivers

[Nick Howitt]

On 07/10/2017 12:35, Phil Perry wrote:


On 06/10/17 13:45, Nick Howitt wrote:

Hi Phil,

One thing I noticed in the summer last year but did not isolate at 
all was that when I was running both the r8168 and r8169 drivers in a 
box which had both cards, the 8169 NIC would not come up on boot and 
had to be modprobed after boot. I got round it by:




That may be because our kmod-r8168 blacklists the r8169 driver from 
loading and binding the device (see below).


Hmm. That sounds dangerous and messes things up when you have both 
cards, or, in my case a motherboard with an r8168 on-board NIC and a PCI 
r8169 NIC. I did not realise you blacklisted the r8169. I have a 
suggestion. The kmod-r8169 driver comes with PCI-IDs removed for the 
r8168 so it will never load against the r8168. If you remove the 
blacklisting of the r8169 from the r8168 package, but instead put a 
dependency on the kmod-r8169 driver, then you have utopia. If you 
install the r8169 it will force the installation of the r8169 as well 
and in an environment with both NICs, both drivers will load against the 
correct NIC.

echo "modprobe r8169" > /etc/sysconfig/modules/r8169.modules
chmod +x /etc/sysconfig/modules/r8169.modules
 > This got the driver to load much earlier in the boot sequence.

The person who tested the via-rhine driver found the same here: 
https://www.clearos.com/clearfoundation/social/community/clearos-7-4-beta#reply-190651 
(and the following post) with drivers compiled for 7.4.




What does lsinitrd say for the kernel in question? Are the appropriate 
drivers present in the initramfs?
I'm about to rebuild my old box so I'll have a look. I've never used the 
command before


IIRC, the issue with r8168/9 is complicated by the fact that the 
distro kernel r8169 driver is a unified driver that supports some 
hardware also supported by the kmod-r8168 driver, so the two are not 
designed to be used together as they may compete to bind the same 
device on boot.
Yes, the stock r8169 driver has the PCI IDs for the r8168. I *think* if 
you install the kmod-r8169 it takes precedence over the stock. Certainly 
a modinfo only returns results for the kmod driver


My network config/admin skills are not great. Maybe there is a way to 
designate/bind a specific driver to a device to ensure you get the 
expected behaviour?



I don't have the knowledge either, but I think what I proposed would work

___
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

Re: [elrepo] More 7.4 incompatible drivers

[Nick Howitt]

Hi Phil,

One thing I noticed in the summer last year but did not isolate at all 
was that when I was running both the r8168 and r8169 drivers in a box 
which had both cards, the 8169 NIC would not come up on boot and had to 
be modprobed after boot. I got round it by:


echo "modprobe r8169" > /etc/sysconfig/modules/r8169.modules
chmod +x /etc/sysconfig/modules/r8169.modules

This got the driver to load much earlier in the boot sequence.

The person who tested the via-rhine driver found the same here: 
https://www.clearos.com/clearfoundation/social/community/clearos-7-4-beta#reply-190651 
(and the following post) with drivers compiled for 7.4.


Regards,

Nick

On 04/10/2017 19:45, Phil Perry wrote:


On 04/10/17 14:19, Nick Howitt wrote:

Hi Phil,

As the r8169 does not carry 7_4 in its file name, does that mean it 
is backwards compatible with earlier kernels/versions of EL7?


Regards,

Nick



No, the newly built package is only compatible with the 7.4 kernel, 
but I didn't know that at the time of rebuilding it.


Phil
___
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

Re: [elrepo] More 7.4 incompatible drivers

[Nick Howitt]

Hi Phil,

As the r8169 does not carry 7_4 in its file name, does that mean it is 
backwards compatible with earlier kernels/versions of EL7?


Regards,

Nick

On 2017-10-03 08:06, Nick Howitt wrote:

Hi Phil,

Thanks for these. I'll get them built as soon as possible then try to
track down the people who requested them to test.

Regards,

Nick

On 2017-10-02 21:04, Phil Perry wrote:

On 01/10/17 20:12, Phil Perry wrote:

On 01/10/17 17:04, Nick Howitt wrote:

Hi Phil,

I've been through all the kmod drivers I've compiled for 7.3 and 
tried compiling them against ClearOS 7.4. Four of them have failed 
to compile:

ath10k


ath10k was included in RHEL from 7.3 onwards so we have deprecated 
our driver in favour of the distro kernel driver.



ne2k-pci


ne2k-pci should be the same fix as via-rhine.


r8169


again, looks like the same fix as via-rhine.


rtl8723be


rtl8723be was included in RHEL from 7.3 onwards so we have deprecated 
our driver in favour of the distro kernel driver.


I'll look to push out updates for ne2k-pci and r8169.

In addition to those above, I note from grepping my source code tree 
the following drivers may also be affected by the 'trans_start' 
issue:


3c59x
lan78xx
mptfc
sis900

although 3 of the 4 do weak link against 7.4 series kernels. I will 
most likely wait for bug reports and fix them should they arise.


Phil



I've rebuilt the following ethernet drivers against RHEL 7.4.
kmod-ne2k-pci needed rebuilding as it was not compatible with 7.4, and
for the others I've taken the opportunity to fix build errors when
rebuilding against RHEL 7.4, but otherwise haven't updated the driver.

kmod-3c59x-0.0-3.el7.elrepo.x86_64.rpm
kmod-ne2k-pci-1.03-3.el7_4.elrepo.x86_64.rpm
kmod-r8169-6.020.00-2.el7.elrepo.x86_64.rpm
kmod-sis900-1.08.10-2.el7.elrepo.x86_64.rpm

Packages are currently syncing to the main elrepo repository.

Phil

___
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

___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] More 7.4 incompatible drivers

[Nick Howitt]

Hi Phil,

Thanks for these. I'll get them built as soon as possible then try to 
track down the people who requested them to test.


Regards,

Nick

On 2017-10-02 21:04, Phil Perry wrote:

On 01/10/17 20:12, Phil Perry wrote:

On 01/10/17 17:04, Nick Howitt wrote:

Hi Phil,

I've been through all the kmod drivers I've compiled for 7.3 and 
tried compiling them against ClearOS 7.4. Four of them have failed to 
compile:

ath10k


ath10k was included in RHEL from 7.3 onwards so we have deprecated our 
driver in favour of the distro kernel driver.



ne2k-pci


ne2k-pci should be the same fix as via-rhine.


r8169


again, looks like the same fix as via-rhine.


rtl8723be


rtl8723be was included in RHEL from 7.3 onwards so we have deprecated 
our driver in favour of the distro kernel driver.


I'll look to push out updates for ne2k-pci and r8169.

In addition to those above, I note from grepping my source code tree 
the following drivers may also be affected by the 'trans_start' issue:


3c59x
lan78xx
mptfc
sis900

although 3 of the 4 do weak link against 7.4 series kernels. I will 
most likely wait for bug reports and fix them should they arise.


Phil



I've rebuilt the following ethernet drivers against RHEL 7.4.
kmod-ne2k-pci needed rebuilding as it was not compatible with 7.4, and
for the others I've taken the opportunity to fix build errors when
rebuilding against RHEL 7.4, but otherwise haven't updated the driver.

kmod-3c59x-0.0-3.el7.elrepo.x86_64.rpm
kmod-ne2k-pci-1.03-3.el7_4.elrepo.x86_64.rpm
kmod-r8169-6.020.00-2.el7.elrepo.x86_64.rpm
kmod-sis900-1.08.10-2.el7.elrepo.x86_64.rpm

Packages are currently syncing to the main elrepo repository.

Phil

___
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

Re: [elrepo] More 7.4 incompatible drivers

[Nick Howitt]

  
  
Hi Phil,

When my box updates (normally a couple of weeks behind the Community
full release) I can check about the r8169 and the weak links. At
some time I would have thought the package would need rebuilding
otherwise anyone wanting to compile from sources would need to
downgrade their kernel and, unless they bump into this thread, they
would not know that.

Regards,

Nick

On 01/10/2017 20:42, Phil Perry wrote:

Looking
  at kmod-r8169, I'm not sure it needs rebuilding for el7.4. The
  current package weak-links against the 7.4 series kernels:
  
  
  $ find /lib/modules/ -name r8169.ko | sort | grep 'extra\|weak'
  
  /lib/modules/3.10.0-123.el7.x86_64/extra/r8169/r8169.ko
  
  /lib/modules/3.10.0-327.el7.x86_64/weak-updates/r8169/r8169.ko
  
  /lib/modules/3.10.0-514.el7.x86_64/weak-updates/r8169/r8169.ko
  
  /lib/modules/3.10.0-693.2.1.el7.x86_64/weak-updates/r8169/r8169.ko
  
  /lib/modules/3.10.0-693.2.2.el7.x86_64/weak-updates/r8169/r8169.ko
  
  /lib/modules/3.10.0-693.el7.x86_64/weak-updates/r8169/r8169.ko
  
  
  $ uname -a
  
  Linux Chroot64R7 3.10.0-693.2.2.el7.x86_64 #1 SMP Sat Sep 9
  03:55:24 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux
  
  
  $ sudo modprobe r8169
  
  
  [117739.817760] Request for unknown module key 'The ELRepo Project
  (http://elrepo.org): ELRepo.org Secure Boot Key:
  f365ad3481a7b20e3427b61b2a26635b83fe427b' err -11
  
  [117739.817770] r8169: loading out-of-tree module taints kernel.
  
  [117739.817808] r8169: module verification failed: signature
  and/or required key missing - tainting kernel
  
  
  I don't have the hardware to test, but the module is present and
  loads into the kernel just fine.
  
  


  

___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] More 7.4 incompatible drivers

[Nick Howitt]

  
  
Hi Phil,

Thanks for looking at it. I'll remove my ath10k and rtl8723be
drivers. I thought you may have a quicker way of scanning all the
sources for the issue. I was going to append that the forcedeth
driver also compiles without change on 7.4 but effectively you've
already found that out.

I am not sure how I can get the two drivers tested. I use the r8169
driver just to remove r8168 driver compatibility and I don't think I
can use my production box for the ClearOS beta release. I'll have to
check with the devs.

I'll also have to trace the ne2k-pci user and try and get them a
message if they follow the forums. If not, I guess they'll be back
pretty soon asking why their box does not work any more!

Regards,

Nick

On 01/10/2017 20:12, Phil Perry wrote:


  
  On 01/10/17 17:04, Nick Howitt wrote:
  
  Hi Phil,


I've been through all the kmod drivers I've compiled for 7.3 and
tried compiling them against ClearOS 7.4. Four of them have
failed to compile:

ath10k

  
  
  ath10k was included in RHEL from 7.3 onwards so we have deprecated
  our driver in favour of the distro kernel driver.
  
  
  ne2k-pci

  
  
  ne2k-pci should be the same fix as via-rhine.
  
  
  r8169

  
  
  again, looks like the same fix as via-rhine.
  
  
  rtl8723be

  
  
  rtl8723be was included in RHEL from 7.3 onwards so we have
  deprecated our driver in favour of the distro kernel driver.
  
  
  I'll look to push out updates for ne2k-pci and r8169.
  
  
  In addition to those above, I note from grepping my source code
  tree the following drivers may also be affected by the
  'trans_start' issue:
  
  
  3c59x
  
  lan78xx
  
  mptfc
  
  sis900
  
  
  although 3 of the 4 do weak link against 7.4 series kernels. I
  will most likely wait for bug reports and fix them should they
  arise.
  
  
  Phil
  
  
  ___
  
  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

[elrepo] More 7.4 incompatible drivers

[Nick Howitt]

Hi Phil,

I've been through all the kmod drivers I've compiled for 7.3 and tried 
compiling them against ClearOS 7.4. Four of them have failed to compile:

ath10k
ne2k-pci
r8169
rtl8723be

Of these I am most concerned about the r8169 as it is needed to remove 
compatibility with r8168 cards. Without it, the stock r8169 driver can 
still be loaded in preference to the r8168 driver for RTL8111/8168 
NIC's. I would really appreciate a fix for it and possibly the others.


The error logs are below:

*_r8169_*
+ cd r8169-6.020.00
+ KSRC=/usr/src/kernels/3.10.0-693.2.2.v7.x86_64
+ /usr/bin/make -C /usr/src/kernels/3.10.0-693.2.2.v7.x86_64 modules 
M=/home/build/rpmbuild/BUILD/r8169-6.020.00/src

make: Entering directory `/usr/src/kernels/3.10.0-693.2.2.v7.x86_64'
  CC [M]  /home/build/rpmbuild/BUILD/r8169-6.020.00/src/r8169_n.o
/home/build/rpmbuild/BUILD/r8169-6.020.00/src/r8169_n.c: In function 
'rtl8169_start_xmit':
/home/build/rpmbuild/BUILD/r8169-6.020.00/src/r8169_n.c:3767:12: error: 
'struct net_device' has no member named 'trans_start'

 dev->trans_start = jiffies;
    ^
make[1]: *** [/home/build/rpmbuild/BUILD/r8169-6.020.00/src/r8169_n.o] 
Error 1

make: *** [_module_/home/build/rpmbuild/BUILD/r8169-6.020.00/src] Error 2
make: Leaving directory `/usr/src/kernels/3.10.0-693.2.2.v7.x86_64'
error: Bad exit status from /var/tmp/rpm-tmp.dc2V8t (%build)

*_Ath10k_*
make: Entering directory `/usr/src/kernels/3.10.0-693.2.2.v7.x86_64'
  CC [M]  /home/build/rpmbuild/BUILD/ath10k-0.0/main.o
In file included from /home/build/rpmbuild/BUILD/ath10k-0.0/main.c:22:0:
/home/build/rpmbuild/BUILD/ath10k-0.0/ath.h:188:41: error: 
'IEEE80211_NUM_BANDS' undeclared here (not in a function)

  struct ieee80211_supported_band sbands[IEEE80211_NUM_BANDS];
 ^
make[1]: *** [/home/build/rpmbuild/BUILD/ath10k-0.0/main.o] Error 1
make: *** [_module_/home/build/rpmbuild/BUILD/ath10k-0.0] Error 2
make: Leaving directory `/usr/src/kernels/3.10.0-693.2.2.v7.x86_64'
error: Bad exit status from /var/tmp/rpm-tmp.p8A24n (%build)

*_ne2k-pci_*
+ cd ne2k-pci-1.03
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ echo 'override ne2k-pci * weak-updates/ne2k-pci'
+ echo 'override 8390 * weak-updates/ne2k-pci'
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.q5cYVI
+ umask 022
+ cd /home/build/rpmbuild/BUILD
+ cd ne2k-pci-1.03
+ KSRC=/usr/src/kernels/3.10.0-693.2.2.v7.x86_64
+ /usr/bin/make -C /usr/src/kernels/3.10.0-693.2.2.v7.x86_64 modules 
M=/home/build/rpmbuild/BUILD/ne2k-pci-1.03

make: Entering directory `/usr/src/kernels/3.10.0-693.2.2.v7.x86_64'
  CC [M]  /home/build/rpmbuild/BUILD/ne2k-pci-1.03/ne2k-pci.o
  CC [M]  /home/build/rpmbuild/BUILD/ne2k-pci-1.03/8390.o
In file included from /home/build/rpmbuild/BUILD/ne2k-pci-1.03/8390.c:6:0:
/home/build/rpmbuild/BUILD/ne2k-pci-1.03/lib8390.c: In function 
'ei_tx_intr':
/home/build/rpmbuild/BUILD/ne2k-pci-1.03/lib8390.c:596:7: error: 'struct 
net_device' has no member named 'trans_start'

    dev->trans_start = jiffies;
   ^
/home/build/rpmbuild/BUILD/ne2k-pci-1.03/lib8390.c:609:7: error: 'struct 
net_device' has no member named 'trans_start'

    dev->trans_start = jiffies;
   ^
make[1]: *** [/home/build/rpmbuild/BUILD/ne2k-pci-1.03/8390.o] Error 1
make: *** [_module_/home/build/rpmbuild/BUILD/ne2k-pci-1.03] Error 2
make: Leaving directory `/usr/src/kernels/3.10.0-693.2.2.v7.x86_64'
error: Bad exit status from /var/tmp/rpm-tmp.q5cYVI (%build)

*_rtl8723be_*
+ cd rtl8723be-0.0
+ KSRC=/usr/src/kernels/3.10.0-693.2.2.v7.x86_64
+ /usr/bin/make -C /usr/src/kernels/3.10.0-693.2.2.v7.x86_64 modules 
M=/home/build/rpmbuild/BUILD/rtl8723be-0.0

make: Entering directory `/usr/src/kernels/3.10.0-693.2.2.v7.x86_64'
  CC [M]  /home/build/rpmbuild/BUILD/rtl8723be-0.0/pci.o
In file included from /home/build/rpmbuild/BUILD/rtl8723be-0.0/pci.c:30:0:
/home/build/rpmbuild/BUILD/rtl8723be-0.0/wifi.h:1349:40: error: 
'IEEE80211_NUM_BANDS' undeclared here (not in a function)

  struct ieee80211_supported_band bands[IEEE80211_NUM_BANDS];
    ^
make[1]: *** [/home/build/rpmbuild/BUILD/rtl8723be-0.0/pci.o] Error 1
make: *** [_module_/home/build/rpmbuild/BUILD/rtl8723be-0.0] Error 2
make: Leaving directory `/usr/src/kernels/3.10.0-693.2.2.v7.x86_64'
error: Bad exit status from /var/tmp/rpm-tmp.kAtiW5 (%build)

For completeness, the ones which compiled OK were:
aic7xxx
ax88179
cciss (not a NIC)
sis190

Regards,

Nick

Regards,

Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] Via-rhine driver on 7.4

[Nick Howitt]

*** sorry, the last reply went off-list so I'm replying again ***

Hi Phil,

The updated via-rhine driver is looking good. Confirmation is here: 
https://www.clearos.com/clearfoundation/social/community/clearos-7-4-beta#reply-190191 



I've hit more compatibility issues, but I'll post to another thread.

Regards,

Nick

On 30/09/2017 16:06, Phil Perry wrote:

Thanks, that would be hugely appreciated.

Phil

On 30/09/17 15:54, Nick Howitt wrote:

Hi Phil,

Thanks very much for that. The user who had the issue is way more 
capable than me so I'll see if he can test it and give feedback to 
enable you to promote it.


Regards,

Nick

On 30/09/2017 15:30, Phil Perry wrote:


On 30/09/17 15:19, Nick Howitt wrote:

Hi Phil,

Thanks for looking at it.

I must apologise as I forgot to mention I am using ClearOS which 
has a slightly different kernel from RHEL/Centos (IMQ is patched in).


The original poster on our forums posted back to say the kernel 
upgrade + symlinks then worked on his three subsequent systems as 
did reinstalling the compiled rpm on the system where the symlinks 
weren't created. Reference 
<https://www.clearos.com/clearfoundation/social/community/clearos-7-4-beta#reply-190091>. 
He has the same problems compiling, but at least the drivers 
compiled under 7.3 appear to be working on 7.4.


Regards,

Nick



Thanks for the feedback Nick.

For reference, the build issues on el7.4 were easy enough to fix, so 
I have fixed those and rebuilt the package against the RHEL 7.4 
kernel and released it to our testing repository here:


kmod-via-rhine-1.5.1-3.el7_4.elrepo.x86_64.rpm

I note the newly built package is only compatible with 7.4 series 
kernels and is not backward compatible with earlier kernels.


For reference, the fix is:

-    dev->trans_start = jiffies; /* prevent tx timeout */
+    netif_trans_update(dev); /* prevent tx timeout */

This was a treewide patch applied upstream in 2016, and presumably 
backported to the RHEL7.4 kernel, so potentially affects a number of 
elrepo drivers using trans_start updates.


If your user has any issues with the driver, I would apply the above 
fix and rebuild against your 7.4 kernel.


Phil

___
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


___
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

Re: [elrepo] Via-rhine driver on 7.4

[Nick Howitt]

Hi Phil,

Thanks very much for that. The user who had the issue is way more 
capable than me so I'll see if he can test it and give feedback to 
enable you to promote it.


Regards,

Nick

On 30/09/2017 15:30, Phil Perry wrote:


On 30/09/17 15:19, Nick Howitt wrote:

Hi Phil,

Thanks for looking at it.

I must apologise as I forgot to mention I am using ClearOS which has 
a slightly different kernel from RHEL/Centos (IMQ is patched in).


The original poster on our forums posted back to say the kernel 
upgrade + symlinks then worked on his three subsequent systems as did 
reinstalling the compiled rpm on the system where the symlinks 
weren't created. Reference 
<https://www.clearos.com/clearfoundation/social/community/clearos-7-4-beta#reply-190091>. 
He has the same problems compiling, but at least the drivers compiled 
under 7.3 appear to be working on 7.4.


Regards,

Nick



Thanks for the feedback Nick.

For reference, the build issues on el7.4 were easy enough to fix, so I 
have fixed those and rebuilt the package against the RHEL 7.4 kernel 
and released it to our testing repository here:


kmod-via-rhine-1.5.1-3.el7_4.elrepo.x86_64.rpm

I note the newly built package is only compatible with 7.4 series 
kernels and is not backward compatible with earlier kernels.


For reference, the fix is:

-    dev->trans_start = jiffies; /* prevent tx timeout */
+    netif_trans_update(dev); /* prevent tx timeout */

This was a treewide patch applied upstream in 2016, and presumably 
backported to the RHEL7.4 kernel, so potentially affects a number of 
elrepo drivers using trans_start updates.


If your user has any issues with the driver, I would apply the above 
fix and rebuild against your 7.4 kernel.


Phil

___
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

Re: [elrepo] Via-rhine driver on 7.4

[Nick Howitt]

Hi Phil,

Thanks for looking at it.

I must apologise as I forgot to mention I am using ClearOS which has a 
slightly different kernel from RHEL/Centos (IMQ is patched in).


The original poster on our forums posted back to say the kernel upgrade 
+ symlinks then worked on his three subsequent systems as did 
reinstalling the compiled rpm on the system where the symlinks weren't 
created. Reference 
<https://www.clearos.com/clearfoundation/social/community/clearos-7-4-beta#reply-190091>. 
He has the same problems compiling, but at least the drivers compiled 
under 7.3 appear to be working on 7.4.


Regards,

Nick

On 30/09/2017 12:12, Phil Perry wrote:

On 29/09/17 19:42, Nick Howitt wrote:

Hi,
I've had a report that this driver does not set up the weak-updates 
symlinks when upgrading from a 7.3 kernel to a 7.4 kernel but is 
seems to function OK you you create the symlinks yourself. I've tried 
compiling the 1.5.1-2 source against the 7.4 kernel and it also fails 
with:


    make: Entering directory `/usr/src/kernels/3.10.0-693.2.2.v7.x86_64'
   CC [M] /home/build/rpmbuild/BUILD/via-rhine-1.5.1/via-rhine.o
    /home/build/rpmbuild/BUILD/via-rhine-1.5.1/via-rhine.c: In function
    'rhine_reset_task':
/home/build/rpmbuild/BUILD/via-rhine-1.5.1/via-rhine.c:1638:5:
    error: 'struct net_device' has no member named 'trans_start'
   dev->trans_start = jiffies; /* prevent tx timeout */
  ^
    make[1]: ***
    [/home/build/rpmbuild/BUILD/via-rhine-1.5.1/via-rhine.o] Error 1
    make: *** [_module_/home/build/rpmbuild/BUILD/via-rhine-1.5.1] 
Error 2

    make: Leaving directory `/usr/src/kernels/3.10.0-693.2.2.v7.x86_64'
    error: Bad exit status from /var/tmp/rpm-tmp.32hFWR (%build)


    RPM build errors:
     via-rhine-kmod-1.5.1-2.el7.elrepo.src.rpm: Header V4 DSA/SHA1
    Signature, key ID baadae52: NOKEY
     user phil does not exist - using root
     group phil does not exist - using root
     user phil does not exist - using root
     group phil does not exist - using root
     user phil does not exist - using root
     group phil does not exist - using root
     user phil does not exist - using root
     group phil does not exist - using root
     Bad exit status from /var/tmp/rpm-tmp.32hFWR (%build)

Have you any idea how to fix it?

Regards,

Nick



Hi Nick,

I'm unable to replicate this on our RHEL7.4 test system. I installed 
the latest package from the elrepo repository:


$ rpm -q kmod-via-rhine
kmod-via-rhine-1.5.1-2.el7.elrepo.x86_64

and I see the appropriate symlinks created against installed 7.4 
series kernels:


$ rpm -qa kernel | sort
kernel-3.10.0-327.el7.x86_64
kernel-3.10.0-514.el7.x86_64
kernel-3.10.0-693.2.1.el7.x86_64
kernel-3.10.0-693.2.2.el7.x86_64
kernel-3.10.0-693.el7.x86_64


$ find /lib/modules/ -name via-rhine.ko
/lib/modules/3.10.0-327.el7.x86_64/extra/via-rhine/via-rhine.ko
/lib/modules/3.10.0-514.el7.x86_64/weak-updates/via-rhine/via-rhine.ko
/lib/modules/3.10.0-693.el7.x86_64/weak-updates/via-rhine/via-rhine.ko
/lib/modules/3.10.0-693.2.1.el7.x86_64/weak-updates/via-rhine/via-rhine.ko 

/lib/modules/3.10.0-693.2.2.el7.x86_64/weak-updates/via-rhine/via-rhine.ko 



I don't have the hardware to test, but I can load the module with 
modprobe:



Sep 30 06:53:10 [localhost] kernel: Request for unknown module key 
'The ELRepo Project (http://elrepo.org): ELRepo.org Secure Boot Key: 
f365ad3481a7b20e3427b61b2a26635b83fe427b' err -11
Sep 30 06:53:10 [localhost] kernel: via_rhine: loading out-of-tree 
module taints kernel.
Sep 30 06:53:10 [localhost] kernel: via_rhine: module verification 
failed: signature and/or required key missing - tainting kernel
Sep 30 06:53:10 [localhost] kernel: via_rhine: v1.10-LK1.5.1 
2010-10-09 Written by Donald Becker



$ lsmod | grep via
via_rhine  32583  0
mii    13934  1 via_rhine


So apart from not actually being able to test the module works, I 
don't see anything amiss here.


Perhaps you could try uninstalling and reinstalling the module and 
checking to see if the symlinks in weak-updates are created.


I can confirm that I see the same error when trying to rebuild against 
the 7.4 series kernel. If you don't get any joy with the above, I can 
certainly look to see if we can fix those build errors on el7.4.


Phil



___
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

[elrepo] Via-rhine driver on 7.4

[Nick Howitt]

Hi,
I've had a report that this driver does not set up the weak-updates 
symlinks when upgrading from a 7.3 kernel to a 7.4 kernel but is seems 
to function OK you you create the symlinks yourself. I've tried 
compiling the 1.5.1-2 source against the 7.4 kernel and it also fails with:


   make: Entering directory `/usr/src/kernels/3.10.0-693.2.2.v7.x86_64'
  CC [M]  /home/build/rpmbuild/BUILD/via-rhine-1.5.1/via-rhine.o
   /home/build/rpmbuild/BUILD/via-rhine-1.5.1/via-rhine.c: In function
   'rhine_reset_task':
   /home/build/rpmbuild/BUILD/via-rhine-1.5.1/via-rhine.c:1638:5:
   error: 'struct net_device' has no member named 'trans_start'
  dev->trans_start = jiffies; /* prevent tx timeout */
 ^
   make[1]: ***
   [/home/build/rpmbuild/BUILD/via-rhine-1.5.1/via-rhine.o] Error 1
   make: *** [_module_/home/build/rpmbuild/BUILD/via-rhine-1.5.1] Error 2
   make: Leaving directory `/usr/src/kernels/3.10.0-693.2.2.v7.x86_64'
   error: Bad exit status from /var/tmp/rpm-tmp.32hFWR (%build)


   RPM build errors:
    via-rhine-kmod-1.5.1-2.el7.elrepo.src.rpm: Header V4 DSA/SHA1
   Signature, key ID baadae52: NOKEY
    user phil does not exist - using root
    group phil does not exist - using root
    user phil does not exist - using root
    group phil does not exist - using root
    user phil does not exist - using root
    group phil does not exist - using root
    user phil does not exist - using root
    group phil does not exist - using root
    Bad exit status from /var/tmp/rpm-tmp.32hFWR (%build)

Have you any idea how to fix it?

Regards,

Nick
___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] aacraid build errors

[Nick Howitt]

  
  
Hi Phil,
Thanks for looking at it. Please don't waste any more time on it.
We've realised the particular Adaptec card we had can only handle
2TB arrays which is nothing these days! mdadm on standard SATA ports
will probably be the solution.
Regards,
Nick

On 12/08/2017 11:34, Phil Perry wrote:


  
  On 12/08/17 09:28, Nick Howitt wrote:
  
  Hi,


  
  
  Hi Nick,
  
  
  I am trying to build the aacraid-1.2.1-x
driver in ClearOS 7.3 (Centos 7.3 derivative) and I'm getting
the following errors:


  
  
  I see the same errors when trying to rebuild
  kmod-aacraid-1.2.1-6.el7.elrepo against
  kernel-3.10.0-514.26.2.el7.x86_64
  
  
  Our original package was built against the RHEL 7.1 kernel and has
  been compatible with kernels up to the el7.3 series. However it is
  not compatible with the RHEL7.4 kernel and I see the same errors
  trying to build it for RHEL7.4.
  
  
  That said, the native kernel driver in RHEL is now newer than our
  driver so we plan to deprecate kmod-aacraid in favour of using the
  distro kernel driver.
  
  
  So your choices are to rebuild the existing package against an
  older kernel and it should work for you on your
  3.10.0-514.26.2.el7.x86_64 kernel (assuming you retain binary
  compatibility with the kernel subsystems used by the aacraid
  driver) or use the distro kernel driver (recommended).
  
  
  Phil
  
  
  ___
  
  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

[elrepo] aacraid build errors

[Nick Howitt]

  
  
Hi,

I am trying to build the aacraid-1.2.1-x driver in ClearOS 7.3
(Centos 7.3 derivative) and I'm getting the following errors:

Installing aacraid-kmod-1.2.1-6.el7.elrepo.src.rpm
  warning: aacraid-kmod-1.2.1-6.el7.elrepo.src.rpm: Header V4
DSA/SHA1 Signature, key ID baadae52: NOKEY
  
  Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.NXEMsi
  + umask 022
  + cd /home/build/rpmbuild/BUILD
  + cd /home/build/rpmbuild/BUILD
  + rm -rf aacraid-1.2.1-40700
  + /usr/bin/mkdir -p aacraid-1.2.1-40700
  + cd aacraid-1.2.1-40700
  + /usr/bin/gzip -dc
/home/build/rpmbuild/SOURCES/aacraid-linux-src-1.2.1-40700.tgz
  + /usr/bin/tar -xf -
  + STATUS=0
  + '[' 0 -ne 0 ']'
  + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
  + rpm2cpio aacraid-1.2.1-40700.src.rpm
  + /usr/bin/cpio -Bcdimu
  46 blocks
  + /usr/bin/mkdir aacraid_source
  + pushd aacraid_source
  + /usr/bin/tar -zxf ../aacraid_source.tgz
  + /usr/bin/chmod 664 CHANGELOG Makefile README
README.ServeRAID TODO VMware-3.0.1.c VMware-3.0.2.c VMware-3.0.c
VMware-3.5.c VMware.c aachba.c aacraid.h commctrl.c comminit.c
commsup.c compat.h csmi.c csmi.h dpcsup.c frey.c fwdebug.c
fwdebug.h linit.c nark.c rkt.c rx.c sa.c src.c
  + popd
  + echo 'override aacraid * weak-updates/aacraid'
  + exit 0
  Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.8F8I2M
  + umask 022
  + cd /home/build/rpmbuild/BUILD
  + cd aacraid-1.2.1-40700
  + KSRC=/usr/src/kernels/3.10.0-514.26.2.v7.x86_64
  + /usr/bin/make -C /usr/src/kernels/3.10.0-514.26.2.v7.x86_64
-j4 modules
M=/home/build/rpmbuild/BUILD/aacraid-1.2.1-40700/aacraid_source
  make: Entering directory
`/usr/src/kernels/3.10.0-514.26.2.v7.x86_64'
    CC [M] 
/home/build/rpmbuild/BUILD/aacraid-1.2.1-40700/aacraid_source/linit.o
    CC [M] 
/home/build/rpmbuild/BUILD/aacraid-1.2.1-40700/aacraid_source/aachba.o
    CC [M] 
/home/build/rpmbuild/BUILD/aacraid-1.2.1-40700/aacraid_source/commctrl.o
    CC [M] 
/home/build/rpmbuild/BUILD/aacraid-1.2.1-40700/aacraid_source/comminit.o
  /home/build/rpmbuild/BUILD/aacraid-1.2.1-40700/aacraid_source/aachba.c:
In function 'aac_scsi_cmd':
  /home/build/rpmbuild/BUILD/aacraid-1.2.1-40700/aacraid_source/aachba.c:3956:10:
error: 'SERVICE_ACTION_IN' undeclared (first use in this
function)
   case SERVICE_ACTION_IN:
    ^
  /home/build/rpmbuild/BUILD/aacraid-1.2.1-40700/aacraid_source/aachba.c:3956:10:
note: each undeclared identifier is reported only once for each
function it appears in
  /home/build/rpmbuild/BUILD/aacraid-1.2.1-40700/aacraid_source/aachba.c:
In function 'busy_disk':
  /home/build/rpmbuild/BUILD/aacraid-1.2.1-40700/aacraid_source/aachba.c:4799:8:
error: used struct type value where scalar is required
      && (device->device_busy
      ^
  make[1]: ***
[/home/build/rpmbuild/BUILD/aacraid-1.2.1-40700/aacraid_source/aachba.o]
Error 1
  make[1]: *** Waiting for unfinished jobs
  /home/build/rpmbuild/BUILD/aacraid-1.2.1-40700/aacraid_source/linit.c:
In function 'aac_eh_abort':
  /home/build/rpmbuild/BUILD/aacraid-1.2.1-40700/aacraid_source/linit.c:1332:7:
error: 'SERVICE_ACTION_IN' undeclared (first use in this
function)
    case SERVICE_ACTION_IN:
     ^
  /home/build/rpmbuild/BUILD/aacraid-1.2.1-40700/aacraid_source/linit.c:1332:7:
note: each undeclared identifier is reported only once for each
function it appears in
  make[1]: ***
[/home/build/rpmbuild/BUILD/aacraid-1.2.1-40700/aacraid_source/linit.o]
Error 1
  make: ***
[_module_/home/build/rpmbuild/BUILD/aacraid-1.2.1-40700/aacraid_source]
Error 2
  make: Leaving directory
`/usr/src/kernels/3.10.0-514.26.2.v7.x86_64'
  error: Bad exit status from /var/tmp/rpm-tmp.8F8I2M (%build)
  
  
  RPM build errors:
      aacraid-kmod-1.2.1-6.el7.elrepo.src.rpm: Header V4
DSA/SHA1 Signature, key ID baadae52: NOKEY
  
      Bad exit status from /var/tmp/rpm-tmp.8F8I2M (%build)


I've removed the group XXX does not exist lines. I get the same
issue with the -4, -5 and -6 files. Have you any ideas what is going
wrong?

The kernel already has the 1.2-1 module which may be OK, but someone
is having difficulty with an Adaptec 2610SA card and I'm trying
different angles.

Thanks,

Nick
  

___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Re: [elrepo] kmod-ath10k firmware issues (?) with CentOS 7

[Nick Howitt]

There is an ath10k-firmware package e.g 
http://elrepo.reloumirrors.net/elrepo/el7/x86_64/RPMS/ath10k-firmware-2.0-1.el7.elrepo.noarch.rpm


On 2016-08-16 16:15, Sean Hancock via elrepo wrote:

I recently installed a dual boot of the CentOS-7-x86_64-DVD iso
alongside an existing Windows 10 Home (V 1511 OS Build 10586.218)
installation. I did this from a DVD image. I have been unable to
connect to wifi. The wifi adapter is detected. But, upon
investigation, I have determined I need a driver.

I downloaded and installed the kmod-ath10k rpm: $ sudo rpm -Uvh
kmod-ath10k-0.0-2.el7.elpro.x86_64.rpm

(I can't use yum install, because I don't have a network interface
until I get wifi working)

The kmod-ath 10k installation was successful, however when I
restarted, I received the following errors (and the wifi interface is
still not detected):

[ 0.00] tsc: Fast TSC calibration failed
[ 4.187737] snd_hda_intel :00:1f.3 failed to add i915 component 
master (

-19)
[ 4.254938] sd 4:0:0:0: [sdc] No caching mode page found
[ 4.255009] sd 4:0:0:0: [sdc] Assuming drive cache: write through
[ 4.331600] ath10k_pci :03:00.0: could not fetch firmware file 
'ath10k/QC

A6174/hw3.0/firmware-4.bin': -2
[ 4.331670] ath10k_pci :03:00.0: could not fetch firmware file 
'ath10k/QC

A6174/hw3.0/firmware-3.bin': -2
[ 4.331739] ath10k_pci :03:00.0: could not fetch firmware file 
'ath10k/QC

A6174/hw3.0/firmware-2.bin': -2
[ 4.331808] ath10k_pci :03:00.0: could not fetch board data (-2)
[ 4.331863] ath10k_pci :03:00.0: could not fetch firmware files 
(-2)

[ 4.331920] ath10k_pci :03:00.0: could not probe fw (-2)
Exception AttributeError:"'NoneType' object has no attribute 
'udev_unref'"in<
bound method Context.__del__of ,pyudev.core.Context object at 
0x2947890>>ignor

ed


Is there additional firmware required? If so, where do I get it?


___
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

Re: [elrepo] kmod-forcedeth build failure

[Nick Howitt]

Thanks for letting me know. I'll give a go in slow time as I managed to 
get someone else to build it against an older kernel and I'm not 
brilliant using patch (understatement).


Nick

On 17/07/2016 12:40, Phil Perry wrote:


On 16/03/16 22:13, Nick Howitt wrote:

Hi,
I am trying to build the kmod-forcedeth driver from the src.rpm on 
ClearOS 7.2
(a CentOS 7.2 derivative but with a slightly different kernel) using 
rpmbuild,

but the build is failing:

Installing forcedeth-kmod-0.64-1.el7.elrepo.src.rpm
warning: forcedeth-kmod-0.64-1.el7.elrepo.src.rpm: Header V4 
DSA/SHA1

Signature, key ID baadae52: NOKEY
warning: user phil does not exist - using root
warning: group phil does not exist - using root
warning: user phil does not exist - using root
warning: group phil does not exist - using root
warning: user phil does not exist - using root
warning: group phil does not exist - using root
warning: user phil does not exist - using root
warning: group phil does not exist - using root
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.KY8JEb
+ umask 022
+ cd /home/build/rpmbuild/BUILD
+ cd /home/build/rpmbuild/BUILD
+ rm -rf forcedeth-0.64
+ /usr/bin/tar -xf -
+ /usr/bin/bzip2 -dc 
/home/build/rpmbuild/SOURCES/forcedeth-0.64.tar.bz2

+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd forcedeth-0.64
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ echo 'override forcedeth * weak-updates/forcedeth'
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.dGt9DZ
+ umask 022
+ cd /home/build/rpmbuild/BUILD
+ cd forcedeth-0.64
+ KSRC=/usr/src/kernels/3.10.0-327.10.1.v7.x86_64
+ /usr/bin/make -C /usr/src/kernels/3.10.0-327.10.1.v7.x86_64 
modules

M=/home/build/rpmbuild/BUILD/forcedeth-0.64
make: Entering directory 
`/usr/src/kernels/3.10.0-327.10.1.v7.x86_64'

   CC [M] /home/build/rpmbuild/BUILD/forcedeth-0.64/forcedeth.o
/home/build/rpmbuild/BUILD/forcedeth-0.64/forcedeth.c: In function
'nv_get_stats64':
/home/build/rpmbuild/BUILD/forcedeth-0.64/forcedeth.c:1758:3: error:
implicit declaration of function 'u64_stats_fetch_begin_bh'
[-Werror=implicit-function-declaration]
syncp_start = u64_stats_fetch_begin_bh(>swstats_rx_syncp);
^
/home/build/rpmbuild/BUILD/forcedeth-0.64/forcedeth.c:1763:2: error:
implicit declaration of function 'u64_stats_fetch_retry_bh'
[-Werror=implicit-function-declaration]
   } while (u64_stats_fetch_retry_bh(>swstats_rx_syncp, 
syncp_start));

   ^
/home/build/rpmbuild/BUILD/forcedeth-0.64/forcedeth.c: In function
'nv_start_xmit_optimized':
/home/build/rpmbuild/BUILD/forcedeth-0.64/forcedeth.c:2467:2: error:
implicit declaration of function 'vlan_tx_tag_present'
[-Werror=implicit-function-declaration]
   if (vlan_tx_tag_present(skb))
   ^
/home/build/rpmbuild/BUILD/forcedeth-0.64/forcedeth.c:2468:3: error:
implicit declaration of function 'vlan_tx_tag_get'
[-Werror=implicit-function-declaration]
start_tx->txvlan = cpu_to_le32(NV_TX3_VLAN_TAG_PRESENT |
^
cc1: some warnings being treated as errors
make[1]: *** 
[/home/build/rpmbuild/BUILD/forcedeth-0.64/forcedeth.o] Error 1
make: *** [_module_/home/build/rpmbuild/BUILD/forcedeth-0.64] 
Error 2

make: Leaving directory `/usr/src/kernels/3.10.0-327.10.1.v7.x86_64'
error: Bad exit status from /var/tmp/rpm-tmp.dGt9DZ (%build)


RPM build errors:
 forcedeth-kmod-0.64-1.el7.elrepo.src.rpm: Header V4 DSA/SHA1 
Signature,

key ID baadae52: NOKEY
 user phil does not exist - using root
 group phil does not exist - using root
 user phil does not exist - using root
 group phil does not exist - using root
 user phil does not exist - using root
 group phil does not exist - using root
 user phil does not exist - using root
 group phil does not exist - using root
 Bad exit status from /var/tmp/rpm-tmp.dGt9DZ (%build)

Is there a problem with the driver or am I out of luck? I've never 
had any
issues like with the other drivers I routinely build (r8168, r8168, 
e1000e and igb).


Regards,

Nick




Hi Nick,

I know it's been a while, but these errors are now fixed in this commit:

https://github.com/elrepo/packages/commit/e31d877ed1c4a09b182e1683f46c5950a7f66809 



I've not rebuilt the packages for RHEL as this is not necessary at 
this point (our packages built against 7.0 or 7.1 still work fine on 
7.2 kernels) but it should be easy for you to incorporate the fix into 
your package should you wish to rebuild against your 7.2 kernel.


These fixes will appear in our next package release(s).

Regards,

Phil


___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo


___
elrepo mailing list
elrepo@lists.elrepo

Re: [elrepo] What is the chance of an el7 e1000 driver?

[Nick Howitt]

On 02/06/2016 20:10, Phil Perry wrote:


On 02/06/16 18:26, Nick Howitt wrote:

Hi Akemi,

Have you been able to make any progress with this or is it a lost cause?

Regards,

Nick



Hi Nick,

Unfortunately at this point I'd say it's looking like a lost cause - 
far too many errors for me to wade my way through trying to fix:


Building target platforms: x86_64
Building for target x86_64
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.c5jstt
+ umask 022
+ cd /home/phil/rpmbuild/BUILD
+ cd /home/phil/rpmbuild/BUILD
+ rm -rf e1000-8.0.35
+ /usr/bin/gzip -dc /home/phil/rpmbuild/SOURCES/e1000-8.0.35.tar.gz
+ /usr/bin/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd e1000-8.0.35
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ /usr/bin/chmod a-x e1000.7 README
+ /usr/bin/gzip e1000.7
+ /usr/bin/cp /home/phil/rpmbuild/SOURCES/ELRepo-e1000-8.0.35-Makefile 
src/Makefile

+ echo 'override e1000 * weak-updates/e1000'
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.V2K4Gs
+ umask 022
+ cd /home/phil/rpmbuild/BUILD
+ cd e1000-8.0.35
+ pushd src
~/rpmbuild/BUILD/e1000-8.0.35/src ~/rpmbuild/BUILD/e1000-8.0.35
+ /usr/bin/make KSRC=/usr/src/kernels/3.10.0-327.el7.x86_64
/usr/bin/make -C /usr/src/kernels/3.10.0-327.el7.x86_64 
SUBDIRS=/home/phil/rpmbuild/BUILD/e1000-8.0.35/src modules

make[1]: Entering directory `/usr/src/kernels/3.10.0-327.el7.x86_64'
  CC [M]  /home/phil/rpmbuild/BUILD/e1000-8.0.35/src/e1000_main.o
/home/phil/rpmbuild/BUILD/e1000-8.0.35/src/e1000_main.c:134:23: error: 
expected '=', ',', ';', 'asm' or '__attribute__' before 'e1000_remove'

 static void __devexit e1000_remove(struct pci_dev *pdev);
   ^
/home/phil/rpmbuild/BUILD/e1000-8.0.35/src/e1000_main.c:253:2: error: 
implicit declaration of function '__devexit_p' 
[-Werror=implicit-function-declaration]

  .remove   = __devexit_p(e1000_remove),
  ^
/home/phil/rpmbuild/BUILD/e1000-8.0.35/src/e1000_main.c:253:26: error: 
'e1000_remove' undeclared here (not in a function)

  .remove   = __devexit_p(e1000_remove),
  ^
/home/phil/rpmbuild/BUILD/e1000-8.0.35/src/e1000_main.c:695:2: error: 
unknown field 'ndo_set_multicast_list' specified in initializer

  .ndo_set_multicast_list = e1000_set_multi,
  ^
/home/phil/rpmbuild/BUILD/e1000-8.0.35/src/e1000_main.c:695:2: 
warning: initialization from incompatible pointer type [enabled by 
default]
/home/phil/rpmbuild/BUILD/e1000-8.0.35/src/e1000_main.c:695:2: 
warning: (near initialization for 
'e1000_netdev_ops.ndo_vlan_rx_add_vid') [enabled by default]
/home/phil/rpmbuild/BUILD/e1000-8.0.35/src/e1000_main.c:702:2: error: 
unknown field 'ndo_vlan_rx_register' specified in initializer

  .ndo_vlan_rx_register = e1000_vlan_rx_register,
  ^
/home/phil/rpmbuild/BUILD/e1000-8.0.35/src/e1000_main.c:702:26: error: 
'e1000_vlan_rx_register' undeclared here (not in a function)

  .ndo_vlan_rx_register = e1000_vlan_rx_register,
  ^
/home/phil/rpmbuild/BUILD/e1000-8.0.35/src/e1000_main.c:703:25: error: 
'e1000_vlan_rx_add_vid' undeclared here (not in a function)

  .ndo_vlan_rx_add_vid = e1000_vlan_rx_add_vid,
 ^
/home/phil/rpmbuild/BUILD/e1000-8.0.35/src/e1000_main.c:704:26: error: 
'e1000_vlan_rx_kill_vid' undeclared here (not in a function)

  .ndo_vlan_rx_kill_vid = e1000_vlan_rx_kill_vid,
  ^
/home/phil/rpmbuild/BUILD/e1000-8.0.35/src/e1000_main.c:722:22: error: 
expected '=', ',', ';', 'asm' or '__attribute__' before 'e1000_probe'

 static int __devinit e1000_probe(struct pci_dev *pdev,
  ^
/home/phil/rpmbuild/BUILD/e1000-8.0.35/src/e1000_main.c:1093:23: 
error: expected '=', ',', ';', 'asm' or '__attribute__' before 
'e1000_remove'

 static void __devexit e1000_remove(struct pci_dev *pdev)
   ^
/home/phil/rpmbuild/BUILD/e1000-8.0.35/src/e1000_main.c:1141:22: 
error: expected '=', ',', ';', 'asm' or '__attribute__' before 
'e1000_sw_init'

 static int __devinit e1000_sw_init(struct e1000_adapter *adapter)
  ^
/home/phil/rpmbuild/BUILD/e1000-8.0.35/src/e1000_main.c:1192:22: 
error: expected '=', ',', ';', 'asm' or '__attribute__' before 
'e1000_alloc_rings'

 static int __devinit e1000_alloc_rings(struct e1000_adapter *adapter)
  ^
In file included from include/uapi/linux/stddef.h:1:0,
 from include/linux/stddef.h:4,
 from 
/usr/src/kernels/3.10.0-327.el7.x86_64/include/uapi/linux/posix_types.h:4,

 from include/uapi/linux/types.h:13,
 from include/linux/types.h:5,
 from include/linux/list.h:4,
 from include/linux/module.h:9,
 from 
/home/phil/rpmbuild/BUILD/e1000-8.0.35/src/e1000_main.c:29:
/home/phil/rpmbuild/BUILD/e1000-8.0.35/src/e1000_main.c: In function 
'e1000_tx_map':
include/asm-generic/memory_model.h:52:52: error: invalid operands to 
binary - (have 'struct ' and 'struct page *')

 #define __page_to_pfn

Re: [elrepo] What is the chance of an el7 e1000 driver?

[Nick Howitt]

Hi Akemi,

Have you been able to make any progress with this or is it a lost cause?

Regards,

Nick

On 14/05/2016 20:30, Nick Howitt wrote:

Hi Akemi,

That would be brilliant. I wait with hope!

Thanks,

Nick

On 14/05/2016 19:26, Akemi Yagi wrote:


On May 10, 2016 11:11, "Nick Howitt" <n...@howitts.co.uk> wrote:
>
> Hi,
>
> We have someone in using ClearOS7 (CentOS7 derivative) who is
having problems with the e1000 driver built into the kernel
(7.3.21-k8-NAPI on 3.10.0-327.10.1.v7.x86_64). The latest Intel
driver is 8.0.35. In its change log on sourceforge it says "* Fix
driver build issue under 3.x.x kernels", however I cannot get it to
build, and in any case it will need recompiling for every kernel
update. I suspect the driver is now unmaintained as it has not been
updated since 11/10/2011.
>
> Is there any chance that one of you fine geniuses can create an el7
compatible kmod version?
>
> Many thanks,
>
> Nick

Just wanted to note that we are working on it but no promise, no ETA.

Akemi





___
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

Re: [elrepo] What is the chance of an el7 e1000 driver?

[Nick Howitt]

  
  
Hi Akemi,

That would be brilliant. I wait with hope!

Thanks,

Nick

On 14/05/2016 19:26, Akemi Yagi wrote:


  On May 10, 2016 11:11, "Nick Howitt" <n...@howitts.co.uk>
wrote:
>
> Hi,
>
> We have someone in using ClearOS7 (CentOS7 derivative) who
is having problems with the e1000 driver built into the kernel
(7.3.21-k8-NAPI on 3.10.0-327.10.1.v7.x86_64). The latest Intel
driver is 8.0.35. In its change log on sourceforge it says "*
Fix driver build issue under 3.x.x kernels", however I cannot
get it to build, and in any case it will need recompiling for
every kernel update. I suspect the driver is now unmaintained as
it has not been updated since 11/10/2011.
>
> Is there any chance that one of you fine geniuses can
create an el7 compatible kmod version?
>
> Many thanks,
>
> Nick
  Just wanted to note that we are working on it but no
promise, no ETA.
  Akemi


  

___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

[elrepo] What is the chance of an el7 e1000 driver?

[Nick Howitt]

  
  
Hi,

We have someone in using ClearOS7 (CentOS7 derivative) who is having
problems with the e1000 driver built into the kernel (7.3.21-k8-NAPI
on 3.10.0-327.10.1.v7.x86_64). The latest Intel driver is 8.0.35. In
its change log on sourceforge it says "* Fix driver build issue
under 3.x.x kernels", however I cannot get it to build, and in any
case it will need recompiling for every kernel update. I suspect the
driver is now unmaintained as it has not been updated since
11/10/2011.

Is there any chance that one of you fine geniuses can create an el7
compatible kmod version?

Many thanks,

Nick

  

___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

[elrepo] kmod-forcedeth build failure

[Nick Howitt]

  
  
Hi,
I am trying to build the kmod-forcedeth driver from the src.rpm on
ClearOS 7.2 (a CentOS 7.2 derivative but with a slightly different
kernel) using rpmbuild, but the build is failing:
Installing forcedeth-kmod-0.64-1.el7.elrepo.src.rpm
  warning: forcedeth-kmod-0.64-1.el7.elrepo.src.rpm: Header V4
  DSA/SHA1 Signature, key ID baadae52: NOKEY
  warning: user phil does not exist - using root
  warning: group phil does not exist - using root
  warning: user phil does not exist - using root
  warning: group phil does not exist - using root
  warning: user phil does not exist - using root
  warning: group phil does not exist - using root
  warning: user phil does not exist - using root
  warning: group phil does not exist - using root
  Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.KY8JEb
  + umask 022
  + cd /home/build/rpmbuild/BUILD
  + cd /home/build/rpmbuild/BUILD
  + rm -rf forcedeth-0.64
  + /usr/bin/tar -xf -
  + /usr/bin/bzip2 -dc
  /home/build/rpmbuild/SOURCES/forcedeth-0.64.tar.bz2
  + STATUS=0
  + '[' 0 -ne 0 ']'
  + cd forcedeth-0.64
  + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
  + echo 'override forcedeth * weak-updates/forcedeth'
  + exit 0
  Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.dGt9DZ
  + umask 022
  + cd /home/build/rpmbuild/BUILD
  + cd forcedeth-0.64
  + KSRC=/usr/src/kernels/3.10.0-327.10.1.v7.x86_64
  + /usr/bin/make -C /usr/src/kernels/3.10.0-327.10.1.v7.x86_64
  modules M=/home/build/rpmbuild/BUILD/forcedeth-0.64
  make: Entering directory
  `/usr/src/kernels/3.10.0-327.10.1.v7.x86_64'
    CC [M]  /home/build/rpmbuild/BUILD/forcedeth-0.64/forcedeth.o
  /home/build/rpmbuild/BUILD/forcedeth-0.64/forcedeth.c: In function
  'nv_get_stats64':
  /home/build/rpmbuild/BUILD/forcedeth-0.64/forcedeth.c:1758:3:
  error: implicit declaration of function 'u64_stats_fetch_begin_bh'
  [-Werror=implicit-function-declaration]
     syncp_start =
  u64_stats_fetch_begin_bh(>swstats_rx_syncp);
     ^
  /home/build/rpmbuild/BUILD/forcedeth-0.64/forcedeth.c:1763:2:
  error: implicit declaration of function 'u64_stats_fetch_retry_bh'
  [-Werror=implicit-function-declaration]
    } while (u64_stats_fetch_retry_bh(>swstats_rx_syncp,
  syncp_start));
    ^
  /home/build/rpmbuild/BUILD/forcedeth-0.64/forcedeth.c: In function
  'nv_start_xmit_optimized':
  /home/build/rpmbuild/BUILD/forcedeth-0.64/forcedeth.c:2467:2:
  error: implicit declaration of function 'vlan_tx_tag_present'
  [-Werror=implicit-function-declaration]
    if (vlan_tx_tag_present(skb))
    ^
  /home/build/rpmbuild/BUILD/forcedeth-0.64/forcedeth.c:2468:3:
  error: implicit declaration of function 'vlan_tx_tag_get'
  [-Werror=implicit-function-declaration]
     start_tx->txvlan = cpu_to_le32(NV_TX3_VLAN_TAG_PRESENT |
     ^
  cc1: some warnings being treated as errors
  make[1]: ***
  [/home/build/rpmbuild/BUILD/forcedeth-0.64/forcedeth.o] Error 1
  make: *** [_module_/home/build/rpmbuild/BUILD/forcedeth-0.64]
  Error 2
  make: Leaving directory
  `/usr/src/kernels/3.10.0-327.10.1.v7.x86_64'
  error: Bad exit status from /var/tmp/rpm-tmp.dGt9DZ (%build)
  
  
  RPM build errors:
      forcedeth-kmod-0.64-1.el7.elrepo.src.rpm: Header V4 DSA/SHA1
  Signature, key ID baadae52: NOKEY
      user phil does not exist - using root
      group phil does not exist - using root
      user phil does not exist - using root
      group phil does not exist - using root
      user phil does not exist - using root
      group phil does not exist - using root
      user phil does not exist - using root
      group phil does not exist - using root
      Bad exit status from /var/tmp/rpm-tmp.dGt9DZ (%build)

Is there a problem with the driver or am I out of luck? I've never
had any issues like with the other drivers I routinely build (r8168,
r8168, e1000e and igb).

Regards,

Nick
  

___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

[elrepo] Intel e1000e and igb issue

[Nick Howitt]

  
  
Hi,

I've been using kmod drivers for a few years now - the r8168, e1000e
(no more) and igb and I've recently bumped into an oddity while
helping someone on the ClearOS
  forums. I've been used to the idea of the modules installing
in a "week-updates" directory so, for example the r8168 driver
installs to
/lib/modules/2.6.32-504.8.1.v6.x86_64/weak-updates/r8168/r8168.ko.
Compiling the e1000e and igb drivers from source against the ClearOS
kernel (which is a small bit different to RHEL), I then install the
drivers and I notice the igb one installs to
/lib/modules/2.6.32-431.23.3.v6.x86_64/extra/igb/igb.ko. Subsequent
to that ClearOS updated and a new kernel was installed
(2.6.32-504.8.1.v6.x86_64). I rebooted the server and it showed me
running the stock version of the igb, so the kmod one was not
carried forward.

Someone else has installed my e1000e driver I compiled on the older
kernel and again it is not being loaded as it has installed into
/lib/modules/2.6.32-431.3.1.v6.x86_64/extra/e1000e.

Have I completely misunderstood things or is something wrong. The
intel drivers are only being used with the kernel they were compiled
for.

Regards,

Nick
  

___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

[elrepo] Exotic kmod-e1000e installation issue

[Nick Howitt]

  
  
Hi,

I bumped into an exotic issue trying to install kmod-e1000e-2.5.4
built for ClearOS. A a bit of history I made and installed my own
rpm of the stock e1000e driver and forgot about it. Since then I've
upgraded the kernel so the driver can't be being used. I tried
compiling and installing kmod-e1000e-2.5.4 but it failed with:
[root@server src]# rpm -Uvh
  kmod-e1000e-2.5.4-1.clearos.x86_64.rpm
  Preparing...
  ### [100%]
   file /usr/share/man/man7/e1000e.7.gz from install of
  kmod-e1000e-2.5.4-1.clearos.x86_64 conflicts with file from
  package e1000e-2.1.4-1.x86_64

Now I know I can and should remove the stock 2.1.4 rpm but out of
interest I tried kmod-e1000e-2.3.2 and that worked fine. 2.4.14 also
fails so something has changed between 2.3.2 and 2.4.14.

Have you any ideas?

Regards,

Nick
  

___
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo