Hello:
I am attempting to re-compile a broken kernel module for the AltArch/Arm32 release. Currently I'm trying it against the current kernel, 4.9.75-204. In using "kernel-devel-4.9.75-204.el7.centos.armv7hl", and following the instructions for CentOS at : https://wiki.centos.org/HowTos/BuildingKernelModules, when I do a "make prepare", I am getting the error:
make[1]: *** No rule to make target `arch/arm/tools/gen-mach-types', needed by `include/generated/mach-types.h'. Stop. make: *** [archprepare] Error 2
I've been searching for a fix for this but not sure what is missing here. If you have a solution please let me know. Thanks for your help on this.
Chris
My apologies... I was running against only the kernel-devel source files rather than the full kernel source. It is working fine now that I found the correct kernel src.rpm package for this kernel.
Thank you... Chris
On 02/02/2018 09:59 PM, Chris Szilagyi wrote:
Hello:
I am attempting to re-compile a broken kernel module for the AltArch/Arm32 release. Currently I'm trying it against the current kernel, 4.9.75-204. In using "kernel-devel-4.9.75-204.el7.centos.armv7hl", and following the instructions for CentOS at : https://wiki.centos.org/HowTos/BuildingKernelModules, when I do a "make prepare", I am getting the error:
make[1]: *** No rule to make target `arch/arm/tools/gen-mach-types', needed by `include/generated/mach-types.h'. Stop. make: *** [archprepare] Error 2
I've been searching for a fix for this but not sure what is missing here. If you have a solution please let me know. Thanks for your help on this.
Chris _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
I seem to have stumbled upon an issue larger than I thought. I have been fighting this driver in the 4.9.75-204 kernel that is the current release for the AltArch/Arm32 platforms. Basically I'm getting a kernel oops with this kernel (I included below). I have tried patching and compiling my own module however I'm now getting a segfault with that. It seems that the 4.14 kernel may have resolved this issue:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/dr...
But I'm hoping to get this fixed with the 4.9.75 kernel or the 4.9.x series if that is what will be used for future kernel updates for this platform. I found a post regarding the issue on an Ubuntu forum and it appears this is the same thing I'm getting with this CentOS 4.9.75 kernel:
https://bugs.launchpad.net/ubuntu/+bug/1710419
This is the patch I tried and so far no luck. If anybody has a way to help or any thoughts on how to get this integrated to the kernels for this, I am more than happy to test it here on the Banana Pi.
Thank you for your help.
Chris
On 02/03/2018 12:37 AM, Chris Szilagyi wrote:
My apologies... I was running against only the kernel-devel source files rather than the full kernel source. It is working fine now that I found the correct kernel src.rpm package for this kernel.
Thank you... Chris
On 02/02/2018 09:59 PM, Chris Szilagyi wrote:
Hello:
I am attempting to re-compile a broken kernel module for the AltArch/Arm32 release. Currently I'm trying it against the current kernel, 4.9.75-204. In using "kernel-devel-4.9.75-204.el7.centos.armv7hl", and following the instructions for CentOS at : https://wiki.centos.org/HowTos/BuildingKernelModules, when I do a "make prepare", I am getting the error:
make[1]: *** No rule to make target `arch/arm/tools/gen-mach-types', needed by `include/generated/mach-types.h'. Stop. make: *** [archprepare] Error 2
I've been searching for a fix for this but not sure what is missing here. If you have a solution please let me know. Thanks for your help on this.
Chris _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
Forgot to provide the kernel oops..... Here it is:
Jan 30 04:43:55 bananapi kernel: usb 4-1: new high-speed USB device number 2 using ehci-platform Jan 30 04:43:55 bananapi kernel: usb 4-1: New USB device found, idVendor=2040, idProduct=7501 Jan 30 04:43:55 bananapi kernel: usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jan 30 04:43:55 bananapi kernel: usb 4-1: Product: WinTV Jan 30 04:43:56 bananapi kernel: usb 4-1: Manufacturer: Hauppauge Jan 30 04:43:56 bananapi kernel: usb 4-1: SerialNumber: 7300-00-F0783133 Jan 30 04:43:56 bananapi kernel: media: Linux media interface: v0.10 Jan 30 04:43:56 bananapi kernel: Linux video capture interface: v2.00 Jan 30 04:43:56 bananapi kernel: pvrusb2: Hardware description: WinTV HVR-1950 Model 751xx Jan 30 04:43:56 bananapi kernel: usbcore: registered new interface driver pvrusb2 Jan 30 04:43:56 bananapi kernel: pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner Jan 30 04:43:56 bananapi kernel: pvrusb2: Debug mask is 31 (0x1f) Jan 30 04:43:57 bananapi kernel: pvrusb2: Device microcontroller firmware (re)loaded; it should now reset and reconnect. Jan 30 04:43:57 bananapi kernel: usb 4-1: USB disconnect, device number 2 Jan 30 04:43:57 bananapi kernel: pvrusb2: Device being rendered inoperable Jan 30 04:43:59 bananapi kernel: usb 4-1: new high-speed USB device number 3 using ehci-platform Jan 30 04:43:59 bananapi kernel: usb 4-1: New USB device found, idVendor=2040, idProduct=7501 Jan 30 04:43:59 bananapi kernel: usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jan 30 04:43:59 bananapi kernel: usb 4-1: Product: WinTV Jan 30 04:43:59 bananapi kernel: usb 4-1: Manufacturer: Hauppauge Jan 30 04:43:59 bananapi kernel: usb 4-1: SerialNumber: 7300-00-F0783133 Jan 30 04:43:59 bananapi kernel: pvrusb2: Hardware description: WinTV HVR-1950 Model 751xx Jan 30 04:43:59 bananapi kernel: pvrusb2: Binding ir_rx_z8f0811_haup to i2c address 0x71. Jan 30 04:43:59 bananapi kernel: pvrusb2: Binding ir_tx_z8f0811_haup to i2c address 0x70. Jan 30 04:43:59 bananapi kernel: lirc_zilog: module is from the staging directory, the quality is unknown, you have been warned. Jan 30 04:43:59 bananapi kernel: lirc_zilog: module is from the staging directory, the quality is unknown, you have been warned. Jan 30 04:43:59 bananapi kernel: Zilog/Hauppauge IR driver initializing Jan 30 04:43:59 bananapi kernel: probing IR Rx on pvrusb2_a (i2c-2) Jan 30 04:43:59 bananapi kernel: probe of IR Rx on pvrusb2_a (i2c-2) done. Waiting on IR Tx. Jan 30 04:43:59 bananapi kernel: i2c i2c-2: probe of IR Rx on pvrusb2_a (i2c-2) done Jan 30 04:43:59 bananapi kernel: probing IR Tx on pvrusb2_a (i2c-2) Jan 30 04:43:59 bananapi kernel: i2c i2c-2: Direct firmware load for haup-ir-blaster.bin failed with error -2 Jan 30 04:43:59 bananapi kernel: i2c i2c-2: firmware haup-ir-blaster.bin not available (-2) Jan 30 04:43:59 bananapi kernel: i2c i2c-2: lirc_dev: driver lirc_zilog registered at minor = 1 Jan 30 04:43:59 bananapi kernel: i2c i2c-2: IR unit on pvrusb2_a (i2c-2) registered as lirc1 and ready Jan 30 04:43:59 bananapi kernel: i2c i2c-2: probe of IR Tx on pvrusb2_a (i2c-2) done Jan 30 04:43:59 bananapi kernel: initialization complete Jan 30 04:43:59 bananapi kernel: cx25840 2-0044: cx25843-24 found @ 0x88 (pvrusb2_a) Jan 30 04:43:59 bananapi kernel: pvrusb2: Attached sub-driver cx25840 Jan 30 04:43:59 bananapi kernel: tuner 2-0042: Tuner -1 found with type(s) Radio TV. Jan 30 04:43:59 bananapi kernel: pvrusb2: Attached sub-driver tuner Jan 30 04:44:01 bananapi kernel: cx25840 2-0044: loaded v4l-cx25840.fw firmware (16382 bytes) Jan 30 04:44:02 bananapi kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000018 Jan 30 04:44:02 bananapi kernel: pgd = c0204000 Jan 30 04:44:02 bananapi kernel: [00000018] *pgd=00000000
Message from syslogd@bananapi at Jan 30 04:44:03 ... kernel:Internal error: Oops: 5 [#1] SMP ARM Jan 30 04:44:03 bananapi kernel: Internal error: Oops: 5 [#1] SMP ARM Jan 30 04:44:03 bananapi kernel: Modules linked in: tda8290(E) tuner(E) cx25840(E) lirc_zilog(CE) pvrusb2(E) tveeprom(E) cx2341x(E) dvb_core(E) v4l2_common(E) videodev(E) media(E) ip6t_rpfilter(E) ip6t_REJECT(E) nf_reject_ipv6(E) xt_conntrack(E) ip_set(E) nfnetlink(E) ebtable_nat(E) ebtable_broute(E) bridge(E) stp(E) llc(E) ip6table_nat(E) nf_conntrack_ipv6(E) nf_defrag_ipv6(E) nf_nat_ipv6(E) ip6table_mangle(E) ip6table_security(E) ip6table_raw(E) iptable_nat(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) nf_nat_ipv4(E) nf_nat(E) nf_conntrack(E) iptable_mangle(E) iptable_security(E) iptable_raw(E) ebtable_filter(E) ebtables(E) ip6table_filter(E) ip6_tables(E) sun4i_codec(E) snd_soc_core(E) snd_pcm_dmaengine(E) ac97_bus(E) snd_seq(E) snd_seq_device(E) ir_lirc_codec(E) lirc_dev(E) axp20x_usb_power(E) snd_pcm(E) gpio_axp209(E) Jan 30 04:44:03 bananapi kernel: axp20x_pek(E) snd_timer(E) snd(E) sun4i_ts(E) soundcore(E) sunxi_cir(E) rc_core(E) sunxi_wdt(E) nvmem_sunxi_sid(E) nvmem_core(E) sun4i_ss(E) sunxi(E) phy_generic(E) des_generic(E) musb_hdrc(E) udc_core(E) spi_sun4i(E) phy_sun4i_usb(E) leds_gpio(E) cpufreq_dt(E) realtek(E) mmc_block(E) dwmac_sunxi(E) stmmac_platform(E) stmmac(E) ptp(E) pps_core(E) i2c_mv64xxx(E) rtc_sunxi(E) ahci_sunxi(E) libahci_platform(E) ehci_platform(E) ohci_platform(E) sunxi_mmc(E) mmc_core(E) sun4i_dma(E) Jan 30 04:44:03 bananapi kernel: CPU: 1 PID: 824 Comm: pvrusb2-context Tainted: G C E 4.9.75-204.el7.centos.armv7hl #1 Jan 30 04:44:03 bananapi kernel: Hardware name: Allwinner sun7i (A20) Family Jan 30 04:44:03 bananapi kernel: task: c7d48000 task.stack: c7f00000 Jan 30 04:44:03 bananapi kernel: PC is at tveeprom_hauppauge_analog+0x6d8/0x9c0 [tveeprom] Jan 30 04:44:03 bananapi kernel: LR is at tveeprom_hauppauge_analog+0x58/0x9c0 [tveeprom] Jan 30 04:44:03 bananapi kernel: pc : [<bf4746d8>] lr : [<bf474058>] psr: 60000013#012sp : c7f01d88 ip : bf476c2b fp : 000000f0 Jan 30 04:44:03 bananapi kernel: r10: 00000000 r9 : 00000025 r8 : bf4769fe Jan 30 04:44:03 bananapi kernel: r7 : 0000009b r6 : 00000000 r5 : bf475d5c r4 : c7f01e4c Jan 30 04:44:03 bananapi kernel: r3 : 00000008 r2 : 00000000 r1 : 00012567 r0 : 00000000 Jan 30 04:44:03 bananapi kernel: Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Jan 30 04:44:03 bananapi kernel: Control: 10c5387d Table: 47d2806a DAC: 00000051
Message from syslogd@bananapi at Jan 30 04:44:03 ... kernel:Process pvrusb2-context (pid: 824, stack limit = 0xc7f00220) Jan 30 04:44:03 bananapi kernel: Process pvrusb2-context (pid: 824, stack limit = 0xc7f00220)
Message from syslogd@bananapi at Jan 30 04:44:03 ... kernel:Stack: (0xc7f01d88 to 0xc7f02000) Jan 30 04:44:03 bananapi kernel: Stack: (0xc7f01d88 to 0xc7f02000)
Message from syslogd@bananapi at Jan 30 04:44:03 ... kernel:1d80: ee8c2000 bf47c518 00000011 c7f00000 00000001 00000001 Jan 30 04:44:03 bananapi kernel: 1d80: ee8c2000 bf47c518 00000011 c7f00000 00000001 00000001
[SNIP]
On 02/03/2018 10:40 AM, Chris Szilagyi wrote:
I seem to have stumbled upon an issue larger than I thought. I have been fighting this driver in the 4.9.75-204 kernel that is the current release for the AltArch/Arm32 platforms. Basically I'm getting a kernel oops with this kernel (I included below). I have tried patching and compiling my own module however I'm now getting a segfault with that. It seems that the 4.14 kernel may have resolved this issue:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/dr...
But I'm hoping to get this fixed with the 4.9.75 kernel or the 4.9.x series if that is what will be used for future kernel updates for this platform. I found a post regarding the issue on an Ubuntu forum and it appears this is the same thing I'm getting with this CentOS 4.9.75 kernel:
https://bugs.launchpad.net/ubuntu/+bug/1710419
This is the patch I tried and so far no luck. If anybody has a way to help or any thoughts on how to get this integrated to the kernels for this, I am more than happy to test it here on the Banana Pi.
Thank you for your help.
Chris
On 02/03/2018 12:37 AM, Chris Szilagyi wrote:
My apologies... I was running against only the kernel-devel source files rather than the full kernel source. It is working fine now that I found the correct kernel src.rpm package for this kernel.
Thank you... Chris
On 02/02/2018 09:59 PM, Chris Szilagyi wrote:
Hello:
I am attempting to re-compile a broken kernel module for the AltArch/Arm32 release. Currently I'm trying it against the current kernel, 4.9.75-204. In using "kernel-devel-4.9.75-204.el7.centos.armv7hl", and following the instructions for CentOS at : https://wiki.centos.org/HowTos/BuildingKernelModules, when I do a "make prepare", I am getting the error:
make[1]: *** No rule to make target `arch/arm/tools/gen-mach-types', needed by `include/generated/mach-types.h'. Stop. make: *** [archprepare] Error 2
I've been searching for a fix for this but not sure what is missing here. If you have a solution please let me know. Thanks for your help on this.
Chris _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
Chris, I think you are on the right track. Reverting commit https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/comm... on both stable 4.4 and 4.9 should fix the issue because neither of those branches received these commits (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/comm... , https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/comm...) so null is an invalid way to call. I think you should file a bug with this info on bugzilla.kernel.org and go from there. From the CentOS standpoint, don't know if such a patch could be applied, for next update, don't really have the authority there....
HTH. Pablo.
El 3/2/18 a las 12:40, Chris Szilagyi escribió:
I seem to have stumbled upon an issue larger than I thought. I have been fighting this driver in the 4.9.75-204 kernel that is the current release for the AltArch/Arm32 platforms. Basically I'm getting a kernel oops with this kernel (I included below). I have tried patching and compiling my own module however I'm now getting a segfault with that. It seems that the 4.14 kernel may have resolved this issue:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/dr...
But I'm hoping to get this fixed with the 4.9.75 kernel or the 4.9.x series if that is what will be used for future kernel updates for this platform. I found a post regarding the issue on an Ubuntu forum and it appears this is the same thing I'm getting with this CentOS 4.9.75 kernel:
https://bugs.launchpad.net/ubuntu/+bug/1710419
This is the patch I tried and so far no luck. If anybody has a way to help or any thoughts on how to get this integrated to the kernels for this, I am more than happy to test it here on the Banana Pi.
Thank you for your help.
Chris
On 02/03/2018 12:37 AM, Chris Szilagyi wrote:
My apologies... I was running against only the kernel-devel source files rather than the full kernel source. It is working fine now that I found the correct kernel src.rpm package for this kernel.
Thank you... Chris
On 02/02/2018 09:59 PM, Chris Szilagyi wrote:
Hello:
I am attempting to re-compile a broken kernel module for the AltArch/Arm32 release. Currently I'm trying it against the current kernel, 4.9.75-204. In using "kernel-devel-4.9.75-204.el7.centos.armv7hl", and following the instructions for CentOS at : https://wiki.centos.org/HowTos/BuildingKernelModules,%C2%A0 when I do a "make prepare", I am getting the error:
make[1]: *** No rule to make target `arch/arm/tools/gen-mach-types', needed by `include/generated/mach-types.h'. Stop. make: *** [archprepare] Error 2
I've been searching for a fix for this but not sure what is missing here. If you have a solution please let me know. Thanks for your help on this.
Chris _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
El 4/2/18 a las 12:15, Chris Szilagyi escribió:
Pablo, Thank you for the feedback. The problem I have faced with applying the patch myself and compiling the module are errors like this when I plug in the device:
Feb 3 13:11:48 bananapi kernel: pvrusb2: Unknown symbol __stack_chk_guard (err 0) Feb 3 13:11:48 bananapi kernel: pvrusb2: Unknown symbol __stack_chk_fail (err 0)
Using insmod directly shows this: insmod: ERROR: could not insert module pvrusb2.ko: Unknown symbol in module
Are you building the whole kernel or just the module? Sounds like different config, environment, etc...
I must still be missing something here.
One thing I had a tough time was finding the kernel source for what is used for these ARM releases. I googled and ended up finding: http://buildlogs-seed.centos.org/c7.1708.exp.i386/kernel/20180105174048/4.9...., and used that one. I figured the src.rpm there should work so that's what I ended up using to recompile just the pvrusb2 module, not sure if that would have anything to do with the problem.
That sounds like the right rpm, but you can also check here (http://vault.centos.org/altarch/7.4.1708/experimental/Source/i386/Source/SPa...)
I definitely have no problem filing a bug on bugzilla, I have a feeling they will say it's fixed in 4.14. I'm not sure if the CentOS ARM branch will continue with the 4.9 kernel or go up to a newer one which would fix the problem entirely. But for now if we are stuck with 4.9 I'm not sure how to proceed or if there's a way to get the patch applied for the next update.
I disagree, since both 4.4 and 4.9 are longterm, and regressions where introduced in "point" releases.
Thanks for the help.
Chris
<snip>
[SNIP]
Feb 3 13:11:48 bananapi kernel: pvrusb2: Unknown symbol __stack_chk_guard (err 0) Feb 3 13:11:48 bananapi kernel: pvrusb2: Unknown symbol __stack_chk_fail (err 0)
Using insmod directly shows this: insmod: ERROR: could not insert module pvrusb2.ko: Unknown symbol in module
Are you building the whole kernel or just the module? Sounds like different config, environment, etc...
Just the module. I've been following the instructions here: https://wiki.centos.org/HowTos/BuildingKernelModules But I am building on the device itself (Banana Pi). So I'm not doing any cross-compiling or anything.
Could this be a problem with a different config, from the running kernel? In the instructions it has be run "make oldconfig" which I thought was supposed to bring in the current config. However it still prompts for a lot of kernel options (regarding chipsets, etc.) and I have tried to make a best guess at them.
I must still be missing something here.
One thing I had a tough time was finding the kernel source for what is used for these ARM releases. I googled and ended up finding: http://buildlogs-seed.centos.org/c7.1708.exp.i386/kernel/20180105174048/4.9...., and used that one. I figured the src.rpm there should work so that's what I ended up using to recompile just the pvrusb2 module, not sure if that would have anything to do with the problem.
That sounds like the right rpm, but you can also check here (http://vault.centos.org/altarch/7.4.1708/experimental/Source/i386/Source/SPa...)
Thank you for the link. Just for a test I did download this source RPM, and tried it but yet again I am getting the errors:
Feb 4 17:21:54 bananapi kernel: pvrusb2: loading out-of-tree module taints kernel. Feb 4 17:21:54 bananapi kernel: pvrusb2: Unknown symbol __stack_chk_guard (err 0) Feb 4 17:21:54 bananapi kernel: pvrusb2: Unknown symbol __stack_chk_fail (err 0)
Not sure why, as I thought it would be OK since the source matches the running kernel.
I definitely have no problem filing a bug on bugzilla, I have a feeling they will say it's fixed in 4.14. I'm not sure if the CentOS ARM branch will continue with the 4.9 kernel or go up to a newer one which would fix the problem entirely. But for now if we are stuck with 4.9 I'm not sure how to proceed or if there's a way to get the patch applied for the next update.
I disagree, since both 4.4 and 4.9 are longterm, and regressions where introduced in "point" releases.
OK very good, I did not know that.
Thank you again for your help.
Chris
El 4/2/18 a las 14:28, Chris Szilagyi escribió:
[SNIP]
Feb 3 13:11:48 bananapi kernel: pvrusb2: Unknown symbol __stack_chk_guard (err 0) Feb 3 13:11:48 bananapi kernel: pvrusb2: Unknown symbol __stack_chk_fail (err 0)
Using insmod directly shows this: insmod: ERROR: could not insert module pvrusb2.ko: Unknown symbol in module
Are you building the whole kernel or just the module? Sounds like different config, environment, etc...
Just the module. I've been following the instructions here: https://wiki.centos.org/HowTos/BuildingKernelModules But I am building on the device itself (Banana Pi). So I'm not doing any cross-compiling or anything.
Could this be a problem with a different config, from the running kernel? In the instructions it has be run "make oldconfig" which I thought was supposed to bring in the current config. However it still prompts for a lot of kernel options (regarding chipsets, etc.) and I have tried to make a best guess at them.
If you copied the right .config, it shouldn't ask anything. Make oldconfig just takes your current .config and asks for what is missing (current as in copied to the root of your kernel build dir, not as in "booted" version). I have never done what you are doing, but I would do it this way: 1) rpmbuild -bp kernel.spec so original patches are applied. 2) copy current config from /boot to .config in your build environment 3) apply the patch you want 4) make oldconfig (should not ask a single question, since you didn't activate anything) 5) continue with your usual steps.
HTH. Pablo.
On 02/04/2018 01:07 PM, Pablo Sebastián Greco wrote:
[SNIP]
If you copied the right .config, it shouldn't ask anything. Make oldconfig just takes your current .config and asks for what is missing (current as in copied to the root of your kernel build dir, not as in "booted" version). I have never done what you are doing, but I would do it this way:
- rpmbuild -bp kernel.spec so original patches are applied.
- copy current config from /boot to .config in your build environment
- apply the patch you want
- make oldconfig (should not ask a single question, since you didn't
activate anything) 5) continue with your usual steps.
HTH. Pablo.
That worked! Thanks so much. I followed your instructions and everything worked straight through this time. I did also need to copy Module.symvers from the source from the kernel-devel package to the build directory, but your solution did the trick. The module compiled and everything is working now with the Hauppauge device!
I will also submit a bug as suggested as well, in case this can help others, too.
Chris
Great!!!. After you file the bug, please post back here for reference.
Pablo.
El 4/2/18 a las 16:56, Chris Szilagyi escribió:
On 02/04/2018 01:07 PM, Pablo Sebastián Greco wrote:
[SNIP]
If you copied the right .config, it shouldn't ask anything. Make oldconfig just takes your current .config and asks for what is missing (current as in copied to the root of your kernel build dir, not as in "booted" version). I have never done what you are doing, but I would do it this way:
- rpmbuild -bp kernel.spec so original patches are applied.
- copy current config from /boot to .config in your build environment
- apply the patch you want
- make oldconfig (should not ask a single question, since you didn't
activate anything) 5) continue with your usual steps.
HTH. Pablo.
That worked! Thanks so much. I followed your instructions and everything worked straight through this time. I did also need to copy Module.symvers from the source from the kernel-devel package to the build directory, but your solution did the trick. The module compiled and everything is working now with the Hauppauge device!
I will also submit a bug as suggested as well, in case this can help others, too.
Chris _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
It's been posted ...
https://bugzilla.kernel.org/show_bug.cgi?id=198675
Thanks again for your help here.
Chris
On 02/04/2018 03:10 PM, Pablo Sebastián Greco wrote:
Great!!!. After you file the bug, please post back here for reference.
Pablo.
El 4/2/18 a las 16:56, Chris Szilagyi escribió:
On 02/04/2018 01:07 PM, Pablo Sebastián Greco wrote:
[SNIP]
If you copied the right .config, it shouldn't ask anything. Make oldconfig just takes your current .config and asks for what is missing (current as in copied to the root of your kernel build dir, not as in "booted" version). I have never done what you are doing, but I would do it this way:
- rpmbuild -bp kernel.spec so original patches are applied.
- copy current config from /boot to .config in your build environment
- apply the patch you want
- make oldconfig (should not ask a single question, since you
didn't activate anything) 5) continue with your usual steps.
HTH. Pablo.
That worked! Thanks so much. I followed your instructions and everything worked straight through this time. I did also need to copy Module.symvers from the source from the kernel-devel package to the build directory, but your solution did the trick. The module compiled and everything is working now with the Hauppauge device!
I will also submit a bug as suggested as well, in case this can help others, too.
Chris _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev