user virtual address to physical address
Hi, I need to convert a user virtual address to its corresponding physical address. I know that if the virtual address is from kernel, we could use virt_to_phys. Is there a similar helper function to convert user virtual address.? Thanks, Fredrick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Hooking a system call.
On 03/26/2012 01:14 AM, V.Ravikumar wrote: > > > On Mon, Mar 26, 2012 at 1:18 PM, Mulyadi Santosa > mailto:mulyadi.sant...@gmail.com>> wrote: > > Hi... > > On Mon, Mar 26, 2012 at 11:45, V.Ravikumar > mailto:ravikumar.valla...@gmail.com>> > wrote: > > As part of auditing purpose I need to intercept/hook > open/read/write system > > calls. > > > > As I was lack of knowledge into kernel development.Could somebody > help me > > out here ? > > I'm working on RHEL-5 machine with Linux kernel version 2.6.18 > > Thanks & Regards, > > Ravi > > IMHO you better use SystemTap, which is based on Kprobes. It can be > used to hook into almost every part of kernel system, with very less > overhead. > > Ok I'll also look into System Tap. > > But in my sample module example code for intercepting system call. how > can I make system_call_table address to writable so that one can change > to customized system call. > > Thanks & Regards, > Ravi > You could use tracepoints, register_trace_sys_enter register_trace_sys_exit as used by ftrace in kernel/trace/trace_syscalls.c -Fredrick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Softlock OOPS dump
On 02/05/2012 11:13 PM, devendra rawat wrote: > > Hi All, > > I am having a PPC system running Windriver linux. System is restarting > because of watchdog. > System was restated because no scheduling took place for 15.7 seconds. I > want to figure out which function/ISR/routine > was the kernel executing when this softlockup happened and at what place > was the execution going. The NIP (next instruction pointer) reg. is not > giving the > symbol name as the "switch" module that created the problem was > dynamically loaded. > Can anybody help in figuring out the exact routine that may be behind > the lockup. > > I am getting the following OOPS. > > > > cpu0: jiffies: 1903983223, hrtime: 16746998586843980, 15756 ms between > scheduler_tick() calls > 31/12/1969 EST 19:00:00, BUG: soft lockup detected on CPU#0! > 31/12/1969 EST 19:00:00, NIP: C0041FAC LR: C0042320 SP: C71AFB10 REGS: > c71afa60 TRAP: 0901Tainted: P > 31/12/1969 EST 19:00:00, MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 > 31/12/1969 EST 19:00:00, TASK = cef2c880[1224] 'switch' THREAD: c71ae000 > 31/12/1969 EST 19:00:00, Last syscall: 54 > 31/12/1969 EST 19:00:00, > 31/12/1969 EST 19:00:00, GPR00: > 31/12/1969 EST 19:00:00, C017D5E4 > 31/12/1969 EST 19:00:00, C71AFB10 > 31/12/1969 EST 19:00:00, CEF2C880 > 31/12/1969 EST 19:00:00, 0020 > 31/12/1969 EST 19:00:00, C71AFC20 > 31/12/1969 EST 19:00:00, D04C7F80 > 31/12/1969 EST 19:00:00, C036A774 > 31/12/1969 EST 19:00:00, 001C > 31/12/1969 EST 19:00:00, > 31/12/1969 EST 19:00:00, GPR08: > 31/12/1969 EST 19:00:00, C036BF48 > 31/12/1969 EST 19:00:00, > 31/12/1969 EST 19:00:00, F10C > 31/12/1969 EST 19:00:00, > 31/12/1969 EST 19:00:00, 2410C042 > 31/12/1969 EST 19:00:00, > 31/12/1969 EST 19:00:00, NIP [c0041fac] > 31/12/1969 EST 19:00:00, handle_IRQ_event+0x254/0x4d4 > 31/12/1969 EST 19:00:00, LR [c0042320] > 31/12/1969 EST 19:00:00, __do_IRQ+0xf4/0x164 > 31/12/1969 EST 19:00:00, Call trace > 31/12/1969 EST 19:00:00, > 31/12/1969 EST 19:00:00, [c0042320] > 31/12/1969 EST 19:00:00, __do_IRQ+0xf4/0x16 > 31/12/1969 EST 19:00:00, > 31/12/1969 EST 19:00:00, [c0006c64] > 31/12/1969 EST 19:00:00, do_IRQ+0x54/0x10 > 31/12/1969 EST 19:00:00, > 31/12/1969 EST 19:00:00, [c0005214] > 31/12/1969 EST 19:00:00, ret_from_except+0x0/0x1 > 31/12/1969 EST 19:00:00, > 31/12/1969 EST 19:00:00, [e10cbc7c] > 31/12/1969 EST 19:00:00, bcm_bsa_request+0x189c/0x4140 [bcm5690 > 31/12/1969 EST 19:00:00, > 31/12/1969 EST 19:00:00, [e10d09a8] > 31/12/1969 EST 19:00:00, bcm_ioctl+0x144/0x480 [bcm5690 > 31/12/1969 EST 19:00:00, > 31/12/1969 EST 19:00:00, [c0087764] > 31/12/1969 EST 19:00:00, do_ioctl+0x68/0x9 > 31/12/1969 EST 19:00:00, > 31/12/1969 EST 19:00:00, [c0087850] > 31/12/1969 EST 19:00:00, vfs_ioctl+0xb8/0x40 > 31/12/1969 EST 19:00:00, > 31/12/1969 EST 19:00:00, [c0087e00] > 31/12/1969 EST 19:00:00, sys_ioctl+0x268/0x38 > 31/12/1969 EST 19:00:00, > 31/12/1969 EST 19:00:00, [c0004a1c] > 31/12/1969 EST 19:00:00, DoSyscall_no_dpa_entry+0x74/0x9 > > /*/ > > Thanks in advance. > Devendra. > > It could be getting stuck in the ioctl bcm_ioctl->bcm_bsa_request+0x189c -Fredrick > > > ___ > 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: Best way to debug an Intel Core i5 hang - likely graphics (possibly power) related
On 01/30/2012 08:52 PM, Graeme Russ wrote: > Hi Mulyadi, > > On Tue, Jan 31, 2012 at 3:25 PM, Mulyadi Santosa > wrote: >> Hi :) >> >> On Tue, Jan 31, 2012 at 10:00, Graeme Russ wrote: >>> I _think_ I've solved the problem - SDRAM Voltage >> >> You got my respect man, you're really stubborn :) >> >>> The SDRAM I am using has a rated operating voltage of 1.5V +/- 0.075. >>> It looked like the motherboard BIOS had decided to use the upper limit >>> of 1.575V when set to 'Auto'. I changed it to 'Manual' and set the >>> SDRAM voltage to 1.5V and it's been running stably for the longest >>> time it ever has. >> >> Thanks (again) for sharing. So this indeed has tight relationship with >> RAM "misbehaviour". How do you know it? Do you inspect every piece of >> your hardware? I am curious to know (maybe others too). > > The first symptom was that the screen would cycle through solid colour, so > naturally the video 'card' was the first to be blamed. Of course, the i5 > has the video built into the CPU, so the likelihood of a fault there is > probably minimal, so the graphics driver was next in line > > So I installed an nVidia 8600GT and ran the nouveau driver (now I did get > a glitch using this combo, but it wasn't a hang so I set that aside as a > driver bug as well... could be related) > > I then installed an nVidia G210 (it's a much smaller and quieter card). I > experienced one hang with this combination (right, now things are getting > interesting...) > > In the meantime, I had tried fiddling with the IGPU voltage offset - no > luck of course > > I removed my Linux hard drives and installed a spare hard drive and > proceeded to install Windows 7 (using the on-chip Intel graphics). The > machine hung once before the Window 7 drivers were installed (promising) > > I then installed the Windows 7 drivers and started downloading 3DMark 2006 > > ...Off to Australia Day Lunch with friends, back later... > > OK, so 3DMark downloaded OK and the machine was still running some 6 hours > later :( > > Before getting a chance to install 3DMark, I had some other things to > attend to... Glancing over bright flashing colours!!! Linux had been > exonerated :) > > So I took it back to the shop I bought it from (long argument about voiding > the warranty by taking of the cover blah blah blah). They ran a stress > test without failure. I suggested they run memtest which was met by 'Ah, > yeah, I should have thought of that first' (and _I_ voided the warranty!) > > So memtest failed, they put in another pair of memory modules and memtest > failed again. Now the plot thickens... They put the old memory back and > memtest passed! (what the!) then the put the new memory in and, you guessed > it, memtest passed! So the old memory goes back in and more stress testing > begins. > > It was run all day, no failure. So I went in and picked up the machine to > take back home on the assumption that the problem was the seating of the > memory modules - well I couldn't really fault that analysis (another > argument about voiding warranty, 'parts still in warranty, labour to run > the tests not', and 'Oh, it failed under Linux, must be software related, > not covered by warrantly' Me: 'It failed before I opened the case', > Them: 'doesn't matter, you opened the case') - Anyway, I got it back > without paying anything mumbling 'idiots' under my breath... > > so I put my Linux drives back in and run it over night. It survived and so > I thought the problem was solved but alas, it failed ten minutes after > waking it up in the morning... bugger! > > So RAM modules not the problem, that leaves CPU, Motherboard and PSU... > > So I switched out the PSU - Fail (really quickly this time... interesting) > > So that's when I decided to look at the SDRAM voltage - I looked up the > datasheet for the RAM and compared it to the BIOS setting... Hmm, right > at the upper limit of the spec'd DIMM voltage, so I set it to 1.5V > manually. > > Since then it has not skipped a beat (only been ~18 hours, but that's way > longer than previously) > > Now if it fails again, I'm just going to buy another motherboard. If that > works, I'm going to have a _very_ interesting time with the shop I > bought it from (after all, the parts are under warranty hardy, har har!) > >> NB: it could be a good lesson that system lock up might have >> absolutely nothing to do with kernel. > > Verily :) > > Regards, > > Graeme > Thank you Graeme for sharing this experience. Amazing persistence! I would not have gone this far. :) Sometimes you have to doubt even the nuts and bolts :) -Fredrick > ___ > 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: kmalloc before kmem_cache_init
On 01/29/2012 04:29 AM, Sukanto Ghosh wrote:
> So to use a MMIO based 8250 as "earlycon", either we need to have some
> sort of fixmap
> (as in case of x86) or otherwise we need to have a ioremap_nocache()
> version that works
> even before kmem_cache_init() is called.
> I am not sure how many architectures will have such form of ioremap
> other than maybe
> nommu variants.
>
Some architectures check for mem_init_done.
Probably every architecture must provide an "early_ioremap" function to
be used in early _code_.
> Greg,
>
> Has anyone used the ioremap path so far ? If not, then why have it
> there as usual ioremap
> can be used only after mm_init(), but this driver whenever used will
> get called earlier than that ?
>
> Regards,
> Sukanto
>
>
>
> On Sun, Jan 29, 2012 at 3:03 PM, Dave Hylands wrote:
>> Hi Sukanto,
>>
>> On Sat, Jan 28, 2012 at 11:25 PM, Sukanto Ghosh
>> wrote:
>>> Hi Dave,
>>>
>>> If you look into start_kernel() the call to parse_early_param()
>>> precedes mm_init().
>>> parse_early_param() eventually calls do_early_param().
>>> do_early_param() parses for "earlycon" in kernel commandline and then calls
>>> the
>>> setup_function associated with earlycon.
>>>
>>> I have in my commandline: earlycon=uart8250,mmio32,0x1000,9600
>>>
>>> Call flow starting from drivers/tty/serial/8250_early.c will lead to kmalloc
>>>
>>> early_param("early_con", setup_early_serial8250_console)
>>>setup_early_serial8250_console()
>>>early_serial8250_setup()
>>>parse_options()
>>>ioremap_nocache()
>>> ... arch-specific-ioremap
>>> -- some form of arch specific __ioremap_caller
>>> --- get_vm_area_caller()
>>> __get_vm_area_node
>>>kzalloc_node
>>>kmalloc_node
>>> kmalloc
>>
>> It looks like CONFIG_FIX_EARLYCON_MEM defaults to y (on x86 anyways),
>> so this would cause the path that doesn't call ioremam_nocache to be
>> taken.
>>
>> I'm guessing that if you specify earycon, then you also need to ensure
>> that CONFIG_FIX_EARLYCON is set.
>>
>> You didn't mention which architecture you were using. ARM has an
>> early_printk which is sort of like an early console.
>>
>> --
>> Dave Hylands
>> Shuswap, BC, Canada
>> http://www.davehylands.com
>
>
>
-Fredrick
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: RO/NX Protections and Modules
On 01/23/2012 02:04 PM, Dannie Stanley wrote: > Regarding the source code for kernel version 2.6.38. In > kernel/module.c the function defined as: > > SYSCALL_DEFINE3(init_module...) > > Calls set_section_ro_nx for core and init. My first question is this: > >Q1: Why doesn't the exit text/data get the RO/NX page protection? > I guess this is a trade off. > In the set_section_ro_nx function the RO comment reads: "Do not > protect last partial page" and the NX comment reads: "Do not protect > first partial page." In the presence of mixed pages this makes sense. > However, change_page_attr_set_clr seems to check for page alignment. > So my second question is this: > >Q2: Does the RO/NX only apply to page aligned sections? > Most MMUs/TLBs deal only with page sized memory. They handle access attributes in page sized memory. > Thank you, > Dannie > -Fredrick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: elf core dump - reading NT_PRPSINFO
Sorry for not clearly specifying. Yes "core" is a core dump file. I see that fs/binfmt_elf.c does put information about the process that cored in a ".note" elf section as NT_PRPSINFO. Is there a standard tool to dump this information? Tried googling, could nt find anything :(. -Fredrick On 01/21/2012 09:45 AM, Mulyadi Santosa wrote: > Hi :) > > On Fri, Jan 20, 2012 at 13:57, Fredrick wrote: >> Hi, >> >> $ readelf -n core > > is that "core" a core dump? > >> Does anyone know how to read this NT_PRPSINFO ? >> Is hexdump the only way to decode this? >> Are there any tools to dump this data ? > > if it is indeed core dump, I think simply pass it to gdb, e.g: > gdb > and start playing with it e.g dumping stack trace. > > NB: IMHO NT_PRPSINFO is just a section that describes the VMAs of the > crashed program. Quite likely an ELF documentation will mention about > it. Try googling... ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
elf core dump - reading NT_PRPSINFO
Hi, $ readelf -n core Notes at offset 0x0274 with length 0x04c0: OwnerData size Description CORE 0x0090 NT_PRSTATUS (prstatus structure) CORE 0x007c NT_PRPSINFO (prpsinfo structure) CORE 0x00a0 NT_AUXV (auxiliary vector) CORE 0x006c NT_FPREGSET (floating point registers) LINUX0x0200 NT_PRXFPREG (user_xfpregs structure) LINUX0x0030 Unknown note type: (0x0200) Does anyone know how to read this NT_PRPSINFO ? Is hexdump the only way to decode this? Are there any tools to dump this data ? Thanks, Fredrick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Does Linux process exist information leakage?
Yes you are right. Each architecture implements clear_page() differently. Some may just use memset. Some may use architecture specific instructions to perform the zero-ing faster. I guess x86's fast_clear_page does that. -Fredrick On 01/18/2012 05:27 PM, 夏业添 wrote: > Thanks！ > > It seems that the function do_page_fault() will finally call > fast_clear_page() > <http://lxr.oss.org.cn/plain/source/arch/x86/lib/mmx_32.c#L125> or > slow_zero_page() > <http://lxr.oss.org.cn/plain/source/arch/x86/lib/mmx_32.c#L336> to zero > a new physical page for a process. So calling malloc() cannot get a page > used by another process which is dead already. > > The assemble language is difficult to me, so please tell me if I am wrong. > > 2012/1/18 Fredrick mailto:fjohn...@zoho.com>> > > When you malloc a memory or mmap a MAP_ANON memory, it is virtually > allocated. When you read or write to it, the process takes a page > fault. The page fault handler zeroes those memory and hands it to > the process. So I think there is no leak. > > -Fredrick > > > On 01/11/2012 04:53 AM, 夏业添 wrote: > > Hi, > My tutor asked me to test whether one process leaves information in > memory after it is dead. I tried to search some article about > such thing > on the Internet but there seems to be no one discuss about it. > And after > that, I tried to write some program in the User Mode to test it, > using > fork() to create lots of processes and filling char 'a' into a > 102400 > bytes char array in each process. Then I used malloc() to get some > memory to seek char 'a' in a new one process or many new > processes, but > failed. All memory I malloced was full of zero. > As the man page of malloc said:"The memory is not initialized", I > believe that the memory which was got by malloc() could be used > by other > process, and therefor information leakage exists. But how can I > test it? > Or where can I get related information? > Thanks! > > > _ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.__org > <mailto:Kernelnewbies@kernelnewbies.org> > http://lists.kernelnewbies.__org/mailman/listinfo/__kernelnewbies > <http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies> > > > > > > > ___ > 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: Does Linux process exist information leakage?
When you malloc a memory or mmap a MAP_ANON memory, it is virtually allocated. When you read or write to it, the process takes a page fault. The page fault handler zeroes those memory and hands it to the process. So I think there is no leak. -Fredrick On 01/11/2012 04:53 AM, 夏业添 wrote: > Hi, > My tutor asked me to test whether one process leaves information in > memory after it is dead. I tried to search some article about such thing > on the Internet but there seems to be no one discuss about it. And after > that, I tried to write some program in the User Mode to test it, using > fork() to create lots of processes and filling char 'a' into a 102400 > bytes char array in each process. Then I used malloc() to get some > memory to seek char 'a' in a new one process or many new processes, but > failed. All memory I malloced was full of zero. > As the man page of malloc said:"The memory is not initialized", I > believe that the memory which was got by malloc() could be used by other > process, and therefor information leakage exists. But how can I test it? > Or where can I get related information? > Thanks! > > > ___ > 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: DEFINE Macro
Nice! Thanks for the explanation Josh.
-Fredrick
On 01/06/2012 06:09 AM, Josh Cartwright wrote:
> On Thu, Jan 05, 2012 at 07:32:48PM -0800, Fredrick wrote:
>> Hi,
>>
>> I am not able to understand the DEFINE macro used in
>> arch/powerpc/kernel/asm-offsets.c
>>
>> I suppose the DEFINE is present in
>> include/linux/kbuild.h
>> where it says
>> #define DEFINE(sym, val) \
>> asm volatile("\n->" #sym " %0 " #val : : "i" (val))
>>
>> What does the above mean?
>
> This is just a trick to get the offsets of members into a generated header
> file
> asm-offsets.h. The inline assembly does NOT contain valid instructions,
> and in fact, asm-offsets.c is never actually assembled into a program.
> Instead, the build process generates the assembly language output
> asm-offsets.s, and processes it with a sed script to generate
> asm-offsets.h.
>
> For example (assume offsetof(struct thread_struct, regs) is 30):
>
> DEFINE(PT_REGS, offsetof(struct thread_struct, regs));
>
> will generate within the assembly language output:
>
> ->PT_REGS $30 offsetof(struct thread_struct, regs)
>
> A sed script, executed on the assembly language output will generate a
> line in include/generated/asm-offsets.h:
>
> #define PT_REGS 30 /* offsetof(struct thread_struct, regs) */
>
> Thats about it. You can find the exact sed script used, and the make
> magic involved in Kbuild (see cmd_offsets).
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
DEFINE Macro
Hi,
I am not able to understand the DEFINE macro used in
arch/powerpc/kernel/asm-offsets.c
I suppose the DEFINE is present in
include/linux/kbuild.h
where it says
#define DEFINE(sym, val) \
asm volatile("\n->" #sym " %0 " #val : : "i" (val))
What does the above mean?
-Fredrick
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
why no vsyscall support on x86 or i386 ?
Hi, Why there is no vsyscall support on i386? I see it only on x86_64. In x86_64 it supports gettimeofday, etc. In i386, it only uses to support the sysenter optimization. Why there is no support for gettimeofday in i386 as a vsyscall? -Fredrick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: cuboot/cuImage? treeboot/treeImage?
Thanks Peter. I also found this link to be helpful. http://www.mjmwired.net/kernel/Documentation/powerpc/bootwrapper.txt -Fredrick On 12/10/2011 04:46 PM, Peter Teoh wrote: > just google for it, i found: > > http://old.nabble.com/treeImage-vs-cuImage-td17020308.html > > On Wed, Dec 7, 2011 at 9:58 AM, Fredrick <mailto:fjohn...@zoho.com>> wrote: > > Hi, > > I was looking at the different powerpc bootable images. > What are these 'cuImage' and 'treeImage'? > Could someone explain when these images are used? > > Thanks, > Fredrick > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org <mailto:Kernelnewbies@kernelnewbies.org> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > > -- > Regards, > Peter Teoh > > > ___ > 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: Measuring time in range of microseconds.
I think if the specific ARM platform you are working supports a oneshot clock_device, you would get the high res timer support. You can check for clock_devices defined in your platform having feature - CLOCK_EVT_FEAT_ONESHOT. -Fredrick On 12/06/2011 03:17 AM, Peter Senna Tschudin wrote: > Hi Sathishkumar, > > rdtsc is x86 specific... Sorry. > > But there are other options. > > Compares rdtsc with hpet: > http://aufather.wordpress.com/2010/09/08/high-performance-time-measuremen-in-linux/ > > Other reference about timers: > http://the-b.org/Linux_timers > > I'm not sure if HPET works on ARM. > > []'s > > Peter > > On Tue, Dec 6, 2011 at 9:06 AM, Sathishkumar Duraisamy > wrote: >> Hi Peter, >> >> Thanks for rdtsc. But I looking to measure time inside Linux Kernel >> Module in ARM architecture. >> >> -- >> Regards, >> Sathishkumar D >> http://flowersopenlab.weebly.com/ > > > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
cuboot/cuImage? treeboot/treeImage?
Hi, I was looking at the different powerpc bootable images. What are these 'cuImage' and 'treeImage'? Could someone explain when these images are used? Thanks, Fredrick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
