st enable the rt_preempt relative options in the
> kernel withe the following method interactively:
>
> But this is very inconvenient for doing the above job in script. Is
> there an alternative method to generate the above configurations for
> kernel compilation non-interactively in scri
management and ACPI options
> > -> CPU Frequency scaling
> >-> CPU Frequency scaling (CPU_FREQ [=y])
> > -> Default CPUFreq governor ( [=y])
> > (X) performance
> >
> > But this is very inconvenient for doing the above job in script. Is
> &g
(X) Full dynticks system (tickless)
> >>>
> >>> # Set CONFIG_HZ_1000 (note: this is no longer in the General Setup
> >>> menu, go back twice)
> >>> -> Processor type and features
> >>> -> Timer frequency (1000 HZ)
> >>&
; -> Timer frequency (1000 HZ)
>>>(X) 1000 HZ
>>>
>>> # Set CPU_FREQ_DEFAULT_GOV_PERFORMANCE [=y]
>>> -> Power management and ACPI options
>>> -> CPU Frequency scaling
>>>-> CPU Frequency scaling (CPU_FREQ [=y])
>>&g
management and ACPI options
> > -> CPU Frequency scaling
> >-> CPU Frequency scaling (CPU_FREQ [=y])
> > -> Default CPUFreq governor ( [=y])
> > (X) performance
> >
> > But this is very inconvenient for doing the above job in script. Is
> &g
Set CPU_FREQ_DEFAULT_GOV_PERFORMANCE [=y]
> -> Power management and ACPI options
> -> CPU Frequency scaling
>-> CPU Frequency scaling (CPU_FREQ [=y])
> -> Default CPUFreq governor ( [=y])
> (X) performance
>
> But this is very inconvenient for doing the abo
But this is very inconvenient for doing the above job in script. Is
there an alternative method to generate the above configurations for
kernel compilation non-interactively in script.
BR,
--
Assoc. Prof. Hongyi Zhao
Theory and Simulation of Materials
Hebei Polytechnic University of Science and
On Tue, 10 Nov 2020 at 08:44, Dmitry Osipenko wrote:
>
> 09.11.2020 10:25, Ard Biesheuvel пишет:
> ...
> >>> So the options are
> >>>
> >>> a) merge my patch that adds 2 bytes of opcode to the Thumb2 build
> >>> b) merge Dmitry's patch that adds an unconditional literal load to all
> >>> builds
>
09.11.2020 10:25, Ard Biesheuvel пишет:
...
>>> So the options are
>>>
>>> a) merge my patch that adds 2 bytes of opcode to the Thumb2 build
>>> b) merge Dmitry's patch that adds an unconditional literal load to all
>>> builds
>>> c) remove kernel mode handling from vfp_support_entry() [my other p
On Tue, 3 Nov 2020 at 09:43, Dmitry Osipenko wrote:
>
> 03.11.2020 10:24, Ard Biesheuvel пишет:
> > Still broken today
> >
> > https://kernelci.org/build/id/5fa0c1a74bdb1ea4063fe7e4/
> >
Still broken today
https://kernelci.org/build/id/5fa898baa00b5f3167db8857/
> > So the options are
> >
> > a)
03.11.2020 10:24, Ard Biesheuvel пишет:
> Still broken today
>
> https://kernelci.org/build/id/5fa0c1a74bdb1ea4063fe7e4/
>
> So the options are
>
> a) merge my patch that adds 2 bytes of opcode to the Thumb2 build
> b) merge Dmitry's patch that adds an unconditional literal load to all builds
>
On Thu, 29 Oct 2020 at 10:56, Ard Biesheuvel wrote:
>
> On Mon, 26 Oct 2020 at 09:58, Ard Biesheuvel wrote:
> >
> > On Thu, 22 Oct 2020 at 19:59, Ard Biesheuvel wrote:
> > >
> > > On Thu, 22 Oct 2020 at 19:48, Russell King - ARM Linux admin
> > > wrote:
> > > >
> > > > On Thu, Oct 22, 2020 at 0
On Mon, 26 Oct 2020 at 09:58, Ard Biesheuvel wrote:
>
> On Thu, 22 Oct 2020 at 19:59, Ard Biesheuvel wrote:
> >
> > On Thu, 22 Oct 2020 at 19:48, Russell King - ARM Linux admin
> > wrote:
> > >
> > > On Thu, Oct 22, 2020 at 06:33:17PM +0200, Ard Biesheuvel wrote:
> > > > On Thu, 22 Oct 2020 at 1
On Thu, 22 Oct 2020 at 19:59, Ard Biesheuvel wrote:
>
> On Thu, 22 Oct 2020 at 19:48, Russell King - ARM Linux admin
> wrote:
> >
> > On Thu, Oct 22, 2020 at 06:33:17PM +0200, Ard Biesheuvel wrote:
> > > On Thu, 22 Oct 2020 at 18:23, Russell King - ARM Linux admin
> > > wrote:
> > > >
> > > > On
22.10.2020 20:38, Russell King - ARM Linux admin пишет:
...
>> But the two line change isn't portable to stable kernels as-is, isn't it?
>
> Why not?
>
I assume we will need to define a new section, no?
On Thu, 22 Oct 2020 at 19:48, Russell King - ARM Linux admin
wrote:
>
> On Thu, Oct 22, 2020 at 06:33:17PM +0200, Ard Biesheuvel wrote:
> > On Thu, 22 Oct 2020 at 18:23, Russell King - ARM Linux admin
> > wrote:
> > >
> > > On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
> > > > O
On Thu, 22 Oct 2020 at 19:50, Russell King - ARM Linux admin
wrote:
>
> On Thu, Oct 22, 2020 at 07:47:57PM +0200, Ard Biesheuvel wrote:
> > On Thu, 22 Oct 2020 at 19:38, Russell King - ARM Linux admin
> > wrote:
> > >
> > > On Thu, Oct 22, 2020 at 07:34:38PM +0300, Dmitry Osipenko wrote:
> > > >
On Thu, Oct 22, 2020 at 07:47:57PM +0200, Ard Biesheuvel wrote:
> On Thu, 22 Oct 2020 at 19:38, Russell King - ARM Linux admin
> wrote:
> >
> > On Thu, Oct 22, 2020 at 07:34:38PM +0300, Dmitry Osipenko wrote:
> > > 22.10.2020 19:23, Russell King - ARM Linux admin пишет:
> > > > On Thu, Oct 22, 202
On Thu, Oct 22, 2020 at 06:33:17PM +0200, Ard Biesheuvel wrote:
> On Thu, 22 Oct 2020 at 18:23, Russell King - ARM Linux admin
> wrote:
> >
> > On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
> > > On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
> > > wrote:
> > > >
>
On Thu, 22 Oct 2020 at 19:38, Russell King - ARM Linux admin
wrote:
>
> On Thu, Oct 22, 2020 at 07:34:38PM +0300, Dmitry Osipenko wrote:
> > 22.10.2020 19:23, Russell King - ARM Linux admin пишет:
> > > On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
> > >> On Thu, 22 Oct 2020 at 1
On Thu, Oct 22, 2020 at 07:34:38PM +0300, Dmitry Osipenko wrote:
> 22.10.2020 19:23, Russell King - ARM Linux admin пишет:
> > On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
> >> On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
> >> wrote:
> >>>
> >>> On Thu, Oct 22, 2
22.10.2020 19:23, Russell King - ARM Linux admin пишет:
> On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
>> On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
>> wrote:
>>>
>>> On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
On Thu, 22 Oct 2020 at 17
On Thu, 22 Oct 2020 at 18:23, Russell King - ARM Linux admin
wrote:
>
> On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
> > On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
> > wrote:
> > >
> > > On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
> > > > O
On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
> On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
> wrote:
> >
> > On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
> > > On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko wrote:
> > > >
> > > > 22.10.2020 10:
On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
wrote:
>
> On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
> > On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko wrote:
> > >
> > > 22.10.2020 10:06, Ard Biesheuvel пишет:
> > > > On Thu, 22 Oct 2020 at 05:30, Kees Cook wro
On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
> On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko wrote:
> >
> > 22.10.2020 10:06, Ard Biesheuvel пишет:
> > > On Thu, 22 Oct 2020 at 05:30, Kees Cook wrote:
> > >>
> > >> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote
On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko wrote:
>
> 22.10.2020 10:06, Ard Biesheuvel пишет:
> > On Thu, 22 Oct 2020 at 05:30, Kees Cook wrote:
> >>
> >> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
> >>> 22.10.2020 02:40, Kees Cook пишет:
> On Thu, Oct 22, 2020 at 01
22.10.2020 10:06, Ard Biesheuvel пишет:
> On Thu, 22 Oct 2020 at 05:30, Kees Cook wrote:
>>
>> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
>>> 22.10.2020 02:40, Kees Cook пишет:
On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> The vfp_kmode_exception
22.10.2020 17:57, Russell King - ARM Linux admin пишет:
> On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
>> The vfp_kmode_exception() function now is unreachable using relative
>> branching in THUMB2 kernel configuration, resulting in a "relocation
>> truncated to fit: R_ARM_THM_J
On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> The vfp_kmode_exception() function now is unreachable using relative
> branching in THUMB2 kernel configuration, resulting in a "relocation
> truncated to fit: R_ARM_THM_JUMP19 against symbol `vfp_kmode_exception'"
> linker error. L
On Thu, 22 Oct 2020 at 05:30, Kees Cook wrote:
>
> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
> > 22.10.2020 02:40, Kees Cook пишет:
> > > On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> > >> The vfp_kmode_exception() function now is unreachable using relat
On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
> 22.10.2020 02:40, Kees Cook пишет:
> > On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> >> The vfp_kmode_exception() function now is unreachable using relative
> >> branching in THUMB2 kernel configuration, resulti
22.10.2020 02:40, Kees Cook пишет:
> On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
>> The vfp_kmode_exception() function now is unreachable using relative
>> branching in THUMB2 kernel configuration, resulting in a "relocation
>> truncated to fit: R_ARM_THM_JUMP19 against symbol
On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> The vfp_kmode_exception() function now is unreachable using relative
> branching in THUMB2 kernel configuration, resulting in a "relocation
> truncated to fit: R_ARM_THM_JUMP19 against symbol `vfp_kmode_exception'"
> linker error. L
The vfp_kmode_exception() function now is unreachable using relative
branching in THUMB2 kernel configuration, resulting in a "relocation
truncated to fit: R_ARM_THM_JUMP19 against symbol `vfp_kmode_exception'"
linker error. Let's use long jump in order to fix the issue.
Fixes: eff8728fe698 ("vmli
On Mon, Dec 11, 2017 at 07:30:33PM +0530, venkat.prashanth2...@gmail.com wrote:
> From: Venkat Prashanth B U
>
> This is the patch to the omap-dma.c file that fixes
> the following issues:
Thanks Venkat for the patch, but unforntunately it has some issues.
First a patch should do only one thing
From: Venkat Prashanth B U
This is the patch to the omap-dma.c file that fixes
the following issues:
1.redefinition of 'omap_dma_filter_fn' in the line 1273
of drivers/dma/omap-dma.c
2.drivers/dma/omap-dma.c:341: ERROR: code indent should
use tabs where possible reported by ./checkpatch.pl
3.d
kernel.org, "linux-kernel"
> Sent: Monday, December 31, 2012 11:33:19 AM
> Subject: kernel compilation failure on power7 system
>
> Stable kernel 3.7.1 failure to compile on power7 system here,
>
> arch/powerpc/kvm/built-in.o: In function `hdec_soon':
> /root/linux
Stable kernel 3.7.1 failure to compile on power7 system here,
arch/powerpc/kvm/built-in.o: In function `hdec_soon':
/root/linux-stable/arch/powerpc/kvm/book3s_hv_rmhandlers.S:1068:
undefined reference to `PACA_SPRG3'
make: *** [vmlinux] Error 1
reverted this commit fixed the problem,
-
01272
* [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.22-1.2115.nptl/fs/devfs'
make[1]: *** [_subdir_devfs] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.22-1.2115.nptl/fs'
make: *** [_dir_fs] Error 2
[EMAIL PROTECTED] linux-2.4]#
--
View this message in context:
On Jan 8 2007 18:48, Ram wrote:
>
> Actually, the some of the case values are defined as -
>
> case (u32)&CM_ICLKEN_WKUP:
> case (u32)&CM_FCLKEN_WKUP:
This looks like really broken code, if CM_* happen to be constants.
-`J'
--
-
To unsubscribe from this list: send the line "unsubscribe
Hi,
* Ram <[EMAIL PROTECTED]> [070108 05:18]:
> Hi,
> Im using linux-2.6.14-omap2430.
>
> Im using TI omap 2430 SDP.
>
> When i compile it with the eldk toolchain.
>
> I get an error listed at the end of this mail.
>
> The error is simple - case values should be constants, However, th
Hi,
Im using linux-2.6.14-omap2430.
Im using TI omap 2430 SDP.
When i compile it with the eldk toolchain.
I get an error listed at the end of this mail.
The error is simple - case values should be constants, However, the
toolchain gcc 4.0
is complaining that case values are not const
On 11/12/06, kalyan kumar <[EMAIL PROTECTED]> wrote:
I am not able to compile latest kernel code in cygwin environment. It
fails for not ELF error always and exits. Any suggestions please?
One suggestion: Don't do that.
That's not a supported way to build the kernel.
--
Jesper Juhl <[EMAIL P
I am not able to compile latest kernel code in cygwin environment. It
fails for not ELF error always and exits. Any suggestions please?
Thanks.
--
Regards
Kalyan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
I would like somebody more experienced to help me, because even though I
have read a lot about IDE kernel driver I didn't manage to find any
answer for the question I describe below. I have asked for quite time on
other groups but nobody helped me. I have gone through google on groups
and even
Hello. I'm trying to compile new kernel 2.4.3 and I get some errors:
yakov:/usr/src/linux$ make modules
make[2]: Entering directory `/home/linux-2.4.3/drivers/block'
gcc -D__KERNEL__ -I/home/linux-2.4.3/include -Wall -Wstrict-prototypes -O2
-fomi
t-frame-pointer -fno-strict-aliasing -
> that the main kernel is compiled with gcc, and linked with standard ld,
> and only the bootloader code is compiled using the bin86 (as86,
> ld86) tools. Am I right in interpreting this to mean that the main kernel
> is/can be 32-bit binary, and not strictly 16-bit?
The main kernel is 32bit. The
I was perusing the makefiles, and I've pretty much come to the conclusion
that the main kernel is compiled with gcc, and linked with standard ld,
and only the bootloader code is compiled using the bin86 (as86,
ld86) tools. Am I right in interpreting this to mean that the main kernel
is/can be 32-b
49 matches
Mail list logo
