Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2216459 - The rmnet driver is missing
Summary: The rmnet driver is missing
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 38
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-06-21 13:47 UTC by Fabio Porcedda
Modified: 2023-07-23 01:28 UTC (History)
17 users (show)

Fixed In Version: kernel-6.4.4-100.fc37 kernel-6.4.4-200.fc38
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-07-23 01:23:54 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
dmesg.txt as required by point 7 (deleted)
2023-06-21 13:47 UTC, Fabio Porcedda 		no flags Details
View All

Description Fabio Porcedda 2023-06-21 13:47:44 UTC 
Created attachment 1971889 [details]
dmesg.txt as required by point 7

1. Please describe the problem:

The rmnet driver is not built in the kernel.

2. What is the Version-Release number of the kernel:

Name        : kernel
Version     : 6.3.8
Release     : 200.fc38
Architecture: x86_64

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :

As far as I know didn't work even in previous kernel version.

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

$ sudo modprobe rmnet
modprobe: FATAL: Module rmnet not found in directory /lib/modules/6.3.8-200.fc38.x86_64

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:

Yes:
$ sudo modprobe rmnet
modprobe: FATAL: Module rmnet not found in directory /lib/modules/6.4.0-0.rc7.20230620git692b7dc87ca6.54.fc39.x86_64

6. Are you running any modules that not shipped with directly Fedora's kernel?:

No.

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.
Comment 1 Fabio Porcedda 2023-06-21 13:50:06 UTC 
To fix the problem the kernel config file should have the line "CONFIG_RMNET=m" in it.
Comment 2 Kate Hsuan 2023-06-21 17:36:18 UTC 
Hi Fabio,

Thank you for reporting the issue.

Could you please describe that why this feature should be included in the kernel?
It would be helpful to persuade the maintainer to enable it.
Comment 3 Fabio Porcedda 2023-06-22 07:57:20 UTC 
The RmNet MAP driver (CONFIG_RMNET) is needed in order to get the most out of the Qualcomm modem both in terms of throughput (e.g. packets aggregation) and features (e.g. multiplexed connections).
Comment 4 Fedora Update System 2023-06-22 13:49:43 UTC 
FEDORA-2023-5b6cd52f47 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-5b6cd52f47
Comment 5 Fedora Update System 2023-06-22 13:49:47 UTC 
FEDORA-2023-9b7e08901a has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-9b7e08901a
Comment 6 Fedora Update System 2023-06-23 01:51:16 UTC 
FEDORA-2023-9b7e08901a has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-9b7e08901a`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-9b7e08901a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 7 Fedora Update System 2023-06-23 01:51:44 UTC 
FEDORA-2023-5b6cd52f47 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-5b6cd52f47`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-5b6cd52f47

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 8 Fabio Porcedda 2023-06-27 08:16:36 UTC 
(In reply to Fedora Update System from comment #6)
> FEDORA-2023-9b7e08901a has been pushed to the Fedora 38 testing repository.
> Soon you'll be able to install the update with the following command:
> `sudo dnf upgrade --enablerepo=updates-testing --refresh
> --advisory=FEDORA-2023-9b7e08901a`
> You can provide feedback for this update here:
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-9b7e08901a
> 
> See also https://fedoraproject.org/wiki/QA:Updates_Testing for more
> information on how to test updates.

I tested the update and unfortunately it still doesn't have the rmnet driver!
Comment 9 Justin M. Forbes 2023-06-28 13:00:20 UTC 
The driver is not missing:
rpm -qlp kernel-modules-core-6.3.9-200.fc38.aarch64.rpm  | grep rmnet
/lib/modules/6.3.9-200.fc38.aarch64/kernel/drivers/net/ethernet/qualcomm/rmnet
/lib/modules/6.3.9-200.fc38.aarch64/kernel/drivers/net/ethernet/qualcomm/rmnet/rmnet.ko.xz


RMNET is dependent on CONFIG_NET_VENDOR_QUALCOMM which is only turned on for aarch64. If your device is supported on x86_64, it is not supported by one of those drivers. If RMNET itself will work with other drivers, perhaps that is an upstream bug that makes it dependent on CONFIG_NET_VENDOR_QUALCOMM
Comment 10 Fabio Porcedda 2023-06-28 14:26:31 UTC 
(In reply to Justin M. Forbes from comment #9)
> The driver is not missing:
> rpm -qlp kernel-modules-core-6.3.9-200.fc38.aarch64.rpm  | grep rmnet
> /lib/modules/6.3.9-200.fc38.aarch64/kernel/drivers/net/ethernet/qualcomm/
> rmnet
> /lib/modules/6.3.9-200.fc38.aarch64/kernel/drivers/net/ethernet/qualcomm/
> rmnet/rmnet.ko.xz
> 
> 
> RMNET is dependent on CONFIG_NET_VENDOR_QUALCOMM which is only turned on for
> aarch64. If your device is supported on x86_64, it is not supported by one
> of those drivers. If RMNET itself will work with other drivers, perhaps that
> is an upstream bug that makes it dependent on CONFIG_NET_VENDOR_QUALCOMM

CONFIG_NET_VENDOR_QUALCOMM doesn't depend on aarch64 so can be enabled even for x86_64, so please turn it on even for x86_64 in order to have the rmnet driver even for the x86_64 architecture because I use Qualcomm devices on a x86_64 architecture.

Regards
Comment 11 Justin M. Forbes 2023-06-28 15:16:42 UTC 
(In reply to Fabio Porcedda from comment #10)
> CONFIG_NET_VENDOR_QUALCOMM doesn't depend on aarch64 so can be enabled even
> for x86_64, so please turn it on even for x86_64 in order to have the rmnet
> driver even for the x86_64 architecture because I use Qualcomm devices on a
> x86_64 architecture.
> 
> Regards

I am aware that it does not depend on aarch64, but the physical devices hidden behind it seem to only be useful on aarch46. My question is, since they decided to hide rmnet behind it as well, does that mean that only those devices are capable of working with rmnet?  If not, then it is an upstream bug, and the rmnet Kconfig shouldn't depend on CONFIG_NET_VENDOR_QUALCOMM, but I am not sure.  I will need to look through the code when I get a chance (on vacation this week, will be working full time again next week).  If it does work with other devices, I will adjust our config appropriately, and send a patch upstream to get rid of the false dependency.
Comment 12 Fabio Porcedda 2023-06-28 15:56:00 UTC 
(In reply to Justin M. Forbes from comment #11)
> (In reply to Fabio Porcedda from comment #10)
> > CONFIG_NET_VENDOR_QUALCOMM doesn't depend on aarch64 so can be enabled even
> > for x86_64, so please turn it on even for x86_64 in order to have the rmnet
> > driver even for the x86_64 architecture because I use Qualcomm devices on a
> > x86_64 architecture.
> > 
> > Regards
> 
> I am aware that it does not depend on aarch64, but the physical devices
> hidden behind it seem to only be useful on aarch46. My question is, since
> they decided to hide rmnet behind it as well, does that mean that only those
> devices are capable of working with rmnet?  If not, then it is an upstream
> bug, and the rmnet Kconfig shouldn't depend on CONFIG_NET_VENDOR_QUALCOMM,
> but I am not sure.  I will need to look through the code when I get a chance
> (on vacation this week, will be working full time again next week).  If it
> does work with other devices, I will adjust our config appropriately, and
> send a patch upstream to get rid of the false dependency.

The dependency between the CONFIG_NET_VENDOR_QUALCOMM and CONFIG_RMNET is correct, doesn't not need to be changed so no patches are needed.

The physical devices are not only used in the aarch64 architecture but also on the x86_64 architecture. I'm using it daily and also my colleagues use it on the x86_64 architecture.

So please enable the CONFIG_NET_VENDOR_QUALCOMM and CONFIG_RMNET options also on the x86_64 architecture.
Comment 13 Justin M. Forbes 2023-07-05 14:01:38 UTC 
(In reply to Fabio Porcedda from comment #12)
> The dependency between the CONFIG_NET_VENDOR_QUALCOMM and CONFIG_RMNET is
> correct, doesn't not need to be changed so no patches are needed.
> 
> The physical devices are not only used in the aarch64 architecture but also
> on the x86_64 architecture. I'm using it daily and also my colleagues use it
> on the x86_64 architecture.

Explain to me how that is working.  The drivers in question are not enabled on x86_64, so you couldn't be using them unless you are building your own kernel. The devices hidden behind NET_VENDOR_QUALCOMM are Qualcomm Atheros QCA7000 and QCOM_EMAC, as well as the rmnet driver. Other Qualcomm hardware is supported, but not behind NET_VENDOR_QUALCOMM. Either rmnet works with other Qualcomm devices, and thus it is a bug that CONFIG_RMNET is hidden behind NET_VENDOR_QUALCOMM, or it does not work with other devices and there is no reason to turn this on on for systems without this hardware.
Comment 14 Fabio Porcedda 2023-07-05 14:25:53 UTC 
(In reply to Justin M. Forbes from comment #13)
> (In reply to Fabio Porcedda from comment #12)
> > The dependency between the CONFIG_NET_VENDOR_QUALCOMM and CONFIG_RMNET is
> > correct, doesn't not need to be changed so no patches are needed.
> > 
> > The physical devices are not only used in the aarch64 architecture but also
> > on the x86_64 architecture. I'm using it daily and also my colleagues use it
> > on the x86_64 architecture.
> 
> Explain to me how that is working.  The drivers in question are not enabled
> on x86_64, so you couldn't be using them unless you are building your own
> kernel. The devices hidden behind NET_VENDOR_QUALCOMM are Qualcomm Atheros
> QCA7000 and QCOM_EMAC, as well as the rmnet driver. Other Qualcomm hardware
> is supported, but not behind NET_VENDOR_QUALCOMM. Either rmnet works with
> other Qualcomm devices, and thus it is a bug that CONFIG_RMNET is hidden
> behind NET_VENDOR_QUALCOMM, or it does not work with other devices and there
> is no reason to turn this on on for systems without this hardware.

I'm using a Qualcomm device trough USB that is not under the CONFIG_NET_VENDOR_QUALCOMM option.
I don't know if it is a bug or not that the CONFIG_RMNET depends on the NET_VENDOR_QUALCOMM, I'm only sure that I need the CONFIG_RMNET option even on the x86_64 architecture.
If for you this is a bug feel free to change it, I don't have a strong opinion about that.
Comment 15 Justin M. Forbes 2023-07-06 15:55:57 UTC 
Just out of curiosity, can you tell me what driver your device is using or what model number it is?
Comment 16 Fabio Porcedda 2023-07-07 06:49:50 UTC 
(In reply to Justin M. Forbes from comment #15)
> Just out of curiosity, can you tell me what driver your device is using or
> what model number it is?

The Qualcomm chipsets are for example Qualcomm SDX55/SDX62/SDX65, the drivers are:
- USB: qmi_wwan
- PCIE: mhi_net
Comment 17 Fedora Update System 2023-07-20 13:55:16 UTC 
FEDORA-2023-3661f028b8 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-3661f028b8
Comment 18 Fedora Update System 2023-07-20 13:55:18 UTC 
FEDORA-2023-e4e985b5dd has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-e4e985b5dd
Comment 19 Fedora Update System 2023-07-21 01:33:27 UTC 
FEDORA-2023-3661f028b8 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-3661f028b8`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-3661f028b8

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 20 Fedora Update System 2023-07-21 02:20:40 UTC 
FEDORA-2023-e4e985b5dd has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-e4e985b5dd`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-e4e985b5dd

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 21 Fedora Update System 2023-07-23 01:23:54 UTC 
FEDORA-2023-3661f028b8 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.
Comment 22 Fedora Update System 2023-07-23 01:28:23 UTC 
FEDORA-2023-e4e985b5dd has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.
Note You need to log in before you can comment on or make changes to this bug.