January 2011 - kernelnewbies@kernelnewbies.org

Creating the same random numbers
by Andreas Leppert Jan. 29, 2011

Jan. 29, 2011

Hi, for my evaluation of different kernel modules which rely on randomness I need the same set of random numbers for each of them. Is there any chance that I can get a random number which depends on a kind of seed value? So if I start with the same seed value, the same random numbers should be generated. Is there any way in the kernel to achieve this? Thanks for your hints, Andreas Leppert

3 3

scrubbing in linux volume manager
by sanoj Jan. 29, 2011

Jan. 29, 2011

Hello, I did not find any support for scrubbing in lvm, I would like to know id this is right and the reason if so I see 2 reasons => performance overhead => demerits of scrubbing when silent data corruption and disk failure simultaneously ocurrs. thanks, sanoj

4 5

Re: page size change on MIPS
by naveen yadav Jan. 28, 2011

Jan. 28, 2011

Hi all I try changing the kernel_execve() function as suggested, but it fails, I am using code sourcery toolchain 4.4.1 but it still fails. I am using 2.6.30.9 kernel and this function is part of it. Kind regards On Thu, Jan 27, 2011 at 11:14 PM, David Daney <ddaney(a)caviumnetworks.com> wrote: > On 01/27/2011 07:18 AM, adnan iqbal wrote: >> >> Please try this. One line of code is added ( move %1, $7). >> >> >> int kernel_execve(const char *filename, char *const argv[], char *const >> envp[]) >> { >> register unsigned long __a0 asm("$4") = (unsigned long) filename; >> register unsigned long __a1 asm("$5") = (unsigned long) argv; >> register unsigned long __a2 asm("$6") = (unsigned long) envp; >> register unsigned long __a3 asm("$7"); >> unsigned long __v0; >> __asm__ volatile (" \n" >> " .set noreorder \n" >> " li $2, %5 # __NR_execve \n" >> " syscall \n" >> " move %0, $2 \n" >> " move %1, $7 \n" >> " .set reorder \n" >> : "=&r" (__v0), "=r" (__a3) >> : "r" (__a0), "r" (__a1), "r" (__a2), "i" (__NR_execve) >> : "$2", "$8", "$9", "$10", "$11", "$12", "$13", "$14", "$15", >> "$24", >> "memory"); >> >> >> if (__a3 == 0) >> return __v0; >> return -__v0; >> } >> > > I don't know where you got that code. But really you should do what glibc > does. glibc gets it correct. > > At a minimum you are missing "hi" and "lo" clobbers. > > If the code works with 16K pages, and not 64K pages, then this snippet is > not the problem. Likely your problem is the layout of the PHDRs in the > executable is not compatible with the page size. > > David Daney > > >> >> On Thu, Jan 27, 2011 at 7:55 PM, naveen yadav<yad.naveen(a)gmail.com> >> wrote: >> >>> Hi David, >>> >>> thanks for your response. >>> >>> I check and found that kernel is booting with 16KB page size with >>> ramdisk booting. But when I change to 64KB it give me >>> >>> : applet not found >>> Kernel panic - not syncing: Attempted to kill init! >>> so I check and found that it is not able to execute well the system >>> call in kernel_execve function. >>> I am using codesourcercy toolchain(4.3.1). So is there a way to debug >>> this problem or how to debug below function. >>> >>> int kernel_execve(const char *filename, char *const argv[], char *const >>> envp[]) >>> { >>> register unsigned long __a0 asm("$4") = (unsigned long) filename; >>> register unsigned long __a1 asm("$5") = (unsigned long) argv; >>> register unsigned long __a2 asm("$6") = (unsigned long) envp; >>> register unsigned long __a3 asm("$7"); >>> unsigned long __v0; >>> __asm__ volatile (" \n" >>> " .set noreorder \n" >>> " li $2, %5 # __NR_execve \n" >>> " syscall \n" >>> " move %0, $2 \n" >>> " .set reorder \n" >>> : "=&r" (__v0), "=r" (__a3) >>> : "r" (__a0), "r" (__a1), "r" (__a2), "i" (__NR_execve) >>> : "$2", "$8", "$9", "$10", "$11", "$12", "$13", "$14", "$15", >>> "$24", >>> "memory"); >>> >>> >>> if (__a3 == 0) >>> return __v0; >>> return -__v0; >>> } >>> >>> >>> On Tue, Jan 25, 2011 at 12:26 AM, David Daney<ddaney(a)caviumnetworks.com> >>> wrote: >>>> >>>> On 01/24/2011 07:02 AM, naveen yadav wrote: >>>>> >>>>> Hi All, >>>>> >>>>> >>>>> we are using mips32r2 so I want to know which all pages size it can >>>>> support? >>>>> When I modify arch/mips/Kconfig. it boot sucessfully on 16KB page >>>>> size. but hang/not boot crash when change page size to 8KB,32KB and 64 >>>>> KB. >>>> >>>> I don't think 8KB and 32KB work on most mips32r2 processors. You would >>> >>> have >>>> >>>> to check the processor manual to be sure. >>>> >>>> >>>>> >>>>> We are using 2.6.30 kernel. >>>>> >>>>> At Page Size 8KB and 32KB it hang in unpack_to_rootfs() function of >>>>> init/initramfs.c >>>>> >>>>> 64KB it hangs when execute init Kernel panic - not syncing: Attempted >>>>> to kill init! >>>> >>>> I regularly run 4K, 16K, and 64K page sizes with a Debian rootfs. If >>>> you >>>> run with a broken uClibc toolchain that doesn't support larger pages, it >>>> will of course fail. In this case the problem is with your toolchain, >>> >>> not >>>> >>>> the kernel. >>>> >>>> David Daney >>>> >>>> >>>>> >>>>> config PAGE_SIZE_4KB >>>>> bool "4kB" >>>>> help >>>>> This option select the standard 4kB Linux page size. On some >>>>> R3000-family processors this is the only available page size. >>>>> Using >>>>> 4kB page size will minimize memory consumption and is >>>>> therefore >>>>> recommended for low memory systems. >>>>> >>>>> config PAGE_SIZE_8KB >>>>> bool "8kB" >>>>> depends on (EXPERIMENTAL&& CPU_R8000) || CPU_CAVIUM_OCTEON >>>>> help >>>>> Using 8kB page size will result in higher performance kernel >>> >>> at >>>>> >>>>> the price of higher memory consumption. This option is >>>>> available >>>>> only on R8000 and cnMIPS processors. Note that you will need >>> >>> a >>>>> >>>>> suitable Linux distribution to support this. >>>>> >>>>> config PAGE_SIZE_16KB >>>>> bool "16kB" >>>>> depends on !CPU_R3000&& !CPU_TX39XX >>>>> help >>>>> Using 16kB page size will result in higher performance kernel >>> >>> at >>>>> >>>>> the price of higher memory consumption. This option is >>>>> available on >>>>> all non-R3000 family processors. Note that you will need a >>>>> suitable >>>>> Linux distribution to support this. >>>>> >>>>> config PAGE_SIZE_32KB >>>>> bool "32kB" >>>>> help >>>>> Using 32kB page size will result in higher performance kernel >>> >>> at >>>>> >>>>> the price of higher memory consumption. This option is >>>>> available >>>>> only on cnMIPS cores. Note that you will need a suitable >>> >>> Linux >>>>> >>>>> distribution to support this. >>>>> >>>>> config PAGE_SIZE_64KB >>>>> bool "64kB" >>>>> depends on EXPERIMENTAL&& !CPU_R3000&& !CPU_TX39XX >>>>> help >>>>> Using 64kB page size will result in higher performance kernel >>> >>> at >>>>> >>>>> the price of higher memory consumption. This option is >>>>> available on >>>>> all non-R3000 family processor. Not that at the time of this >>>>> writing this option is still high experimental. >>>>> >>>>> >>>> >>>> >>> >>> >> > >

2 1

i see the intel i915 black screen issue is back
by Robert P. J. Day Jan. 28, 2011

Jan. 28, 2011

just built a new kernel for ubuntu 10.10 (2.6.38-rc2) and, depressingly, this kernel once again boots to a black screen given the intel i915 onboard video. this is getting frustrating. rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

5 9

Test message - please ignore.
by Tayade, Nilesh Jan. 28, 2011

Jan. 28, 2011

My emails are not reaching to kernelnewbies list. This is a test message just to check. -- Thanks, Nilesh

1 0

"inconsistent lock state"
by Arvid Brodin Jan. 27, 2011

Jan. 27, 2011

Hello, I'm using spinlocks (spin_lock_irqsave() / spin_unlock_irqrestore()) to protect shared resources between softirq, hardirq and non-irq kernel contexts. When I configure PROVE_LOCKING I get ================================= [ INFO: inconsistent lock state ] 2.6.27.54 #148 --------------------------------- inconsistent {softirq-on-W} -> {in-softirq-W} usage. khubd/85 [HC0[0]:SC1[1]:HE0:SE0] takes: (&priv->lock){-+..}, at: [<90152430>] schedule_ptds+0x54/0x564 {softirq-on-W} state was registered at: [<9003856e>] trace_hardirqs_on_caller+0x92/0xc4 [<900385a8>] trace_hardirqs_on+0x8/0xc [<90058fc2>] __slab_alloc+0xee/0x3e4 [<90059f9c>] kmem_cache_alloc+0x30/0x70 etc... I don't understand why. Assuming that "{softirq-on-W} -> {in-softirq-W}" means that the problem is that the lock was taken in "softirq on" (irqs enabled) state, and at some later time in softirq context, then what is the problem? spin_lock_irqsave() disables irqs, right? So after the lock is taken in non-irq context, softirq cannot interrupt? There are code paths like this: { spin_lock_irqsave(...); ... spin_unlock() ... spin_lock() ... spin_unlock_irqrestore(...); } in both non-irq and softirq contexts. Could this be a problem? If I understand correctly, spin_lock() and spin_unlock() does not touch irq settings, so the usage above should be fine, right? Thanks, Arvid Brodin Enea Services Stockholm AB

1 0

Re: page size change on MIPS
by David Daney Jan. 27, 2011

Jan. 27, 2011

On 01/27/2011 07:18 AM, adnan iqbal wrote: > Please try this. One line of code is added ( move %1, $7). > > > int kernel_execve(const char *filename, char *const argv[], char *const > envp[]) > { > register unsigned long __a0 asm("$4") = (unsigned long) filename; > register unsigned long __a1 asm("$5") = (unsigned long) argv; > register unsigned long __a2 asm("$6") = (unsigned long) envp; > register unsigned long __a3 asm("$7"); > unsigned long __v0; > __asm__ volatile (" \n" > " .set noreorder \n" > " li $2, %5 # __NR_execve \n" > " syscall \n" > " move %0, $2 \n" > " move %1, $7 \n" > " .set reorder \n" > : "=&r" (__v0), "=r" (__a3) > : "r" (__a0), "r" (__a1), "r" (__a2), "i" (__NR_execve) > : "$2", "$8", "$9", "$10", "$11", "$12", "$13", "$14", "$15", "$24", > "memory"); > > > if (__a3 == 0) > return __v0; > return -__v0; > } > I don't know where you got that code. But really you should do what glibc does. glibc gets it correct. At a minimum you are missing "hi" and "lo" clobbers. If the code works with 16K pages, and not 64K pages, then this snippet is not the problem. Likely your problem is the layout of the PHDRs in the executable is not compatible with the page size. David Daney > > On Thu, Jan 27, 2011 at 7:55 PM, naveen yadav<yad.naveen(a)gmail.com> wrote: > >> Hi David, >> >> thanks for your response. >> >> I check and found that kernel is booting with 16KB page size with >> ramdisk booting. But when I change to 64KB it give me >> >> : applet not found >> Kernel panic - not syncing: Attempted to kill init! >> so I check and found that it is not able to execute well the system >> call in kernel_execve function. >> I am using codesourcercy toolchain(4.3.1). So is there a way to debug >> this problem or how to debug below function. >> >> int kernel_execve(const char *filename, char *const argv[], char *const >> envp[]) >> { >> register unsigned long __a0 asm("$4") = (unsigned long) filename; >> register unsigned long __a1 asm("$5") = (unsigned long) argv; >> register unsigned long __a2 asm("$6") = (unsigned long) envp; >> register unsigned long __a3 asm("$7"); >> unsigned long __v0; >> __asm__ volatile (" \n" >> " .set noreorder \n" >> " li $2, %5 # __NR_execve \n" >> " syscall \n" >> " move %0, $2 \n" >> " .set reorder \n" >> : "=&r" (__v0), "=r" (__a3) >> : "r" (__a0), "r" (__a1), "r" (__a2), "i" (__NR_execve) >> : "$2", "$8", "$9", "$10", "$11", "$12", "$13", "$14", "$15", "$24", >> "memory"); >> >> >> if (__a3 == 0) >> return __v0; >> return -__v0; >> } >> >> >> On Tue, Jan 25, 2011 at 12:26 AM, David Daney<ddaney(a)caviumnetworks.com> >> wrote: >>> On 01/24/2011 07:02 AM, naveen yadav wrote: >>>> >>>> Hi All, >>>> >>>> >>>> we are using mips32r2 so I want to know which all pages size it can >>>> support? >>>> When I modify arch/mips/Kconfig. it boot sucessfully on 16KB page >>>> size. but hang/not boot crash when change page size to 8KB,32KB and 64 >>>> KB. >>> >>> I don't think 8KB and 32KB work on most mips32r2 processors. You would >> have >>> to check the processor manual to be sure. >>> >>> >>>> >>>> We are using 2.6.30 kernel. >>>> >>>> At Page Size 8KB and 32KB it hang in unpack_to_rootfs() function of >>>> init/initramfs.c >>>> >>>> 64KB it hangs when execute init Kernel panic - not syncing: Attempted >>>> to kill init! >>> >>> I regularly run 4K, 16K, and 64K page sizes with a Debian rootfs. If you >>> run with a broken uClibc toolchain that doesn't support larger pages, it >>> will of course fail. In this case the problem is with your toolchain, >> not >>> the kernel. >>> >>> David Daney >>> >>> >>>> >>>> config PAGE_SIZE_4KB >>>> bool "4kB" >>>> help >>>> This option select the standard 4kB Linux page size. On some >>>> R3000-family processors this is the only available page size. >>>> Using >>>> 4kB page size will minimize memory consumption and is therefore >>>> recommended for low memory systems. >>>> >>>> config PAGE_SIZE_8KB >>>> bool "8kB" >>>> depends on (EXPERIMENTAL&& CPU_R8000) || CPU_CAVIUM_OCTEON >>>> help >>>> Using 8kB page size will result in higher performance kernel >> at >>>> the price of higher memory consumption. This option is >>>> available >>>> only on R8000 and cnMIPS processors. Note that you will need >> a >>>> suitable Linux distribution to support this. >>>> >>>> config PAGE_SIZE_16KB >>>> bool "16kB" >>>> depends on !CPU_R3000&& !CPU_TX39XX >>>> help >>>> Using 16kB page size will result in higher performance kernel >> at >>>> the price of higher memory consumption. This option is >>>> available on >>>> all non-R3000 family processors. Note that you will need a >>>> suitable >>>> Linux distribution to support this. >>>> >>>> config PAGE_SIZE_32KB >>>> bool "32kB" >>>> help >>>> Using 32kB page size will result in higher performance kernel >> at >>>> the price of higher memory consumption. This option is >>>> available >>>> only on cnMIPS cores. Note that you will need a suitable >> Linux >>>> distribution to support this. >>>> >>>> config PAGE_SIZE_64KB >>>> bool "64kB" >>>> depends on EXPERIMENTAL&& !CPU_R3000&& !CPU_TX39XX >>>> help >>>> Using 64kB page size will result in higher performance kernel >> at >>>> the price of higher memory consumption. This option is >>>> available on >>>> all non-R3000 family processor. Not that at the time of this >>>> writing this option is still high experimental. >>>> >>>> >>> >>> >> >> >

1 0

Re: page size change on MIPS
by naveen yadav Jan. 27, 2011

Jan. 27, 2011

Hi David, thanks for your response. I check and found that kernel is booting with 16KB page size with ramdisk booting. But when I change to 64KB it give me : applet not found Kernel panic - not syncing: Attempted to kill init! so I check and found that it is not able to execute well the system call in kernel_execve function. I am using codesourcercy toolchain(4.3.1). So is there a way to debug this problem or how to debug below function. int kernel_execve(const char *filename, char *const argv[], char *const envp[]) { register unsigned long __a0 asm("$4") = (unsigned long) filename; register unsigned long __a1 asm("$5") = (unsigned long) argv; register unsigned long __a2 asm("$6") = (unsigned long) envp; register unsigned long __a3 asm("$7"); unsigned long __v0; __asm__ volatile (" \n" " .set noreorder \n" " li $2, %5 # __NR_execve \n" " syscall \n" " move %0, $2 \n" " .set reorder \n" : "=&r" (__v0), "=r" (__a3) : "r" (__a0), "r" (__a1), "r" (__a2), "i" (__NR_execve) : "$2", "$8", "$9", "$10", "$11", "$12", "$13", "$14", "$15", "$24", "memory"); if (__a3 == 0) return __v0; return -__v0; } On Tue, Jan 25, 2011 at 12:26 AM, David Daney <ddaney(a)caviumnetworks.com> wrote: > On 01/24/2011 07:02 AM, naveen yadav wrote: >> >> Hi All, >> >> >> we are using mips32r2 so I want to know which all pages size it can >> support? >> When I modify arch/mips/Kconfig. it boot sucessfully on 16KB page >> size. but hang/not boot crash when change page size to 8KB,32KB and 64 >> KB. > > I don't think 8KB and 32KB work on most mips32r2 processors. You would have > to check the processor manual to be sure. > > >> >> We are using 2.6.30 kernel. >> >> At Page Size 8KB and 32KB it hang in unpack_to_rootfs() function of >> init/initramfs.c >> >> 64KB it hangs when execute init Kernel panic - not syncing: Attempted >> to kill init! > > I regularly run 4K, 16K, and 64K page sizes with a Debian rootfs. If you > run with a broken uClibc toolchain that doesn't support larger pages, it > will of course fail. In this case the problem is with your toolchain, not > the kernel. > > David Daney > > >> >> config PAGE_SIZE_4KB >> bool "4kB" >> help >> This option select the standard 4kB Linux page size. On some >> R3000-family processors this is the only available page size. >> Using >> 4kB page size will minimize memory consumption and is therefore >> recommended for low memory systems. >> >> config PAGE_SIZE_8KB >> bool "8kB" >> depends on (EXPERIMENTAL&& CPU_R8000) || CPU_CAVIUM_OCTEON >> help >> Using 8kB page size will result in higher performance kernel at >> the price of higher memory consumption. This option is >> available >> only on R8000 and cnMIPS processors. Note that you will need a >> suitable Linux distribution to support this. >> >> config PAGE_SIZE_16KB >> bool "16kB" >> depends on !CPU_R3000&& !CPU_TX39XX >> help >> Using 16kB page size will result in higher performance kernel at >> the price of higher memory consumption. This option is >> available on >> all non-R3000 family processors. Note that you will need a >> suitable >> Linux distribution to support this. >> >> config PAGE_SIZE_32KB >> bool "32kB" >> help >> Using 32kB page size will result in higher performance kernel at >> the price of higher memory consumption. This option is >> available >> only on cnMIPS cores. Note that you will need a suitable Linux >> distribution to support this. >> >> config PAGE_SIZE_64KB >> bool "64kB" >> depends on EXPERIMENTAL&& !CPU_R3000&& !CPU_TX39XX >> help >> Using 64kB page size will result in higher performance kernel at >> the price of higher memory consumption. This option is >> available on >> all non-R3000 family processor. Not that at the time of this >> writing this option is still high experimental. >> >> > >

1 0

Doubt regarding read/write testing
by Gaurav Mahajan Jan. 27, 2011

Jan. 27, 2011

Hi, I've created a device mapper target and I wanna test its read and write mechanisms. I created a device using this target and tried to write a filesystem on to the device. My target is creating roughly two outgoing bios per incoming bio. Which is maybe why I'm not able to get a proper log after running the mke2fs command as while writing the filesystem, there are massive amounts of writes performed on the device. So, I tried to use the cat command to directly write to the device file. The write is being performed for sure because I'm able to view the data written to the underlying device. But there is no output when I try to read the device file contents using cat. Is there any other way to test the read/write workflows of a dm target that can give out a proper log ? Regards, Gaurav

1 0

Doubt regarding
by Gaurav Mahajan Jan. 27, 2011

Jan. 27, 2011

Hi, I've created a device mapper target and I wanna test its read and write mechanisms. I created a device using this target and tried to write a filesystem on to the device. My target is creating roughly two outgoing bios per incoming bio. Which is maybe why I'm not able to get a proper log after running the mke2fs command as while writing the filesystem, there are massive amounts of writes performed on the device. So, I tried to use the cat command to directly write to the device file. The write is being performed for sure because I'm able to view the data written to the underlying device. But there is no output when I try to read the device file contents using cat. Is there any other way to test the read/write workflows of a dm target that can give out a proper log ? Regards, Gaurav

1 0