View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000942 | channel: kernel/el7 | kernel-ml | public | 2019-09-22 16:04 | 2021-04-17 13:29 |
| Reporter | kupan787 | Assigned To | burakkucat | ||
| Priority | normal | Severity | block | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0000942: Kernel Panic with 5.3.0/5.3.1 - Bad RIP Value | ||||
| Description | When trying to boot up with Kernel 5.3 (or 5.3.1) I get a kernel panic, with the error "Bad RIP Value". Not sure how best to grab the log, so took a photo of my display. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
|
|
Last successful kernel that booted was 5.2.14. |
|
|
We do not alter the source code in any way. We simply package what upstream provides. Therefore, issues like this need to be reported upstream at kernel.org where they will get fixed. |
|
|
I got exactly the same error. There are two reports inside bugzilla.kernel.org: https://bugzilla.kernel.org/show_bug.cgi?id=204883 Showing some kernel panic screenshots(one of this from me). Most of the screenshots shows the rtl_open() in the first line. So I assumed it's Realtek related. Later I found: https://bugzilla.kernel.org/show_bug.cgi?id=204343 In the last comment: "This indicates that you miss the Realtek PHY driver (should be "Generic Realtek PHY") ..." So we(I) miss a kernel module. But which one? Or the kernel-ml-5.3.1-1.el7.elrepo.x86_64.rpm is configured not to have this "Generic Realtek PHY" driver. |
|
|
Found some related config values: menuconfig PHYLIB config REALTEK_PHY How is the current kernel-ml configured about it? My last kernel build is from last decade, since then I used kernel rpms. |
|
|
I'm by no means a kernel guy, but I think you can find the config in /boot. For example, on my box with 5.2.14 I see: config-5.2.14-1.el7.elrepo.x86_64 And when I check that for REALTEK_PHY I see: CONFIG_REALTEK_PHY=m On a box I have with 5.3: config-5.3.0-1.el7.elrepo.x86_64 CONFIG_REALTEK_PHY=m So it looks the same to me. |
|
|
Same here with 5.3.1, CONFIG PHYLIB=m also. So we need the kernel modules only or/and some firmware rpms. Who knows? |
|
|
Found some related .ko below /lib/modules/[kernelversion]/ The modules are there! But what goes wrong? Ok, I was too long not involved in Linux! |
|
|
Ok, found a solution for me: exclude moldule r8169 from load per kernel parameter in grub add "module_blacklist=r8169" to your kernel parameters Works for me for 5.3.1 and 5.2.14! IMHO module r8169 is obsolete in kernels > 5.3. |
|
|
I have checked in the master kernel configuration files and see that the following REALTEK options are enabled -- [Build64R7 el7]$ grep -r REALTEK * | sort | grep -E '4\.4\.194|5\.3\.1' config-4.4/config-4.4.194-x86_64:CONFIG_MEMSTICK_REALTEK_PCI=m config-4.4/config-4.4.194-x86_64:CONFIG_MEMSTICK_REALTEK_USB=m config-4.4/config-4.4.194-x86_64:CONFIG_MMC_REALTEK_PCI=m config-4.4/config-4.4.194-x86_64:CONFIG_MMC_REALTEK_USB=m config-4.4/config-4.4.194-x86_64:CONFIG_NET_VENDOR_REALTEK=y config-4.4/config-4.4.194-x86_64:CONFIG_REALTEK_AUTOPM=y config-4.4/config-4.4.194-x86_64:CONFIG_REALTEK_PHY=m config-4.4/config-4.4.194-x86_64:CONFIG_SND_HDA_CODEC_REALTEK=m config-4.4/config-4.4.194-x86_64:CONFIG_USB_STORAGE_REALTEK=m config-5.3/config-5.3.1-x86_64:CONFIG_MEMSTICK_REALTEK_PCI=m config-5.3/config-5.3.1-x86_64:CONFIG_MEMSTICK_REALTEK_USB=m config-5.3/config-5.3.1-x86_64:CONFIG_MMC_REALTEK_PCI=m config-5.3/config-5.3.1-x86_64:CONFIG_MMC_REALTEK_USB=m config-5.3/config-5.3.1-x86_64:CONFIG_NET_VENDOR_REALTEK=y config-5.3/config-5.3.1-x86_64:CONFIG_REALTEK_AUTOPM=y config-5.3/config-5.3.1-x86_64:CONFIG_REALTEK_PHY=m config-5.3/config-5.3.1-x86_64:CONFIG_SND_HDA_CODEC_REALTEK=m config-5.3/config-5.3.1-x86_64:CONFIG_USB_STORAGE_REALTEK=m config-5.3/config-5.3.1-x86_64:CONFIG_WLAN_VENDOR_REALTEK=y [Build64R7 el7]$ Perhaps you could perform a test with the kernel-lt-4.4.194 package set and see if it operates correctly with your hardware? If it does, then there is a regression in the kernel source code which should be reported upstream, at https://bugzilla.kernel.org/ As toracat has explained (in note 6497, above) the ELRepo Project only builds the kernel package sets from the upstream source code. Any bug fix would have to come from the relevant upstream developer. |
|
|
I think you are right, r8169 is not obsolete it's broken. Upps, now the LAN does not work anymore. WiFi was ok! So it was my fault, sorry! |
|
|
IMHO there is a interference between r8169 and realtek module. |
|
|
So just an FYI, by blacklisting the driver, you loose network access with that NIC. I confirmed that I can now boot, but have no network access. I just built/installed the Realtek driver, and can now boot and have network access on 5.3 Steps I took: 1) While still on 5.2 kernel, grab the source code for my Realtek card wget https://github.com/mtorromeo/r8168/archive/8.047.04.tar.gz 2) Install 5.3 kernel 3) Add kernel param to blacklist r8169 4) Boot into 5.3 5) Untar and build kernel tar xfvz 8.047.04.tar.gz cd r8168-8.047.04/ ./autorun.sh 6) Confirm new module is loaded: lsmod | grep r81 ethtool -I enp6s0 7) Reboot, and have a working 5.3 along with working network access. |
|
|
This can be closed. It is posted upstream: https://bugzilla.kernel.org/show_bug.cgi?id=204883 |
|
|
So, thanks much for this. This fixed the same issue (5.3.x kernels would not boot, where 5.2.x would). However, I was able to get the system back to functioning simply by blacklisting the driver, and my wireless works w/o that driver. I'm writing this note on the system with the driver blacklisted, and it's working great. I'm pretty sure I have only one wireless chip in the machine, the r8169 driver was being loaded when it didn't need to be? Adding this info in case someone else has the same system environment. I have the driver downloaded, and if the next time the kernel updates I'm broken again, I may actually compile the driver, but I had wireless with both 5.3.1 and 5.3.5 kernels. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-09-22 16:04 | kupan787 | New Issue | |
| 2019-09-22 16:04 | kupan787 | Status | new => assigned |
| 2019-09-22 16:04 | kupan787 | Assigned To | => burakkucat |
| 2019-09-22 16:04 | kupan787 | File Added: IMG_0054.jpeg | |
| 2019-09-22 16:05 | kupan787 | Note Added: 0006496 | |
| 2019-09-22 18:22 | toracat | Note Added: 0006497 | |
| 2019-09-27 13:12 | whamburg | Note Added: 0006525 | |
| 2019-09-27 14:11 | whamburg | Note Added: 0006526 | |
| 2019-09-27 14:16 | kupan787 | Note Added: 0006527 | |
| 2019-09-27 14:28 | whamburg | Note Added: 0006528 | |
| 2019-09-27 15:02 | whamburg | Note Added: 0006529 | |
| 2019-09-27 15:43 | whamburg | Note Added: 0006530 | |
| 2019-09-27 15:57 | burakkucat | Note Added: 0006531 | |
| 2019-09-27 16:25 | whamburg | Note Added: 0006532 | |
| 2019-09-27 17:02 | whamburg | Note Added: 0006534 | |
| 2019-09-27 17:13 | kupan787 | Note Added: 0006536 | |
| 2019-09-27 17:17 | kupan787 | Note Added: 0006537 | |
| 2019-10-09 09:43 | tunaboy | Note Added: 0006596 | |
| 2021-04-17 13:29 | toracat | Status | assigned => resolved |
| 2021-04-17 13:29 | toracat | Resolution | open => fixed |
