System shutdown sequence
Hi, When system is going for shutdown, shutdown handler of each device driver is called. Does kernel in this sequence calls remove handler ? I believe that remove is not called if driver is built-in. Is my understanding correct ? Thanks, Rahul ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [Audio Driver Low power state]
Hi Gomathi, This is not the exact place for this query as this list is for people having queries on Kernel in general. You query mostly is on audio on certain platform. Check what is the support list for that like alsa-devel or alsa mailing list. On Wed, Mar 26, 2014 at 9:35 AM, Gomathi Kumar wrote: > Hi all, > > I am new to kernel work and am trying to understand the low power state of > audio driver. > > I am using ALC262 codec, hda_intel and 3.10 kernel code. > In this codec, d3_stop_clk flag is not set. So in the code flow I was able > to understand the following. > > if (!codec->pm_down_notified && > !bus->power_keep_link_on && (state & AC_PWRST_CLK_STOP_OK)) > > this particular condition in hda_power_work function fails, as > power_keep_link_on flag is directly based on d3_stop_clk flag. > > codec->d3_stop_clk = snd_hda_codec_get_supported_ps(codec, fg, > AC_PWRST_CLKSTOP); > > I modified the if condition to not check the power_keep_link_on flag. > After this change the audio is consuming lesser power, but I am not able to > see it going to suspend/runtime suspend. > > *Please clarify what is happening when I modify the if condition and how > audio device is consuming low power?* > > *Also please help me understand, the significance of flags EPSS and > D3_STOP_CLK and if they can be set by software code. * > > Thanks, > Gomathi > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -- Thanks and Regards Pramod ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[Audio Driver Low power state]
Hi all, I am new to kernel work and am trying to understand the low power state of audio driver. I am using ALC262 codec, hda_intel and 3.10 kernel code. In this codec, d3_stop_clk flag is not set. So in the code flow I was able to understand the following. if (!codec->pm_down_notified && !bus->power_keep_link_on && (state & AC_PWRST_CLK_STOP_OK)) this particular condition in hda_power_work function fails, as power_keep_link_on flag is directly based on d3_stop_clk flag. codec->d3_stop_clk = snd_hda_codec_get_supported_ps(codec, fg, AC_PWRST_CLKSTOP); I modified the if condition to not check the power_keep_link_on flag. After this change the audio is consuming lesser power, but I am not able to see it going to suspend/runtime suspend. *Please clarify what is happening when I modify the if condition and how audio device is consuming low power?* *Also please help me understand, the significance of flags EPSS and D3_STOP_CLK and if they can be set by software code. * Thanks, Gomathi ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Selecting a Linux Kernel Bug
On March 24, 2014 9:23:01 AM EDT, valdis.kletni...@vt.edu wrote: >On Mon, 24 Mar 2014 12:22:58 +0530, sanjeev sharma said: > >> Thanks and Let me subscribe so that I can start working on Bugs. > >Subscribing to lkml almost guarantees you won't have enough time to >actually work on bugs. > >"Note that nobody reads every post in linux-kernel. In fact, nobody who >expects >to have time left over to actually do any real kernel work will read >even half. >Except Alan Cox, but he's actually not human, but about a thousand >gnomes >working in under-ground caves in Swansea. None of the individual gnomes >read >all the postings either, they just work together really well." -- Linus >Torvalds > >The linux-kernel list has about 4 times the traffic now as when Linus >said that. I subscribe to a few subsystem lists, that is more than I can keep up with. I've never had the urge to even try lkml. For me it's ide/libata, ext4, xfs. I should drop ext4 as I rarely read it these days. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
regarding ext3 and RDF sesisons
Hi all, I'm creating a RDF session and using ext3 as my FS type. What i've noticed is that once the synchronization has been initiated between R1 and R2 i am unable to mount the device on R2 site. I always get a "Bad superblock error" . However if the RDF session is stopped or split then i'm able to mount the same device on R2 site. What i've so far found out is that when i try to mount (even with -r and -noload options). I see that the Journaling still seems to be active and during mount dmesg throws up error saying that "Journal recovery failed" . I dont have any debug tools to even follow the mount syscall. So i'm having to go through the code. But i'm not able to get the call stack once the mount syscall is called. Can anyone please help me find any docs or can you tell me how the call flow begins after the mount syscall is called. I'm aware of the VFS layer inbetween but i want to know the exact starting point to start tracing from. Thanks ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Managing kernel-updates in rpm
On Tue, Mar 25, 2014 at 09:32:11AM -0400, valdis.kletni...@vt.edu wrote: > On Tue, 25 Mar 2014 18:18:35 +0530, Saket Sinha said: > > >Its a proprietary driver so its not meant to be the part of > > mainline kernel. :( > > Hey Greg - how long did Linux carry around an entire freaking *architecture* > for the Voyager when there were only like 4 systems on the *planet* still in > existence? There was only 1 working system, and it was years :) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Managing kernel-updates in rpm
On Tue, Mar 25, 2014 at 06:18:35PM +0530, Saket Sinha wrote: > Hi Greg, > > Please find my response inline- > > >> > >>We have a rpm which installs a linux kernel driver. Now this > >> driver has some kernel-level dependencies especially Development Tools > >> (kernel-headers etc) such that they depend on running kernel version. > > > > I'd ask you first off, why is your kernel driver not merged upstream > > with the main kernel.org releases, to prevent any of these issues from > > ever happening? > > >Its a proprietary driver so its not meant to be the part of > mainline kernel. :( > > > Do you have a pointer to your driver somewhere so we can look at it to > > determine what is needed to be done to get it merged properly? > > > > I am sorry but I am not allowed to do that. Then I'm not allowed to help you, and asking for help from the community seems a bit rude to the community that you are relying on for your product. Take a look at this for details: http://www.linuxfoundation.org/collaborate/workgroups/technical-advisory-board-tab/kerneldriverstatement Good luck with the lawsuits, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Managing kernel-updates in rpm
On Tue, 25 Mar 2014 18:18:35 +0530, Saket Sinha said: >Its a proprietary driver so its not meant to be the part of > mainline kernel. :( Hey Greg - how long did Linux carry around an entire freaking *architecture* for the Voyager when there were only like 4 systems on the *planet* still in existence? > > Do you have a pointer to your driver somewhere so we can look at it to > > determine what is needed to be done to get it merged properly? > I am sorry but I am not allowed to do that. If you can't do that, you *probably* can't legally ship the code to customers either. Just thought you should consider that... pgp4ivMAFlfyO.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Managing kernel-updates in rpm
On Tue, 25 Mar 2014 12:54:12 +0530, Saket Sinha said: > Now this is very cumbersome and we plan to replace it with installing > a yum plugin through our rpm which allows user to update the kernel > level dependencies. dkms is your friend. Look to see how VirtualBox and NVidia use it for their kernel code. pgpUsyDlxNlMT.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Managing kernel-updates in rpm
Hi Greg, Please find my response inline- >> >>We have a rpm which installs a linux kernel driver. Now this >> driver has some kernel-level dependencies especially Development Tools >> (kernel-headers etc) such that they depend on running kernel version. > > I'd ask you first off, why is your kernel driver not merged upstream > with the main kernel.org releases, to prevent any of these issues from > ever happening? > Its a proprietary driver so its not meant to be the part of mainline kernel. :( > Do you have a pointer to your driver somewhere so we can look at it to > determine what is needed to be done to get it merged properly? > I am sorry but I am not allowed to do that. Regards, Saket Sinha ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Managing kernel-updates in rpm
On Tue, Mar 25, 2014 at 12:54:12PM +0530, Saket Sinha wrote: > Hi, > >We have a rpm which installs a linux kernel driver. Now this > driver has some kernel-level dependencies especially Development Tools > (kernel-headers etc) such that they depend on running kernel version. I'd ask you first off, why is your kernel driver not merged upstream with the main kernel.org releases, to prevent any of these issues from ever happening? Do you have a pointer to your driver somewhere so we can look at it to determine what is needed to be done to get it merged properly? thanks, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Vmalloc Information Needed
Hi Pramod, On Tue, Mar 25, 2014 at 5:08 PM, pramod gurav wrote: > Hi Arun, > > > On Tue, Mar 25, 2014 at 3:55 PM, Arun KS wrote: >> >> Hello Anup, >> >> On Sun, Mar 23, 2014 at 9:54 AM, Anup Buchke >> wrote: >> > For a user/kernel configuration of 3/1GB and (0-16M DMA , 16-896 - Low , >> > 896 >> > - 1024 - High ) >> > Q: Is amount of memory allocated to Vmalloc limited to 128MB? >> No. 128MB is the default vmalloc size. You can override by kernel boot >> argument vmalloc=n[KMG] > > > Ok. So will this reduce(adjust) the LOW_MEM and add that reduced LOW_MEM to > HIGH_MEM region in virtual address space? Exactly. Thanks, Arun >> >> >> Thanks, >> Arun >> > >> > I read an article which said to increase the Vmalloc allocation size we >> > need >> > to either >> > 1) Change user/kernel distribution like 2.75/1.25 which proportionately >> > increase the address space available to High memory >> > 2) For a fixed user/kernel distribution reduce the low memory like >> > 16-800 >> > thereby increasing the size available for high memory. >> > >> > In either of the case the memory for vmalloc is limited to user/kernel >> > distribution . i.e. the amount of virtual address space available in >> > high >> > memory. >> > >> > I am a beginner, so please let me know if my understanding is >> > correct..and >> > rectify in-case of wrong.? >> > >> > Thanks, >> > Anup Buchke. >> > >> > ___ >> > Kernelnewbies mailing list >> > Kernelnewbies@kernelnewbies.org >> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > >> >> ___ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > > -- > Thanks and Regards > Pramod ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How Kernel stack is used in case of different processor mode in ARM architecture?
Hello Rahul,
On Tue, Mar 25, 2014 at 5:01 PM, Rahul Garg wrote:
> Hi Arun,
>
> When I used word nested interrupt, I meant that in my interrupt
> handler I am enabling interrupts.
>
> and about "what made you believe we need system mode to support nesting?"
>
> I asked this question on SO, here is the link for its answer
>
> http://stackoverflow.com/a/22500017/769260
Its actually SVC mode. not system mode.
arch/arm/kernel/entry-armv.S. This file is your key.
>
> And thanks for your prompt answer :)
My pleasure.
Thanks,
Arun
>
> Regards
> Rahul
>
> On Tue, Mar 25, 2014 at 4:45 PM, Arun KS wrote:
>> On Tue, Mar 25, 2014 at 4:40 PM, Arun KS wrote:
>>> Hello Rahul,
>>>
>>> On Tue, Mar 25, 2014 at 4:10 PM, Rahul Garg wrote:
Hi Arun,
Lines from Robert Love :
Early in the 2.6 kernel process, an option was added to reduce the
stack size from two
pages down to one, providing only a 4KB stack on 32-bit systems.This
reduced memory
pressure because every process on the system previously needed two
pages of contiguous,
nonswappable kernel memory.To cope with the reduced stack size,
interrupt handlers
were given their own stack, one stack per processor, one page in
size.This stack is referred
to as the interrupt stack.Although the total size of the interrupt
stack is half that of the
original shared stack, the average stack space available is greater
because interrupt handlers
get the full page of memory to themselves.
>>>
>>> Kernel stack size is architecture dependent. Some architecture uses
>>> CONFIG_4KSTACKS to choose 4K stacks.
>>>
>>> Where as in arm, it is always 8KB.
>>>
>>> File:arch/arm/include/asm/thread_info.h
>>> #define THREAD_SIZE_ORDER 1
>>> #define THREAD_SIZE 8192
>>> #define THREAD_START_SP (THREAD_SIZE - 8)
>>>
So with these lines, it is clear that interrupt stack is used by
interrupt handlers. So can you please re-confirm your answer ?
>>> On ARM when there is an irq, the processor switches to irq mode. But
>>> the kernel switches to svc mode immediately and uses SVC stack, ie the
>>> stack of the current process.
>>>
>>> Why do you believe my be? :-)
>>> If you want re-confirmation, go through arch/arm/kernel/entry-armv.S
>>>
>>> Thanks,
>>> Arun
And one more thing, as you mentioned only interrupt, undefined and
abort have stack, So how nested interrupt is handled because for that
we need System mode stack ?
>> Interrupts are no more nested in linux kernel,
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/kernel/irq/handle.c?id=e58aa3d2d0cc01ad8d6f7f640a0670433f794922
>>
>> But nested exceptions(data, prefetch aborts etc) can still happen.
>>
>> And, what made you believe we need system mode to support nesting?
>> What difference does it make if it is svc mode?
>>
>> Thanks,
>> Arun
>>
>>
>>> ARM linux never use system mode for anything.
>>>
Regards
Rahul
On Tue, Mar 25, 2014 at 3:06 PM, Arun KS wrote:
> On Tue, Mar 25, 2014 at 2:58 PM, Arun KS wrote:
>> Hello Rahul,
>>
>> On Tue, Mar 25, 2014 at 6:29 AM, Rahul Garg
>> wrote:
>>> As I understand every process have a user stack and kernel stack.
>> True.
>>
>>> Apart from that there is a stack for every mode in ARM achitecture. So
>> This is wrong.
>> Only irq, abort and undefined modes have stacks in linux. That too is
>> very limited, 3 bytes per mode per cpu.
>> Have a look at arch/arm/kernel/irq.c
> Sorry. Wrong file, its at arch/arm/kernel/setup.c
>
> Thanks,
> Arun
>> struct stack {
>> u32 irq[3];
>> u32 abt[3];
>> u32 und[3];
>> } cacheline_aligned;
>>
>> kernel runs in SVC mode and the stack used belong to the kernel stack
>> of the current task.
>> Even irq, abort and undefined exception handlers use kernel stack of
>> current task. All the exception
>> handlers switch to SVC mode at a very early stage and use kernel
>> stack. Those 3 bytes are used
>> as stack just during the transition phase(for example transition from
>> irq to svc mode during and interrupt).
>>
>> Thanks,
>> Arun
>>> I want to know How different stack and stack pointer works in ARM
>>> modes? Also when this kernel stack associated with the process will be
>>> used ?
>>>
>>> ___
>>> Kernelnewbies mailing list
>>> Kernelnewbies@kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How Kernel stack is used in case of different processor mode in ARM architecture?
Hi Arun,
When I used word nested interrupt, I meant that in my interrupt
handler I am enabling interrupts.
and about "what made you believe we need system mode to support nesting?"
I asked this question on SO, here is the link for its answer
http://stackoverflow.com/a/22500017/769260
And thanks for your prompt answer :)
Regards
Rahul
On Tue, Mar 25, 2014 at 4:45 PM, Arun KS wrote:
> On Tue, Mar 25, 2014 at 4:40 PM, Arun KS wrote:
>> Hello Rahul,
>>
>> On Tue, Mar 25, 2014 at 4:10 PM, Rahul Garg wrote:
>>> Hi Arun,
>>>
>>> Lines from Robert Love :
>>>
>>> Early in the 2.6 kernel process, an option was added to reduce the
>>> stack size from two
>>> pages down to one, providing only a 4KB stack on 32-bit systems.This
>>> reduced memory
>>> pressure because every process on the system previously needed two
>>> pages of contiguous,
>>> nonswappable kernel memory.To cope with the reduced stack size,
>>> interrupt handlers
>>> were given their own stack, one stack per processor, one page in
>>> size.This stack is referred
>>> to as the interrupt stack.Although the total size of the interrupt
>>> stack is half that of the
>>> original shared stack, the average stack space available is greater
>>> because interrupt handlers
>>> get the full page of memory to themselves.
>>
>> Kernel stack size is architecture dependent. Some architecture uses
>> CONFIG_4KSTACKS to choose 4K stacks.
>>
>> Where as in arm, it is always 8KB.
>>
>> File:arch/arm/include/asm/thread_info.h
>> #define THREAD_SIZE_ORDER 1
>> #define THREAD_SIZE 8192
>> #define THREAD_START_SP (THREAD_SIZE - 8)
>>
>>>
>>>
>>> So with these lines, it is clear that interrupt stack is used by
>>> interrupt handlers. So can you please re-confirm your answer ?
>> On ARM when there is an irq, the processor switches to irq mode. But
>> the kernel switches to svc mode immediately and uses SVC stack, ie the
>> stack of the current process.
>>
>> Why do you believe my be? :-)
>> If you want re-confirmation, go through arch/arm/kernel/entry-armv.S
>>
>> Thanks,
>> Arun
>>>
>>> And one more thing, as you mentioned only interrupt, undefined and
>>> abort have stack, So how nested interrupt is handled because for that
>>> we need System mode stack ?
> Interrupts are no more nested in linux kernel,
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/kernel/irq/handle.c?id=e58aa3d2d0cc01ad8d6f7f640a0670433f794922
>
> But nested exceptions(data, prefetch aborts etc) can still happen.
>
> And, what made you believe we need system mode to support nesting?
> What difference does it make if it is svc mode?
>
> Thanks,
> Arun
>
>
>> ARM linux never use system mode for anything.
>>
>>>
>>> Regards
>>> Rahul
>>>
>>> On Tue, Mar 25, 2014 at 3:06 PM, Arun KS wrote:
On Tue, Mar 25, 2014 at 2:58 PM, Arun KS wrote:
> Hello Rahul,
>
> On Tue, Mar 25, 2014 at 6:29 AM, Rahul Garg
> wrote:
>> As I understand every process have a user stack and kernel stack.
> True.
>
>> Apart from that there is a stack for every mode in ARM achitecture. So
> This is wrong.
> Only irq, abort and undefined modes have stacks in linux. That too is
> very limited, 3 bytes per mode per cpu.
> Have a look at arch/arm/kernel/irq.c
Sorry. Wrong file, its at arch/arm/kernel/setup.c
Thanks,
Arun
> struct stack {
> u32 irq[3];
> u32 abt[3];
> u32 und[3];
> } cacheline_aligned;
>
> kernel runs in SVC mode and the stack used belong to the kernel stack
> of the current task.
> Even irq, abort and undefined exception handlers use kernel stack of
> current task. All the exception
> handlers switch to SVC mode at a very early stage and use kernel
> stack. Those 3 bytes are used
> as stack just during the transition phase(for example transition from
> irq to svc mode during and interrupt).
>
> Thanks,
> Arun
>> I want to know How different stack and stack pointer works in ARM
>> modes? Also when this kernel stack associated with the process will be
>> used ?
>>
>> ___
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Vmalloc Information Needed
Hi Arun, On Tue, Mar 25, 2014 at 3:55 PM, Arun KS wrote: > Hello Anup, > > On Sun, Mar 23, 2014 at 9:54 AM, Anup Buchke > wrote: > > For a user/kernel configuration of 3/1GB and (0-16M DMA , 16-896 - Low , > 896 > > - 1024 - High ) > > Q: Is amount of memory allocated to Vmalloc limited to 128MB? > No. 128MB is the default vmalloc size. You can override by kernel boot > argument vmalloc=n[KMG] > Ok. So will this reduce(adjust) the LOW_MEM and add that reduced LOW_MEM to HIGH_MEM region in virtual address space? > > Thanks, > Arun > > > > I read an article which said to increase the Vmalloc allocation size we > need > > to either > > 1) Change user/kernel distribution like 2.75/1.25 which proportionately > > increase the address space available to High memory > > 2) For a fixed user/kernel distribution reduce the low memory like 16-800 > > thereby increasing the size available for high memory. > > > > In either of the case the memory for vmalloc is limited to user/kernel > > distribution . i.e. the amount of virtual address space available in high > > memory. > > > > I am a beginner, so please let me know if my understanding is > correct..and > > rectify in-case of wrong.? > > > > Thanks, > > Anup Buchke. > > > > ___ > > Kernelnewbies mailing list > > Kernelnewbies@kernelnewbies.org > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- Thanks and Regards Pramod ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How Kernel stack is used in case of different processor mode in ARM architecture?
Hello Rahul,
On Tue, Mar 25, 2014 at 4:10 PM, Rahul Garg wrote:
> Hi Arun,
>
> Lines from Robert Love :
>
> Early in the 2.6 kernel process, an option was added to reduce the
> stack size from two
> pages down to one, providing only a 4KB stack on 32-bit systems.This
> reduced memory
> pressure because every process on the system previously needed two
> pages of contiguous,
> nonswappable kernel memory.To cope with the reduced stack size,
> interrupt handlers
> were given their own stack, one stack per processor, one page in
> size.This stack is referred
> to as the interrupt stack.Although the total size of the interrupt
> stack is half that of the
> original shared stack, the average stack space available is greater
> because interrupt handlers
> get the full page of memory to themselves.
Kernel stack size is architecture dependent. Some architecture uses
CONFIG_4KSTACKS to choose 4K stacks.
Where as in arm, it is always 8KB.
File:arch/arm/include/asm/thread_info.h
#define THREAD_SIZE_ORDER 1
#define THREAD_SIZE 8192
#define THREAD_START_SP (THREAD_SIZE - 8)
>
>
> So with these lines, it is clear that interrupt stack is used by
> interrupt handlers. So can you please re-confirm your answer ?
On ARM when there is an irq, the processor switches to irq mode. But
the kernel switches to svc mode immediately and uses SVC stack, ie the
stack of the current process.
Why do you believe my be? :-)
If you want re-confirmation, go through arch/arm/kernel/entry-armv.S
Thanks,
Arun
>
> And one more thing, as you mentioned only interrupt, undefined and
> abort have stack, So how nested interrupt is handled because for that
> we need System mode stack ?
ARM linux never use system mode for anything.
>
> Regards
> Rahul
>
> On Tue, Mar 25, 2014 at 3:06 PM, Arun KS wrote:
>> On Tue, Mar 25, 2014 at 2:58 PM, Arun KS wrote:
>>> Hello Rahul,
>>>
>>> On Tue, Mar 25, 2014 at 6:29 AM, Rahul Garg wrote:
As I understand every process have a user stack and kernel stack.
>>> True.
>>>
Apart from that there is a stack for every mode in ARM achitecture. So
>>> This is wrong.
>>> Only irq, abort and undefined modes have stacks in linux. That too is
>>> very limited, 3 bytes per mode per cpu.
>>> Have a look at arch/arm/kernel/irq.c
>> Sorry. Wrong file, its at arch/arm/kernel/setup.c
>>
>> Thanks,
>> Arun
>>> struct stack {
>>> u32 irq[3];
>>> u32 abt[3];
>>> u32 und[3];
>>> } cacheline_aligned;
>>>
>>> kernel runs in SVC mode and the stack used belong to the kernel stack
>>> of the current task.
>>> Even irq, abort and undefined exception handlers use kernel stack of
>>> current task. All the exception
>>> handlers switch to SVC mode at a very early stage and use kernel
>>> stack. Those 3 bytes are used
>>> as stack just during the transition phase(for example transition from
>>> irq to svc mode during and interrupt).
>>>
>>> Thanks,
>>> Arun
I want to know How different stack and stack pointer works in ARM
modes? Also when this kernel stack associated with the process will be
used ?
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How Kernel stack is used in case of different processor mode in ARM architecture?
On Tue, Mar 25, 2014 at 4:40 PM, Arun KS wrote:
> Hello Rahul,
>
> On Tue, Mar 25, 2014 at 4:10 PM, Rahul Garg wrote:
>> Hi Arun,
>>
>> Lines from Robert Love :
>>
>> Early in the 2.6 kernel process, an option was added to reduce the
>> stack size from two
>> pages down to one, providing only a 4KB stack on 32-bit systems.This
>> reduced memory
>> pressure because every process on the system previously needed two
>> pages of contiguous,
>> nonswappable kernel memory.To cope with the reduced stack size,
>> interrupt handlers
>> were given their own stack, one stack per processor, one page in
>> size.This stack is referred
>> to as the interrupt stack.Although the total size of the interrupt
>> stack is half that of the
>> original shared stack, the average stack space available is greater
>> because interrupt handlers
>> get the full page of memory to themselves.
>
> Kernel stack size is architecture dependent. Some architecture uses
> CONFIG_4KSTACKS to choose 4K stacks.
>
> Where as in arm, it is always 8KB.
>
> File:arch/arm/include/asm/thread_info.h
> #define THREAD_SIZE_ORDER 1
> #define THREAD_SIZE 8192
> #define THREAD_START_SP (THREAD_SIZE - 8)
>
>>
>>
>> So with these lines, it is clear that interrupt stack is used by
>> interrupt handlers. So can you please re-confirm your answer ?
> On ARM when there is an irq, the processor switches to irq mode. But
> the kernel switches to svc mode immediately and uses SVC stack, ie the
> stack of the current process.
>
> Why do you believe my be? :-)
> If you want re-confirmation, go through arch/arm/kernel/entry-armv.S
>
> Thanks,
> Arun
>>
>> And one more thing, as you mentioned only interrupt, undefined and
>> abort have stack, So how nested interrupt is handled because for that
>> we need System mode stack ?
Interrupts are no more nested in linux kernel,
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/kernel/irq/handle.c?id=e58aa3d2d0cc01ad8d6f7f640a0670433f794922
But nested exceptions(data, prefetch aborts etc) can still happen.
And, what made you believe we need system mode to support nesting?
What difference does it make if it is svc mode?
Thanks,
Arun
> ARM linux never use system mode for anything.
>
>>
>> Regards
>> Rahul
>>
>> On Tue, Mar 25, 2014 at 3:06 PM, Arun KS wrote:
>>> On Tue, Mar 25, 2014 at 2:58 PM, Arun KS wrote:
Hello Rahul,
On Tue, Mar 25, 2014 at 6:29 AM, Rahul Garg wrote:
> As I understand every process have a user stack and kernel stack.
True.
> Apart from that there is a stack for every mode in ARM achitecture. So
This is wrong.
Only irq, abort and undefined modes have stacks in linux. That too is
very limited, 3 bytes per mode per cpu.
Have a look at arch/arm/kernel/irq.c
>>> Sorry. Wrong file, its at arch/arm/kernel/setup.c
>>>
>>> Thanks,
>>> Arun
struct stack {
u32 irq[3];
u32 abt[3];
u32 und[3];
} cacheline_aligned;
kernel runs in SVC mode and the stack used belong to the kernel stack
of the current task.
Even irq, abort and undefined exception handlers use kernel stack of
current task. All the exception
handlers switch to SVC mode at a very early stage and use kernel
stack. Those 3 bytes are used
as stack just during the transition phase(for example transition from
irq to svc mode during and interrupt).
Thanks,
Arun
> I want to know How different stack and stack pointer works in ARM
> modes? Also when this kernel stack associated with the process will be
> used ?
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How Kernel stack is used in case of different processor mode in ARM architecture?
Hi Arun,
Lines from Robert Love :
Early in the 2.6 kernel process, an option was added to reduce the
stack size from two
pages down to one, providing only a 4KB stack on 32-bit systems.This
reduced memory
pressure because every process on the system previously needed two
pages of contiguous,
nonswappable kernel memory.To cope with the reduced stack size,
interrupt handlers
were given their own stack, one stack per processor, one page in
size.This stack is referred
to as the interrupt stack.Although the total size of the interrupt
stack is half that of the
original shared stack, the average stack space available is greater
because interrupt handlers
get the full page of memory to themselves.
So with these lines, it is clear that interrupt stack is used by
interrupt handlers. So can you please re-confirm your answer ?
And one more thing, as you mentioned only interrupt, undefined and
abort have stack, So how nested interrupt is handled because for that
we need System mode stack ?
Regards
Rahul
On Tue, Mar 25, 2014 at 3:06 PM, Arun KS wrote:
> On Tue, Mar 25, 2014 at 2:58 PM, Arun KS wrote:
>> Hello Rahul,
>>
>> On Tue, Mar 25, 2014 at 6:29 AM, Rahul Garg wrote:
>>> As I understand every process have a user stack and kernel stack.
>> True.
>>
>>> Apart from that there is a stack for every mode in ARM achitecture. So
>> This is wrong.
>> Only irq, abort and undefined modes have stacks in linux. That too is
>> very limited, 3 bytes per mode per cpu.
>> Have a look at arch/arm/kernel/irq.c
> Sorry. Wrong file, its at arch/arm/kernel/setup.c
>
> Thanks,
> Arun
>> struct stack {
>> u32 irq[3];
>> u32 abt[3];
>> u32 und[3];
>> } cacheline_aligned;
>>
>> kernel runs in SVC mode and the stack used belong to the kernel stack
>> of the current task.
>> Even irq, abort and undefined exception handlers use kernel stack of
>> current task. All the exception
>> handlers switch to SVC mode at a very early stage and use kernel
>> stack. Those 3 bytes are used
>> as stack just during the transition phase(for example transition from
>> irq to svc mode during and interrupt).
>>
>> Thanks,
>> Arun
>>> I want to know How different stack and stack pointer works in ARM
>>> modes? Also when this kernel stack associated with the process will be
>>> used ?
>>>
>>> ___
>>> Kernelnewbies mailing list
>>> Kernelnewbies@kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Vmalloc Information Needed
Hello Anup, On Sun, Mar 23, 2014 at 9:54 AM, Anup Buchke wrote: > For a user/kernel configuration of 3/1GB and (0-16M DMA , 16-896 - Low , 896 > - 1024 - High ) > Q: Is amount of memory allocated to Vmalloc limited to 128MB? No. 128MB is the default vmalloc size. You can override by kernel boot argument vmalloc=n[KMG] Thanks, Arun > > I read an article which said to increase the Vmalloc allocation size we need > to either > 1) Change user/kernel distribution like 2.75/1.25 which proportionately > increase the address space available to High memory > 2) For a fixed user/kernel distribution reduce the low memory like 16-800 > thereby increasing the size available for high memory. > > In either of the case the memory for vmalloc is limited to user/kernel > distribution . i.e. the amount of virtual address space available in high > memory. > > I am a beginner, so please let me know if my understanding is correct..and > rectify in-case of wrong.? > > Thanks, > Anup Buchke. > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How Kernel stack is used in case of different processor mode in ARM architecture?
On Tue, Mar 25, 2014 at 2:58 PM, Arun KS wrote:
> Hello Rahul,
>
> On Tue, Mar 25, 2014 at 6:29 AM, Rahul Garg wrote:
>> As I understand every process have a user stack and kernel stack.
> True.
>
>> Apart from that there is a stack for every mode in ARM achitecture. So
> This is wrong.
> Only irq, abort and undefined modes have stacks in linux. That too is
> very limited, 3 bytes per mode per cpu.
> Have a look at arch/arm/kernel/irq.c
Sorry. Wrong file, its at arch/arm/kernel/setup.c
Thanks,
Arun
> struct stack {
> u32 irq[3];
> u32 abt[3];
> u32 und[3];
> } cacheline_aligned;
>
> kernel runs in SVC mode and the stack used belong to the kernel stack
> of the current task.
> Even irq, abort and undefined exception handlers use kernel stack of
> current task. All the exception
> handlers switch to SVC mode at a very early stage and use kernel
> stack. Those 3 bytes are used
> as stack just during the transition phase(for example transition from
> irq to svc mode during and interrupt).
>
> Thanks,
> Arun
>> I want to know How different stack and stack pointer works in ARM
>> modes? Also when this kernel stack associated with the process will be
>> used ?
>>
>> ___
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How Kernel stack is used in case of different processor mode in ARM architecture?
Hello Rahul,
On Tue, Mar 25, 2014 at 6:29 AM, Rahul Garg wrote:
> As I understand every process have a user stack and kernel stack.
True.
> Apart from that there is a stack for every mode in ARM achitecture. So
This is wrong.
Only irq, abort and undefined modes have stacks in linux. That too is
very limited, 3 bytes per mode per cpu.
Have a look at arch/arm/kernel/irq.c
struct stack {
u32 irq[3];
u32 abt[3];
u32 und[3];
} cacheline_aligned;
kernel runs in SVC mode and the stack used belong to the kernel stack
of the current task.
Even irq, abort and undefined exception handlers use kernel stack of
current task. All the exception
handlers switch to SVC mode at a very early stage and use kernel
stack. Those 3 bytes are used
as stack just during the transition phase(for example transition from
irq to svc mode during and interrupt).
Thanks,
Arun
> I want to know How different stack and stack pointer works in ARM
> modes? Also when this kernel stack associated with the process will be
> used ?
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Managing kernel-updates in rpm
Let me describe a scenario to explain my question - I first deployed a RHEL machine which happened to boot into kernel-2.6.32-358.14.1.el6.x86_64. Some time later I decided to install kernel-headers and kernel-devel, and therefore I ended up with kernel-devel-2.6.32-431.5.1.el6.x86_64 and kernel-headers-2.6.32-431.5.1.el6.x86_64. Note that these differ from the running kernel in minor version (358 and 431). This is normal and expected with RHEL but it breaks the installation of my driver. I will also explain why my driver has dependencies on these packages In this condition, my driver rpm will try to install a driver for version 2.6.32-358.14.1.el6.x86_64 which is the currently running kernel. Since the rpm does not contain a driver for this exact kernel, I do not fail my driver. NOW HERE WHAT CAN I DO. I HAVE FOUND THE FOLLOWING SOLUTION. In my rpm's SPEC file, I try to build my driver with kernel-devel & Development Tools. Thus my rpm has dependencies on two packages kernel-devel and development-tools. Most of the times this is successful. But look at the above scenario. What all I have in the above scenario- kernel-devel-2.6.32-431.5.1.el6.x86_64 kernel-headers-2.6.32-431.5.1.el6.x86_64 kernel-firmware-2.6.32-358.14.1.el6.noarch kernel-2.6.32-358.14.1.el6.x86_64 And although it appears that kernel-devel is installed, it is installed for a different version from the running kernel, hence the failure. Now I thought of installing a yum plugin with my rpm to handle kernel updates rather than the above approach. Is this approach right? Regards, Saket Sinha ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Managing kernel-updates in rpm
Saket, IMO, explore the option of kABI and/or DKMS. http://people.redhat.com/jcm/el6/dup/docs/dup_book.pdf http://linux.dell.com/dkms/dkms-ols2004.pdf HTH On Tue, Mar 25, 2014 at 12:54 PM, Saket Sinha wrote: > Hi, > >We have a rpm which installs a linux kernel driver. Now this > driver has some kernel-level dependencies especially Development Tools > (kernel-headers etc) such that they depend on running kernel version. > > Now in the rpm we provide drivers for different kernel versions since > the user can update the kernel. In the rpm's SPEC file, we match the > running kernel version with our driver for that particular version and > install it. > > If the user has updated its kernel to such a version whose driver is > not present in the RPM, the installation fails. We tell user in the > error message to update the kernel to a supported version. > > Now this is very cumbersome and we plan to replace it with installing > a yum plugin through our rpm which allows user to update the kernel > level dependencies. > > Is this a right approach? > > Regards, > Saket Sinha > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- easy is right begin right and you're easy continue easy and you're right the right way to go easy is to forget the right way and forget that the going is easy ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Managing kernel-updates in rpm
Hi, We have a rpm which installs a linux kernel driver. Now this driver has some kernel-level dependencies especially Development Tools (kernel-headers etc) such that they depend on running kernel version. Now in the rpm we provide drivers for different kernel versions since the user can update the kernel. In the rpm's SPEC file, we match the running kernel version with our driver for that particular version and install it. If the user has updated its kernel to such a version whose driver is not present in the RPM, the installation fails. We tell user in the error message to update the kernel to a supported version. Now this is very cumbersome and we plan to replace it with installing a yum plugin through our rpm which allows user to update the kernel level dependencies. Is this a right approach? Regards, Saket Sinha ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
