* [ARM_LINUX] ioremap() allowing to map system memory... @ 2013-03-01 11:18 sandeep kumar 2013-03-01 11:28 ` Prabhu nath 2013-03-01 17:29 ` Valdis.Kletnieks at vt.edu 0 siblings, 2 replies; 9+ messages in thread From: sandeep kumar @ 2013-03-01 11:18 UTC (permalink / raw) To: kernelnewbies Hi All I am using ARM based board. In mine, i did the following... void __iomem *tcpm_base = ioremap_nocache(0x03B00000, 10*SZ_3MB); Actually i didnt reserve the 30MB memory @ 0x3B00000. But still the call is succesful and i am able to read the memory. In the logs it is just showing a warning, to fix my driver as i am calling ioremap() on system memory. However if i try to write something on that memory, then only it is calling panic().. Don't you think it should throw panic()while calling the ioremap() itself. Because this sounds like a serious violation... What say? -- With regards, Sandeep Kumar Anantapalli, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130301/47ae0267/attachment.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ARM_LINUX] ioremap() allowing to map system memory... 2013-03-01 11:18 [ARM_LINUX] ioremap() allowing to map system memory sandeep kumar @ 2013-03-01 11:28 ` Prabhu nath 2013-03-01 12:27 ` sandeep kumar 2013-03-01 17:29 ` Valdis.Kletnieks at vt.edu 1 sibling, 1 reply; 9+ messages in thread From: Prabhu nath @ 2013-03-01 11:28 UTC (permalink / raw) To: kernelnewbies On Fri, Mar 1, 2013 at 4:48 PM, sandeep kumar <coolsandyforyou@gmail.com>wrote: > Hi All > I am using ARM based board. > In mine, > i did the following... > > void __iomem *tcpm_base = ioremap_nocache(0x03B00000, 10*SZ_3MB); > > Actually i didnt reserve the 30MB memory @ 0x3B00000. But still the call > is succesful and i am able to read the memory. > > In the logs it is just showing a warning, to fix my driver as i am calling > ioremap() on system memory. > > However if i try to write something on that memory, then only it is > calling panic().. > > Don't you think it should throw panic()while calling the ioremap() itself. > Because this sounds like a serious violation... > > What say? > To my knowledge, ioremap is used only to map the device related physical address to kernel virtual address. i.e. this function will only map either device registers or device memory to kernel virtual address. Looks like you are trying to pass the address of physical memory to this function as a parameter and it is screwing up. Please verify. Regards, Prabhu -- > With regards, > Sandeep Kumar Anantapalli, > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130301/baef5c85/attachment.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ARM_LINUX] ioremap() allowing to map system memory... 2013-03-01 11:28 ` Prabhu nath @ 2013-03-01 12:27 ` sandeep kumar 2013-03-02 11:22 ` Prabhu nath 0 siblings, 1 reply; 9+ messages in thread From: sandeep kumar @ 2013-03-01 12:27 UTC (permalink / raw) To: kernelnewbies >Looks like you are trying to pass the address of physical memory to this function as a parameter and it is screwing up. Yes, i intentionally gave some physical address which is part of system memory. My problem infact is, it is not screwing up. It is allowing me to do that. Its not 'panic'ing On Fri, Mar 1, 2013 at 4:58 PM, Prabhu nath <gprabhunath@gmail.com> wrote: > > > On Fri, Mar 1, 2013 at 4:48 PM, sandeep kumar <coolsandyforyou@gmail.com>wrote: > >> Hi All >> I am using ARM based board. >> In mine, >> i did the following... >> >> void __iomem *tcpm_base = ioremap_nocache(0x03B00000, 10*SZ_3MB); >> >> Actually i didnt reserve the 30MB memory @ 0x3B00000. But still the call >> is succesful and i am able to read the memory. >> >> In the logs it is just showing a warning, to fix my driver as i am >> calling ioremap() on system memory. >> >> However if i try to write something on that memory, then only it is >> calling panic().. >> >> Don't you think it should throw panic()while calling the ioremap() >> itself. Because this sounds like a serious violation... >> >> What say? >> > > To my knowledge, ioremap is used only to map the device related physical > address to kernel virtual address. i.e. this function will only map either > device registers or device memory to kernel virtual address. > > Looks like you are trying to pass the address of physical memory to this > function as a parameter and it is screwing up. > > Please verify. > > Regards, > Prabhu > > -- >> With regards, >> Sandeep Kumar Anantapalli, >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies at kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> >> > -- With regards, Sandeep Kumar Anantapalli, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130301/e472ab16/attachment-0001.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ARM_LINUX] ioremap() allowing to map system memory... 2013-03-01 12:27 ` sandeep kumar @ 2013-03-02 11:22 ` Prabhu nath 2013-03-02 17:18 ` sandeep kumar 0 siblings, 1 reply; 9+ messages in thread From: Prabhu nath @ 2013-03-02 11:22 UTC (permalink / raw) To: kernelnewbies In principle, ioremap() will return 0x00000000 if the physical address passed is of memory. I just want you to double check the address you have passed to ioremap(). In my experiment on x86 Desktop machine with 2GB RAM. I passed a physical address 0x63ACD000. As expected it returned 0x00000000. I am running linux version 3.5.1. Regards, Prabhunath G Linux Trainer Bangalore On Fri, Mar 1, 2013 at 5:57 PM, sandeep kumar <coolsandyforyou@gmail.com>wrote: > >Looks like you are trying to pass the address of physical memory to this > function as a parameter and it is screwing up. > Yes, i intentionally gave some physical address which is part of system > memory. > My problem infact is, it is not screwing up. It is allowing me to do that. > Its not 'panic'ing > > > On Fri, Mar 1, 2013 at 4:58 PM, Prabhu nath <gprabhunath@gmail.com> wrote: > >> >> >> On Fri, Mar 1, 2013 at 4:48 PM, sandeep kumar <coolsandyforyou@gmail.com>wrote: >> >>> Hi All >>> I am using ARM based board. >>> In mine, >>> i did the following... >>> >>> void __iomem *tcpm_base = ioremap_nocache(0x03B00000, 10*SZ_3MB); >>> >>> Actually i didnt reserve the 30MB memory @ 0x3B00000. But still the call >>> is succesful and i am able to read the memory. >>> >>> In the logs it is just showing a warning, to fix my driver as i am >>> calling ioremap() on system memory. >>> >>> However if i try to write something on that memory, then only it is >>> calling panic().. >>> >>> Don't you think it should throw panic()while calling the ioremap() >>> itself. Because this sounds like a serious violation... >>> >>> What say? >>> >> >> To my knowledge, ioremap is used only to map the device related physical >> address to kernel virtual address. i.e. this function will only map either >> device registers or device memory to kernel virtual address. >> >> Looks like you are trying to pass the address of physical memory to this >> function as a parameter and it is screwing up. >> >> Please verify. >> >> Regards, >> Prabhu >> >> -- >>> With regards, >>> Sandeep Kumar Anantapalli, >>> >>> _______________________________________________ >>> Kernelnewbies mailing list >>> Kernelnewbies at kernelnewbies.org >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>> >>> >> > > > -- > With regards, > Sandeep Kumar Anantapalli, > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130302/15d2391b/attachment.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ARM_LINUX] ioremap() allowing to map system memory... 2013-03-02 11:22 ` Prabhu nath @ 2013-03-02 17:18 ` sandeep kumar 2013-03-04 8:02 ` buyitian 0 siblings, 1 reply; 9+ messages in thread From: sandeep kumar @ 2013-03-02 17:18 UTC (permalink / raw) To: kernelnewbies >I passed a physical address 0x63ACD000. As expected it returned 0x00000000. I am running linux version 3.5.1. Mine is ARM, i donno about x86. In my case ioremap is successfule and giving an address in ioremap() range of virtual memory map as in http://www.arm.linux.org.uk/developer/memory.txt. On Sat, Mar 2, 2013 at 4:52 PM, Prabhu nath <gprabhunath@gmail.com> wrote: > In principle, ioremap() will return 0x00000000 if the physical address > passed is of memory. > I just want you to double check the address you have passed to ioremap(). > In my experiment on x86 Desktop machine with 2GB RAM. I passed a physical > address 0x63ACD000. As expected it returned 0x00000000. I am running linux > version 3.5.1. > > > Regards, > Prabhunath G > Linux Trainer > Bangalore > > > On Fri, Mar 1, 2013 at 5:57 PM, sandeep kumar <coolsandyforyou@gmail.com>wrote: > >> >Looks like you are trying to pass the address of physical memory to this >> function as a parameter and it is screwing up. >> Yes, i intentionally gave some physical address which is part of system >> memory. >> My problem infact is, it is not screwing up. It is allowing me to do >> that. Its not 'panic'ing >> >> >> On Fri, Mar 1, 2013 at 4:58 PM, Prabhu nath <gprabhunath@gmail.com>wrote: >> >>> >>> >>> On Fri, Mar 1, 2013 at 4:48 PM, sandeep kumar <coolsandyforyou@gmail.com >>> > wrote: >>> >>>> Hi All >>>> I am using ARM based board. >>>> In mine, >>>> i did the following... >>>> >>>> void __iomem *tcpm_base = ioremap_nocache(0x03B00000, 10*SZ_3MB); >>>> >>>> Actually i didnt reserve the 30MB memory @ 0x3B00000. But still the >>>> call is succesful and i am able to read the memory. >>>> >>>> In the logs it is just showing a warning, to fix my driver as i am >>>> calling ioremap() on system memory. >>>> >>>> However if i try to write something on that memory, then only it is >>>> calling panic().. >>>> >>>> Don't you think it should throw panic()while calling the ioremap() >>>> itself. Because this sounds like a serious violation... >>>> >>>> What say? >>>> >>> >>> To my knowledge, ioremap is used only to map the device related physical >>> address to kernel virtual address. i.e. this function will only map either >>> device registers or device memory to kernel virtual address. >>> >>> Looks like you are trying to pass the address of physical memory to this >>> function as a parameter and it is screwing up. >>> >>> Please verify. >>> >>> Regards, >>> Prabhu >>> >>> -- >>>> With regards, >>>> Sandeep Kumar Anantapalli, >>>> >>>> _______________________________________________ >>>> Kernelnewbies mailing list >>>> Kernelnewbies at kernelnewbies.org >>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>>> >>>> >>> >> >> >> -- >> With regards, >> Sandeep Kumar Anantapalli, >> > > -- With regards, Sandeep Kumar Anantapalli, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130302/67f2aab9/attachment.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ARM_LINUX] ioremap() allowing to map system memory... 2013-03-02 17:18 ` sandeep kumar @ 2013-03-04 8:02 ` buyitian 2013-03-04 9:48 ` sandeep kumar 0 siblings, 1 reply; 9+ messages in thread From: buyitian @ 2013-03-04 8:02 UTC (permalink / raw) To: kernelnewbies ________________________________ > From: coolsandyforyou at gmail.com > Date: Sat, 2 Mar 2013 22:48:34 +0530 > Subject: Re: [ARM_LINUX] ioremap() allowing to map system memory... > To: gprabhunath at gmail.com > CC: kernelnewbies at kernelnewbies.org > > >I passed a physical address 0x63ACD000. As expected it returned > 0x00000000. I am running linux version 3.5.1. > Mine is ARM, i donno about x86. In my case ioremap is successfule and > giving an address in ioremap() range of virtual memory map as > in http://www.arm.linux.org.uk/developer/memory.txt. please give your detail calling example, it is weired that you did not get 0x0 returned. maybe your platform overwirte the arch_ioremap_caller? please double check this. the default implementation for arch_ioremap_caller is as below: void __iomem * (*arch_ioremap_caller)(unsigned long, size_t, unsigned int, void *) = __arm_ioremap_caller; in \arch\arm\mm\ioremap.c, in function __arm_ioremap_pfn_caller: /* * Don't allow RAM to be mapped - this causes problems with ARMv6+ */ if (WARN_ON(pfn_valid(pfn))) return NULL; you should get NULL if you are asking convert a valid memory. > > > On Sat, Mar 2, 2013 at 4:52 PM, Prabhu nath > <gprabhunath at gmail.com<mailto:gprabhunath@gmail.com>> wrote: > In principle, ioremap() will return 0x00000000 if the physical address > passed is of memory. > I just want you to double check the address you have passed to ioremap(). > In my experiment on x86 Desktop machine with 2GB RAM. I passed a > physical address 0x63ACD000. As expected it returned 0x00000000. I am > running linux version 3.5.1. > > > Regards, > Prabhunath G > Linux Trainer > Bangalore > > > On Fri, Mar 1, 2013 at 5:57 PM, sandeep kumar > <coolsandyforyou at gmail.com<mailto:coolsandyforyou@gmail.com>> wrote: > >Looks like you are trying to pass the address of physical memory to > this function as a parameter and it is screwing up. > Yes, i intentionally gave some physical address which is part of system > memory. > My problem infact is, it is not screwing up. It is allowing me to do > that. Its not 'panic'ing > > > On Fri, Mar 1, 2013 at 4:58 PM, Prabhu nath > <gprabhunath at gmail.com<mailto:gprabhunath@gmail.com>> wrote: > > > On Fri, Mar 1, 2013 at 4:48 PM, sandeep kumar > <coolsandyforyou at gmail.com<mailto:coolsandyforyou@gmail.com>> wrote: > Hi All > I am using ARM based board. > In mine, > i did the following... > > void __iomem *tcpm_base = ioremap_nocache(0x03B00000, 10*SZ_3MB); > > Actually i didnt reserve the 30MB memory @ 0x3B00000. But still the > call is succesful and i am able to read the memory. > > In the logs it is just showing a warning, to fix my driver as i am > calling ioremap() on system memory. > > However if i try to write something on that memory, then only it is > calling panic().. > > Don't you think it should throw panic()while calling the ioremap() > itself. Because this sounds like a serious violation... > > What say? > > To my knowledge, ioremap is used only to map the device related > physical address to kernel virtual address. i.e. this function will > only map either device registers or device memory to kernel virtual > address. > > Looks like you are trying to pass the address of physical memory to > this function as a parameter and it is screwing up. > > Please verify. > > Regards, > Prabhu > > -- > With regards, > Sandeep Kumar Anantapalli, > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org<mailto:Kernelnewbies@kernelnewbies.org> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > > > -- > With regards, > Sandeep Kumar Anantapalli, > > > > > -- > With regards, > Sandeep Kumar Anantapalli, > > _______________________________________________ Kernelnewbies mailing > list Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ARM_LINUX] ioremap() allowing to map system memory... 2013-03-04 8:02 ` buyitian @ 2013-03-04 9:48 ` sandeep kumar 0 siblings, 0 replies; 9+ messages in thread From: sandeep kumar @ 2013-03-04 9:48 UTC (permalink / raw) To: kernelnewbies >please give your detail calling example, it is weired that you did not get >0x0 returned. I have the following code like below. In my case it is not returning NULL. /* * Don't allow RAM to be mapped - this causes problems with ARMv6+ */ if (pfn_valid(pfn)) { printk(KERN_WARNING "BUG: Your driver calls ioremap() on system memory. This leads\n" KERN_WARNING "to architecturally unpredictable behaviour on ARMv6+, and ioremap()\n" KERN_WARNING "will fail in the next kernel release. Please fix your driver.\n"); WARN_ON(1); } Thanks Sandeep On Mon, Mar 4, 2013 at 1:32 PM, buyitian <buyit@live.cn> wrote: > ________________________________ > > From: coolsandyforyou at gmail.com > > Date: Sat, 2 Mar 2013 22:48:34 +0530 > > Subject: Re: [ARM_LINUX] ioremap() allowing to map system memory... > > To: gprabhunath at gmail.com > > CC: kernelnewbies at kernelnewbies.org > > > > >I passed a physical address 0x63ACD000. As expected it returned > > 0x00000000. I am running linux version 3.5.1. > > Mine is ARM, i donno about x86. In my case ioremap is successfule and > > giving an address in ioremap() range of virtual memory map as > > in http://www.arm.linux.org.uk/developer/memory.txt. > > please give your detail calling example, it is weired that you did not get > 0x0 returned. > > maybe your platform overwirte the arch_ioremap_caller? please double check > this. > the default implementation for arch_ioremap_caller is as below: > void __iomem * (*arch_ioremap_caller)(unsigned long, size_t, > unsigned int, void *) = __arm_ioremap_caller; > > in \arch\arm\mm\ioremap.c, in function __arm_ioremap_pfn_caller: > > /* > * Don't allow RAM to be mapped - this causes problems with ARMv6+ > */ > if (WARN_ON(pfn_valid(pfn))) > return NULL; > > you should get NULL if you are asking convert a valid memory. > > > > > > > On Sat, Mar 2, 2013 at 4:52 PM, Prabhu nath > > <gprabhunath at gmail.com<mailto:gprabhunath@gmail.com>> wrote: > > In principle, ioremap() will return 0x00000000 if the physical address > > passed is of memory. > > I just want you to double check the address you have passed to ioremap(). > > In my experiment on x86 Desktop machine with 2GB RAM. I passed a > > physical address 0x63ACD000. As expected it returned 0x00000000. I am > > running linux version 3.5.1. > > > > > > Regards, > > Prabhunath G > > Linux Trainer > > Bangalore > > > > > > On Fri, Mar 1, 2013 at 5:57 PM, sandeep kumar > > <coolsandyforyou at gmail.com<mailto:coolsandyforyou@gmail.com>> wrote: > > >Looks like you are trying to pass the address of physical memory to > > this function as a parameter and it is screwing up. > > Yes, i intentionally gave some physical address which is part of system > > memory. > > My problem infact is, it is not screwing up. It is allowing me to do > > that. Its not 'panic'ing > > > > > > On Fri, Mar 1, 2013 at 4:58 PM, Prabhu nath > > <gprabhunath at gmail.com<mailto:gprabhunath@gmail.com>> wrote: > > > > > > On Fri, Mar 1, 2013 at 4:48 PM, sandeep kumar > > <coolsandyforyou at gmail.com<mailto:coolsandyforyou@gmail.com>> wrote: > > Hi All > > I am using ARM based board. > > In mine, > > i did the following... > > > > void __iomem *tcpm_base = ioremap_nocache(0x03B00000, 10*SZ_3MB); > > > > Actually i didnt reserve the 30MB memory @ 0x3B00000. But still the > > call is succesful and i am able to read the memory. > > > > In the logs it is just showing a warning, to fix my driver as i am > > calling ioremap() on system memory. > > > > However if i try to write something on that memory, then only it is > > calling panic().. > > > > Don't you think it should throw panic()while calling the ioremap() > > itself. Because this sounds like a serious violation... > > > > What say? > > > > To my knowledge, ioremap is used only to map the device related > > physical address to kernel virtual address. i.e. this function will > > only map either device registers or device memory to kernel virtual > > address. > > > > Looks like you are trying to pass the address of physical memory to > > this function as a parameter and it is screwing up. > > > > Please verify. > > > > Regards, > > Prabhu > > > > -- > > With regards, > > Sandeep Kumar Anantapalli, > > > > _______________________________________________ > > Kernelnewbies mailing list > > Kernelnewbies at kernelnewbies.org<mailto:Kernelnewbies@kernelnewbies.org> > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > > > > > > > > > -- > > With regards, > > Sandeep Kumar Anantapalli, > > > > > > > > > > -- > > With regards, > > Sandeep Kumar Anantapalli, > > > > _______________________________________________ Kernelnewbies mailing > > list Kernelnewbies at kernelnewbies.org > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -- With regards, Sandeep Kumar Anantapalli, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130304/ee081dcf/attachment-0001.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ARM_LINUX] ioremap() allowing to map system memory... 2013-03-01 11:18 [ARM_LINUX] ioremap() allowing to map system memory sandeep kumar 2013-03-01 11:28 ` Prabhu nath @ 2013-03-01 17:29 ` Valdis.Kletnieks at vt.edu 2013-03-01 17:56 ` Arlie Stephens 1 sibling, 1 reply; 9+ messages in thread From: Valdis.Kletnieks at vt.edu @ 2013-03-01 17:29 UTC (permalink / raw) To: kernelnewbies On Fri, 01 Mar 2013 16:48:12 +0530, sandeep kumar said: > Don't you think it should throw panic()while calling the ioremap() itself. > Because this sounds like a serious violation... As you noted, it does give you a warning. That's a kernel design philosophy - to reserve the panic() and BUG() calls for cases where it is *known* that proceeding further is unsafe or impossible. So the kernel does a panic() if it can't start /sbin/init at system boot-up - because without that, further progress is impossible. But once the system is up, we don't panic if PID 1 goes away - because it's possible that the user has an open window, and can su and at least do an orderly shutdown. Similarly, if a device driver gets confused, the driver code may do a BUG_ON() and end up locking up that device because to do anything else may scramble the disk further. But we don't panic() because that will basically wedge the system - and the user loses any chance at dumping the dmesg buffer for debugging or other attempts at an orderly shutdown (in particular, panic() won't sync the filesystems. So even though a BUG() often kills a thread while it holds an important lock, which often leads to the system eventually deadlocking one process at a time, it's still a net win if it doesn't panic but lets the user at least try to run sync. And even BUG_ON() is frowned upon if further progress in a degraded mode is possible (for instance, a networking error that totally locks up one TCP connection, but other connections are still working) - at that point, warn() is the correct thing to do. As in this case - it *is* a serious violation, but the kernel (a) can at least possibly keep going and (b) it's at least possible that the user can recover from it. There's a *very* good chance that if the kernel just does a warn(), the user will say "*facepalm* Stupid typo in the address", fix the typo, and re-try with the correct address. So that's the design philosophy of why it gives you a warning rather than a panic. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130301/88ae50b7/attachment.bin ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ARM_LINUX] ioremap() allowing to map system memory... 2013-03-01 17:29 ` Valdis.Kletnieks at vt.edu @ 2013-03-01 17:56 ` Arlie Stephens 0 siblings, 0 replies; 9+ messages in thread From: Arlie Stephens @ 2013-03-01 17:56 UTC (permalink / raw) To: kernelnewbies On Mar 01 2013, Valdis.Kletnieks at vt.edu wrote: > X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.4-dev > > On Fri, 01 Mar 2013 16:48:12 +0530, sandeep kumar said: > > > Don't you think it should throw panic()while calling the ioremap() itself. > > Because this sounds like a serious violation... > > As you noted, it does give you a warning. > > That's a kernel design philosophy - to reserve the panic() and BUG() > calls for cases where it is *known* that proceeding further is > unsafe or impossible. So the kernel does a panic() if it can't start > /sbin/init at system boot-up - because without that, further progress > is impossible. But once the system is up, we don't panic if PID 1 goes > away - because it's possible that the user has an open window, and can su > and at least do an orderly shutdown. [snippage] > So that's the design philosophy of why it gives you a warning rather than > a panic. Great explanation. Thank you. I figured it would be something vaguely like this, but I'm very new to the *linux* kernel, so I wasn't going to try to answer. -- Arlie (Arlie Stephens arlie at worldash.org) ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-03-04 9:48 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-03-01 11:18 [ARM_LINUX] ioremap() allowing to map system memory sandeep kumar 2013-03-01 11:28 ` Prabhu nath 2013-03-01 12:27 ` sandeep kumar 2013-03-02 11:22 ` Prabhu nath 2013-03-02 17:18 ` sandeep kumar 2013-03-04 8:02 ` buyitian 2013-03-04 9:48 ` sandeep kumar 2013-03-01 17:29 ` Valdis.Kletnieks at vt.edu 2013-03-01 17:56 ` Arlie Stephens
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).