Re: Mounting block device fails.
Thanks Manish,
The issue was with filesystem creation. It was not getting created
properly. I used dumpe2fs command to verify the file system. Actually
Superblock was written correctly but, few other fields like free block
and free inode list etc were incorrect
It seems to be working properly now
# dumpe2fs /dev/ftl
...
...
Group 0: (Blocks 0-65527)
Primary superblock at 0, Group descriptors at 1-1
Reserved GDT blocks at 2-8
Block bitmap at 9 (+9), Inode bitmap at 10 (+10)
Inode table at 11-1034 (+11)
64489 free blocks, 32757 free inodes, 2 directories
Free blocks: 1039-65527
Free inodes: 12-32768
Group 1: (Blocks 65528-131055)
Backup superblock at 65528, Group descriptors at 65529-65529
Reserved GDT blocks at 65530-65536
Block bitmap at 65537 (+9), Inode bitmap at 65538 (+10)
Inode table at 65539-66562 (+11)
64493 free blocks, 32768 free inodes, 0 directories
Free blocks: 66563-131055
Free inodes: 32769-65536
# mount
...
...
/dev/ftl on /mntpt type ext2 (rw,relatime,errors=continue)
The other problem which I am facing is with the blocksize.
mkfs allows ext2 file system be created with blocksize=8192,
overriding the default 4096. But, when I try to mount the file system
it fails
# mkfs -t ext2 -b 8192 /dev/ftl
Warning: blocksize 8192 not usable on most systems.
mke2fs 1.41.4 (27-Jan-2009)
mkfs.ext2: 8192-byte blocks too big for system (max 4096)
Proceed anyway? (y,n) y
Warning: 8192-byte blocks too big for system (max 4096), forced to continue
warning: 16 blocks unused.
Filesystem label=
OS type: Linux
Block size=8192 (log=3)
Fragment size=8192 (log=3)
65536 inodes, 131056 blocks
# mount -t ext2 /dev/ftl /mntpt
[54658.092031] EXT2-fs: blocksize too small for device.
mount: mounting /dev/ftl on /mntpt failed: Invalid argument
I tried specifying blocksize with the mount command, but it also fails
# mount -t ext2 /dev/ftl /mntpt -o blocksize=8192
mount: mounting /dev/ftl on /mntpt failed: Invalid argument
The above command fails in parsing the options passed to the command
The section "Mount options for ext2" of mount manpage does not mention
blocksize option.
Is there anyway I can create ext2 filesystem with blocksize 8192?
Thanks and Regards,
Prasad
On Thu, Oct 8, 2009 at 6:41 PM, Manish Katiyar wrote:
> On Thu, Oct 8, 2009 at 12:38 PM, Prasad Joshi
> wrote:
>> Hi,
>>
>> I am working on translation layer for flash. For the purpose testing I am
>> using a disk file to simulate the flash behavior. So every read and write on
>> the block device finally goes to a disk file, something similar to loop
>> device, but in addition maintaining the flash property.
>>
>> I am able to create the file system on the device (/dev/ftl) but when I try
>> to mount the device it fails with error "Invalid Argument".
>
> From the code I can see -EINVAL can be returned at lot of places. You
> need to see dmesg to see the message which can help tracing.
>
>>
>> I thought it is failing to read the super block of the file systems, but it
>> seems like it did not fail in superblock read
>>
>> # strace -o out mount -t ext2 /dev/ftl /mntpt/
>> [ 175.192033] Opening the device.
>> [ 175.193599] IftlIoRead: offset=0x400 Length=0x400
>> [ 175.193875] OffsetWithinPage: 400
>> [ 175.195104] Read pos=1002535424, length=8192
>> [ 175.195474] 0001 0004 eea5 0003 fff5
>> 0002 0002 8000 8000 2000 8a9e 4acd
>> 0020 ef53 0001 0001 8a9e 4acd 4e00 00ed 0001
>> 000b 0100 0038 0002 0003 a037 8e0c d6b3 de11 abb8
>> 0635 bff9 2b36
>>
>>
>> 003f
>> a037 8f0c d6b3 de11 abb8 0635 bff9 2b36 0001
>> 8a9e 4acd
>>
>> 001c 001c 0001
>> [ 175.215929] Closing the
>> device.
>> mount: mounting /dev/ftl on /mntpt/ failed: Invalid argument
>>
>> I tried printing the data in hex format just to make sure proper ext2 magic
>> code in present in the superblock read from the flash device. "ef53" is the
>> magic code of ext2 superblock, ftl device is correctly reading the magic
>> code
>>
>> # cat out
>> execve("/bin/mount", ["mount", "-t", "ext2", "/dev/ftl", "/mntpt/"], [/* 4
>> vars */]) = 0
>> uname({sys="Linux", node="(none)", ...}) = 0
>> brk(0) = 0x72f000
>> brk(0x72ff40) = 0x72ff40
>> arch_prctl(ARCH_SET_FS, 0x72f880) = 0
>> open("/dev/urandom", O_RDONLY) =
Re: Mounting block device fails.
On Fri, Oct 9, 2009 at 11:16 AM, Prasad Joshi wrote:
> Thanks Manish,
>
> The issue was with filesystem creation. It was not getting created
> properly. I used dumpe2fs command to verify the file system. Actually
> Superblock was written correctly but, few other fields like free block
> and free inode list etc were incorrect
>
> It seems to be working properly now
> # dumpe2fs /dev/ftl
> ...
> ...
> Group 0: (Blocks 0-65527)
> Primary superblock at 0, Group descriptors at 1-1
> Reserved GDT blocks at 2-8
> Block bitmap at 9 (+9), Inode bitmap at 10 (+10)
> Inode table at 11-1034 (+11)
> 64489 free blocks, 32757 free inodes, 2 directories
> Free blocks: 1039-65527
> Free inodes: 12-32768
> Group 1: (Blocks 65528-131055)
> Backup superblock at 65528, Group descriptors at 65529-65529
> Reserved GDT blocks at 65530-65536
> Block bitmap at 65537 (+9), Inode bitmap at 65538 (+10)
> Inode table at 65539-66562 (+11)
> 64493 free blocks, 32768 free inodes, 0 directories
> Free blocks: 66563-131055
> Free inodes: 32769-65536
>
> # mount
> ...
> ...
> /dev/ftl on /mntpt type ext2 (rw,relatime,errors=continue)
>
>
> The other problem which I am facing is with the blocksize.
>
> mkfs allows ext2 file system be created with blocksize=8192,
> overriding the default 4096. But, when I try to mount the file system
> it fails
>
> # mkfs -t ext2 -b 8192 /dev/ftl
> Warning: blocksize 8192 not usable on most systems.
> mke2fs 1.41.4 (27-Jan-2009)
> mkfs.ext2: 8192-byte blocks too big for system (max 4096)
> Proceed anyway? (y,n) y
> Warning: 8192-byte blocks too big for system (max 4096), forced to continue
> warning: 16 blocks unused.
>
> Filesystem label=
> OS type: Linux
> Block size=8192 (log=3)
> Fragment size=8192 (log=3)
> 65536 inodes, 131056 blocks
>
>
>
> # mount -t ext2 /dev/ftl /mntpt
> [54658.092031] EXT2-fs: blocksize too small for device.
> mount: mounting /dev/ftl on /mntpt failed: Invalid argument
>
> I tried specifying blocksize with the mount command, but it also fails
>
> # mount -t ext2 /dev/ftl /mntpt -o blocksize=8192
> mount: mounting /dev/ftl on /mntpt failed: Invalid argument
>
> The above command fails in parsing the options passed to the command
>
> The section "Mount options for ext2" of mount manpage does not mention
> blocksize option.
Yes, there is no "blocksize" option in ext2. For a list of valid
options see "tokens" table in ext2/super.c
>
> Is there anyway I can create ext2 filesystem with blocksize 8192?
No ... as far as I know.
Man page of mke2fs says :
-b block-size
Specify the size of blocks in bytes. Valid block-size
values are 1024, 2048 and 4096 bytes per block.
And the kernel code says :
int sb_set_blocksize(struct super_block *sb, int size)
{
if (set_blocksize(sb->s_bdev, size))
return 0;
/* If we get here, we know size is power of two
* and it's value is between 512 and PAGE_SIZE */
sb->s_blocksize = size;
sb->s_blocksize_bits = blksize_bits(size);
return sb->s_blocksize;
}
and the PAGE_SIZE is 4096.
Reiserfs supports blocksizes of 8192 , but its man page says :-
-b | --block-size N
N is block size in bytes. It may only be set to a power
of 2 within the 512-8192 interval. Note
that current versions of the kernel ( 2.6.19 ) do NOT
support any size other than 4096.
But is there any specific reason you want to use block sizes of 8192 ?
>
> Thanks and Regards,
> Prasad
>
> On Thu, Oct 8, 2009 at 6:41 PM, Manish Katiyar wrote:
>> On Thu, Oct 8, 2009 at 12:38 PM, Prasad Joshi
>> wrote:
>>> Hi,
>>>
>>> I am working on translation layer for flash. For the purpose testing I am
>>> using a disk file to simulate the flash behavior. So every read and write on
>>> the block device finally goes to a disk file, something similar to loop
>>> device, but in addition maintaining the flash property.
>>>
>>> I am able to create the file system on the device (/dev/ftl) but when I try
>>> to mount the device it fails with error "Invalid Argument".
>>
>> From the code I can see -EINVAL can be returned at lot of places. You
>> need to see dmesg to see the message which can help tracing.
>>
>>>
>>> I thought it is failing to read the super block of the file systems, but it
>>> seems like it did not fail in superblock read
>>>
>>> # strace -o out mount -t ext2 /dev/ftl /mntpt/
>>> [ 175.192033] Opening the device.
>>> [ 175.193599] IftlIoRead: offset=0x400 Length=0x400
>>> [ 175.193875] OffsetWithinPage: 400
>>> [ 175.195104] Read pos=1002535424, length=8192
>>> [ 175.195474] 0001 0004 eea5 0003 fff5
>>> 0002 0002 8000 8000 2000 8a9e 4acd
>>> 0020 ef53 0001 0001 8a9e 4acd 4e00 00ed 0001
>>> 000b 0100 0038 0002 0003 a037 8e0c d6b3 de11 abb8
>>> 0635 bff9 2b36
preempt_disable() as synchronization tool
Hi List, I have few queries related to preempt_disable() and would appreciate any answers to it. Firstly, Does preempt_disable() disable the preemption on all the processors or on just the local processor? Secondly, a preempt_disable() a suffifient synchronization technique to guard a data that is shared only among process context code on a Uni-processor? And on SMP? Lastly, is it allowable to schedule / sleep immediately after a call to preempt_disable()? Thanks & Best Regards, Dan -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
USB controller driver question
Hi all, I am debugging an issue for a USB device (usb wifi dongle from TP-LINK which is using Ralink chipset). I am using it on an embedded board running Linux 2.6.30 on ARM architecture. The board has USB controller from synopsys, and they've provided the driver for the same. The controller has the feature to switch between USB speeds (i.e. 1.0 and 2.0). When I configure the USB controller in USB 1.0 speed, my USB device (i.e. usb wifi dongle) works perfectly fine. But when the USB controller is configured for USB 2.0, the device stops working after some time when doing large data transfer at high speed. Its not crashing the Linux, but the system becomes non-responsive. I could capture the USB packets (using analyzer) between controller and device and found that there was continuous PING - NAK token exchanges were happening. I could re-confirm this scenario by putting some debug prints in controller driver. From this observation, I assumed that it may happen that device is not able to release the buffers and because of that its sending NAK to each incoming PING request. When I reduced the number of PINGs sent out by USB controller driver, the device was working fine. Currently I am skipping every alternate PING token from controller driver. I want to understand that what should be the ideal frequency to send PING tokens. Should it be very aggressive? I searched through the code of ehci driver in linux kernel, but could not figure out where the exactly PING protocol is implemented in that. Can you please point out the part of source code, so that I can look into it and see how it is implemented ? Thanks, Vishal -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
preempt_disable() as a synchronization tool
Hi List, I have few queries related to preempt_disable() and would appreciate any answers to it. Firstly, Does preempt_disable() disable the preemption on all the processors or on just the local processor? Secondly, a preempt_disable() a suffifient synchronization technique to guard a data that is shared only among process context code on a Uni-processor? And on SMP? Lastly, is it allowable to schedule / sleep immediately after a call to preempt_disable()? Thanks & Best Regards, Dan -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
kernel newbie column -- more initrd and initramfs
http://cli.gs/uyEENL. enjoy. feel free to point out errors and typoes in the comments section. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: waking up processes while holding spinlock
On Thu, Oct 8, 2009 at 7:30 PM, Denis Kirjanov wrote:
> Hello dear all!
>
> Suppose, we have the following pseudo code:
>
> spin_lock(&some_lock);
> some_func();
> spin_unlock(&some_lock);
>
> some_fun()
> {
> .
> wake_up_interruptibe_sync(&wait_queue);
>
> }
> Is this correct behavior or not?
>
> This is a call chain:
> wake_up_interruptible_sync ---> wake_up_sync ---> wake_up_common(...,
> sync=1, ...) ---> ... ---> try_to_wake_up(..., sync=1)
> try_to_wake_up invokes resched_task().
> As a result, we invoke one thread, while other holds the lock.
>
> Tell me please, my assumption is correct?
>
> --
> Regards,
> Denis
>
I dont think try_to_wake_up call invokes any rescheduling function.
Also, __wake_up_sync is already calling __wake_up_common with spin
lock held, so i think it is safe what you are trying to do. Please
correct me if I am wrong at any point.
[snip]
void
4349__wake_up_sync(wait_queue_head_t *q, unsigned int mode, int nr_exclusive)
4350{
4351unsigned long flags;
4352int sync = 1;
4353
4354if (unlikely(!q))
4355return;
4356
4357if (unlikely(!nr_exclusive))
4358sync = 0;
4359
4360spin_lock_irqsave(&q->lock, flags);
4361__wake_up_common(q, mode, nr_exclusive, sync, NULL);
4362spin_unlock_irqrestore(&q->lock, flags);
4363}
[\snip]
-Vinit
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecar...@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ
waking up processes while holding spinlock
Hello dear all!
Suppose, we have the following pseudo code:
spin_lock(&some_lock);
some_func();
spin_unlock(&some_lock);
some_fun()
{
.
wake_up_interruptibe_sync(&wait_queue);
}
Is this correct behavior or not?
This is a call chain:
wake_up_interruptible_sync ---> wake_up_sync ---> wake_up_common(...,
sync=1, ...) ---> ... ---> try_to_wake_up(..., sync=1)
try_to_wake_up invokes resched_task().
As a result, we invoke one thread, while other holds the lock.
Tell me please, my assumption is correct?
--
Regards,
Denis
Re: Mounting block device fails.
On Thu, Oct 8, 2009 at 12:38 PM, Prasad Joshi wrote:
> Hi,
>
> I am working on translation layer for flash. For the purpose testing I am
> using a disk file to simulate the flash behavior. So every read and write on
> the block device finally goes to a disk file, something similar to loop
> device, but in addition maintaining the flash property.
>
> I am able to create the file system on the device (/dev/ftl) but when I try
> to mount the device it fails with error "Invalid Argument".
>From the code I can see -EINVAL can be returned at lot of places. You
need to see dmesg to see the message which can help tracing.
>
> I thought it is failing to read the super block of the file systems, but it
> seems like it did not fail in superblock read
>
> # strace -o out mount -t ext2 /dev/ftl /mntpt/
> [ 175.192033] Opening the device.
> [ 175.193599] IftlIoRead: offset=0x400 Length=0x400
> [ 175.193875] OffsetWithinPage: 400
> [ 175.195104] Read pos=1002535424, length=8192
> [ 175.195474] 0001 0004 eea5 0003 fff5
> 0002 0002 8000 8000 2000 8a9e 4acd
> 0020 ef53 0001 0001 8a9e 4acd 4e00 00ed 0001
> 000b 0100 0038 0002 0003 a037 8e0c d6b3 de11 abb8
> 0635 bff9 2b36
>
>
> 003f
> a037 8f0c d6b3 de11 abb8 0635 bff9 2b36 0001
> 8a9e 4acd
>
> 001c 001c 0001
> [ 175.215929] Closing the
> device.
> mount: mounting /dev/ftl on /mntpt/ failed: Invalid argument
>
> I tried printing the data in hex format just to make sure proper ext2 magic
> code in present in the superblock read from the flash device. "ef53" is the
> magic code of ext2 superblock, ftl device is correctly reading the magic
> code
>
> # cat out
> execve("/bin/mount", ["mount", "-t", "ext2", "/dev/ftl", "/mntpt/"], [/* 4
> vars */]) = 0
> uname({sys="Linux", node="(none)", ...}) = 0
> brk(0) = 0x72f000
> brk(0x72ff40) = 0x72ff40
> arch_prctl(ARCH_SET_FS, 0x72f880) = 0
> open("/dev/urandom", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> brk(0x750f40) = 0x750f40
> brk(0x751000) = 0x751000
> getuid() = 0
> getuid() = 0
> geteuid() = 0
> stat("/dev/ftl", {st_mode=S_IFBLK|0644, st_rdev=makedev(254, 0), ...}) = 0
> mount("/dev/ftl", "/mntpt/", "ext2", MS_SILENT, "") = -1 EINVAL (Invalid
> argument)
> vfork() = 869
> --- SIGCHLD (Child exited) @ 0 (0) ---
> write(2, "mount: mounting /dev/ftl on /mntp"..., 61) = 61
> exit_group(-1) = ?
>
> What could be the reason of failure of mount?
>
> Thanks and Regards,
> Prasad
>
>
--
Thanks -
Manish
==
[$\*.^ -- I miss being one of them
==
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecar...@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ
splice on fat filesystem
Hi All, I want to use splice call to improve performance of file copying on fat filesystem. But in fat filesystem driver (fs/fat/file.c) there isn't support for splice_write. I checked it in file_operations struct of fat driver (fs/fat/file.c:146 on 2.6.30.5 kernel). It has implementation of splice_read only. I checked that all other filesystem drivers are using generic_file_splice_write function for splice_write implementation. So I made change in fat filesystem driver for same. Following is change I made in file.c. With this change splice is working fine on fat filesystem. @@ -144,6 +144,7 @@ .ioctl= fat_generic_ioctl, .fsync= file_fsync, .splice_read= generic_file_splice_read, +.splice_write= generic_file_splice_write, }; static int fat_cont_expand(struct inode *inode, loff_t size) Is this correct way to add support for splice write on fat? Also Is there any specific reason for not having support for splice_write in fat driver in main stream Linux kernel source? I also doubt that splice will really improve performance compare to read/write operation on filesystem. Any input on splice will be helpful. Thanks in advance. Thanks, Rahul Patel Embedded Software Engineer eInfochips Ltd. Tel. No. 91-79-26400801-2 Ext. 156 www.einfochips.com -- _ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. _ -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
sse2 in kernel code
Can one safely use SSE2 instructions in kernel module code? Or are those 128bit registers not preserved across kernel/userspace context switch? -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Changing Kernel 3g / 1g memory split
> > Interesting. I've previously used 2G/2G split (some years ago, before 64b >> was prevalent) quite a bit and never needed to recompile existing binaries >> and libraries on the distro, and never had issues. Perhaps the default >> addresses are quite low (well below 2G)? Also, how does ASLR ( >> http://en.wikipedia.org/wiki/Address_space_layout_randomization ) play >> into this? > > > Yes, looks like truth. If program does not using memory more than 2gb, it's ok. But what happens if it does? -- Regards, Denis
RE: Changing Kernel 3g / 1g memory split
Hi,
>>> 3) And finally, in order to complete this change and to ensure my
> >>> applications are awrae of it and are doing the needful to restrict
> >>> themselves in only 2G, do I also need to make changes in
> >> the glibc or
> >>> the gcc?
> >>
> >> No, you don't need changes to glibc or gcc.
> >>
> >
> > I think he will need to. In the ELF user space executables
> in most of
> > the cases, the address at which each synbol (function / data) will
> > go is
> > generally fixed at compile time. So I think mosty of the
> > applications in
> > user space will need a recomile with a compiler that is
> aware of the
> > new
> > 2G/2G split.
> >
>
> Interesting. I've previously used 2G/2G split (some years
> ago, before
> 64b was prevalent) quite a bit and never needed to recompile
> existing
> binaries and libraries on the distro, and never had issues. Perhaps
> the default addresses are quite low (well below 2G)?
I think so. See below:
[ra...@linux-server module]$ cat t.c
int main()
{
for(;;);
return 0;
}
[ra...@linux-server module]$ gcc t.c
[ra...@linux-server module]$ ./a.out &
[1] 18189
[ra...@linux-server module]$ readelf -S a.out | grep "test\|data\|bss"
[14] .rodata PROGBITS0804842c 00042c 08 00 A
0 0 4
[22] .data PROGBITS08049528 000528 0c 00 WA
0 0 4
[23] .bss NOBITS 08049534 000534 04 00 WA
0 0 4
The above the virtual addresses of the code and data sections (which are
well under 2G).
[ra...@linux-server module]$
[ra...@linux-server module]$ cat /proc/18189/maps |grep "a.out"
08048000-08049000 r-xp 00:13 1594602
/netapp_filer/users/rajat/linux/module/a.out
08049000-0804a000 rw-p 00:13 1594602
/netapp_filer/users/rajat/linux/module/a.out
The same memory pages have been mapped into user application as evident
above. Also, all the symbols in the application are well below 2G:
[ra...@linux-server module]$ readelf -s a.out
Symbol table '.dynsym' contains 5 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 239 FUNCGLOBAL DEFAULT UND
__libc_start_m...@glibc_2.0 (2)
2: 08048430 4 OBJECT GLOBAL DEFAULT 14 _IO_stdin_used
3: 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
4: 0 NOTYPE WEAK DEFAULT UND __gmon_start__
Symbol table '.symtab' contains 69 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 08048114 0 SECTION LOCAL DEFAULT1
2: 08048128 0 SECTION LOCAL DEFAULT2
3: 08048148 0 SECTION LOCAL DEFAULT3
4: 08048170 0 SECTION LOCAL DEFAULT4
5: 080481c0 0 SECTION LOCAL DEFAULT5
6: 0804821a 0 SECTION LOCAL DEFAULT6
7: 08048224 0 SECTION LOCAL DEFAULT7
8: 08048244 0 SECTION LOCAL DEFAULT8
9: 0804824c 0 SECTION LOCAL DEFAULT9
10: 08048254 0 SECTION LOCAL DEFAULT 10
11: 0804826c 0 SECTION LOCAL DEFAULT 11
12: 0804828c 0 SECTION LOCAL DEFAULT 12
13: 08048410 0 SECTION LOCAL DEFAULT 13
14: 0804842c 0 SECTION LOCAL DEFAULT 14
15: 08048434 0 SECTION LOCAL DEFAULT 15
16: 08049438 0 SECTION LOCAL DEFAULT 16
17: 08049440 0 SECTION LOCAL DEFAULT 17
18: 08049448 0 SECTION LOCAL DEFAULT 18
19: 0804944c 0 SECTION LOCAL DEFAULT 19
20: 08049514 0 SECTION LOCAL DEFAULT 20
21: 08049518 0 SECTION LOCAL DEFAULT 21
22: 08049528 0 SECTION LOCAL DEFAULT 22
23: 08049534 0 SECTION LOCAL DEFAULT 23
24: 0 SECTION LOCAL DEFAULT 24
25: 0 SECTION LOCAL DEFAULT 25
26: 0 SECTION LOCAL DEFAULT 26
27: 0 SECTION LOCAL DEFAULT 27
28: 080482b0 0 FUNCLOCAL DEFAULT 12 call_gmon_start
29: 0 FILELOCAL DEFAULT ABS crtstuff.c
30: 08049438 0 OBJECT LOCAL DEFAULT 16 __CTOR_LIST__
31: 08049440 0 OBJECT LOCAL DEFAULT 17 __DTOR_LIST__
32: 08049448 0 OBJECT LOCAL DEFAULT 18 __JCR_LIST__
33: 08049530 0 OBJECT LOCAL DEFAULT 22 p.0
34: 08049534 1 OBJECT LOCAL DEFAULT 23 completed.1
35: 080482d4 0 FUNCLOCAL DEFAULT 12 __do_global_dtors_aux
36: 08048308 0 FUNCLOCAL DEFAULT 12 frame_dummy
37: 0 FILELOCAL DEFAULT ABS crtstuff.c
38: 0804943c 0 OBJECT LOCAL DEFAULT 16 __CTOR_END__
39: 08049444 0 OBJECT LOCAL DEFAULT 17 __DTOR_END__
40: 08048434 0 OBJECT LOCAL DEFAULT 15 __FRAME_END__
41: 08049448 0 OBJECT LOCAL DEFAULT 18 __JCR_END__
42: 080483ec 0 FUNCLOCAL DEFAULT 12 __do_global_ctors_aux
43: 0 FILELOCAL DEFAULT ABS t.c
44
Re: Recursive makefiles for module spanning over multiple dir
On Thu, Oct 8, 2009 at 7:53 AM, Rajat Jain wrote: > Hi, > >>> >>> obj-m = test.o >>> test-objs := test1/test1.o test2/test2.o >>> >>> No need for makefiles under test1 and test2. However, only throwing >>> ideas here, without a feasibility check. >>> >>> Thanks, >>> >>> Rajat >>> >> >> Why it is not possible? Just trying to understand whether it is >> limited by the Linux kernel build system or what? User space >> makefiles almost all the time have this recursive nature. Any >> pointers? >> >> > On second thoughts, the solution above should work > > Rajat > For me it is not working, only difference is I am using make -f Makefile.kern i.e. top level make file is renamed as Makefile.kern, there are reasons I am not naming it as Makefile. When I do make -f Makefile.kern, I get following error: make[1]: Entering directory `/usr/src/linux-headers-2.6.28-15-generic' scripts/Makefile.build:41: /home/Leo/Desktop/My_Kernel_Stuff/TEST/Makefile: No such file or directory make[2]: *** No rule to make target `/home/Leo/Desktop/My_Kernel_Stuff/TEST/Makefile'. Stop. make[1]: *** [_module_/home/Leo/Desktop/My_Kernel_Stuff/TEST] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-2.6.28-15-generic' Looks like it is trying to look for an file named Makefile, which I have renamed as Makefile.kern. If this is the case then what is the point of make -f. -Leo. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
RE: Recursive makefiles for module spanning over multiple dir
Hi, > > For me it is not working, only difference is I am using make > -f Makefile.kern > i.e. top level make file is renamed as Makefile.kern, there > are reasons I am > not naming it as Makefile. > > When I do make -f Makefile.kern, > I get following error: > > make[1]: Entering directory `/usr/src/linux-headers-2.6.28-15-generic' > scripts/Makefile.build:41: > /home/Leo/Desktop/My_Kernel_Stuff/TEST/Makefile: No such file or > directory > make[2]: *** No rule to make target > `/home/Leo/Desktop/My_Kernel_Stuff/TEST/Makefile'. Stop. > make[1]: *** [_module_/home/Leo/Desktop/My_Kernel_Stuff/TEST] Error 2 > make[1]: Leaving directory `/usr/src/linux-headers-2.6.28-15-generic' > > > Looks like it is trying to look for an file named Makefile, which I > have renamed as Makefile.kern. > If this is the case then what is the point of make -f. > -Leo. > Leo, you cannot give Makefile -f command. You will have to compile your module like this only (and thus will need to name your Makefile "Makefile" only and not "Makefile.kern"): make -C ../linux-2.6.25/ M=`pwd` modules The reason is when you give -C option to the make, you are actually changin to the kernel tree and using the top level Makefile there which has rules to recurse into each directory and us "Makefile" there (not Makefile.kern). Thanks, Rajat -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: C question
On Thu, Oct 8, 2009 at 7:42 AM, Rick Brown wrote: As far as I recall from K&R, isn't pointer arithmetic on a void pointer banned? And any effort to do that results in an error - because the compiler won't know by how much size to increment the pointer for a statement like "ptr++"? On Thu, 08 Oct 2009 04:52:31 +0200, Manish Katiyar wrote: But in the program, you aren't actually trying to dereference the value. Just adding means it becomes normal arithmetic and that is why you get result as 1. You will see the error if you try to dereference it. This comment is a bit misleading. The standard does not define behaviour of pointer arithmetic on pointer to void. What one need to realise is that undefined behaviour means compiler's documentation may well define how such a construct is evaluated and gcc (with proper options) decides to treat pointer to void as if sizeof(void) == 1. So the thing it's true pointer arithmetic on a pointer to void is undefined behaviour as far as C standard is concerned however because Linux is compiled with gcc kernel's developers tend to make use of gcc's extensions and one of it is arithmetic on a pointer to void. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał "mina86" Nazarewicz (o o) ooo +-ooO--(_)--Ooo-- -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Changing Kernel 3g / 1g memory split
On 08 Oct 2009, at 9:08 AM, Rajat Jain wrote: Hi, 3) And finally, in order to complete this change and to ensure my applications are awrae of it and are doing the needful to restrict themselves in only 2G, do I also need to make changes in the glibc or the gcc? No, you don't need changes to glibc or gcc. I think he will need to. In the ELF user space executables in most of the cases, the address at which each synbol (function / data) will go is generally fixed at compile time. So I think mosty of the applications in user space will need a recomile with a compiler that is aware of the new 2G/2G split. Interesting. I've previously used 2G/2G split (some years ago, before 64b was prevalent) quite a bit and never needed to recompile existing binaries and libraries on the distro, and never had issues. Perhaps the default addresses are quite low (well below 2G)? Also, how does ASLR ( http://en.wikipedia.org/wiki/ Address_space_layout_randomization ) play into this? -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: C question
Hi Rick,
gcc can warn about void pointer increment if you use compiler option
-Wpointer-arith
==
Kalpesh
On Thu, Oct 8, 2009 at 8:22 AM, Manish Katiyar wrote:
> On Thu, Oct 8, 2009 at 7:42 AM, Rick Brown wrote:
>> Hello list,
>>
>> As far as I recall from K&R, isn't pointer arithmetic on a void
>> pointer banned? And any effort to do that results in an error -
>> because the compiler won't know by how much size to increment the
>> pointer for a statement like "ptr++"? But then how about this:
>
> But in the program, you aren't actually trying to dereference the
> value. Just adding means it becomes normal arithmetic and that is why
> you get result as 1. You will see the error if you try to dereference
> it.
>
> /tmp> gcc a.c
> a.c: In function ‘main’:
> a.c:5: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘void
> *’
> a.c:6: warning: dereferencing ‘void *’ pointer
> a.c:6: error: invalid use of void expression
> /tmp> cat a.c
> #include
> int main()
> {
> void *ptr = 0;
> printf("%d \n", ptr+1);
> printf("%d \n", *(ptr+1));
> }
>
>
>>
>> [r...@linux rick]$ cat t.c
>> #include
>> int main()
>> {
>> void *ptr = 0;
>> printf("%d \n", ptr+1);
>> }
>> [r...@linux rick]$ gcc t.c
>> [r...@linux rick]$ ./a.out
>> 1
>> [r...@linux rick]$
>>
>> It compiles and runs fine ... !
>>
>> TIA,
>>
>> Rick
>>
>> --
>> To unsubscribe from this list: send an email with
>> "unsubscribe kernelnewbies" to ecar...@nl.linux.org
>> Please read the FAQ at http://kernelnewbies.org/FAQ
>>
>>
>
>
>
> --
> Thanks -
> Manish
> ==
> [$\*.^ -- I miss being one of them
> ==
>
> --
> To unsubscribe from this list: send an email with
> "unsubscribe kernelnewbies" to ecar...@nl.linux.org
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecar...@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ
Mounting block device fails.
Hi,
I am working on translation layer for flash. For the purpose testing I am
using a disk file to simulate the flash behavior. So every read and write on
the block device finally goes to a disk file, something similar to loop
device, but in addition maintaining the flash property.
I am able to create the file system on the device (/dev/ftl) but when I try
to mount the device it fails with error "Invalid Argument".
I thought it is failing to read the super block of the file systems, but it
seems like it did not fail in superblock read
# strace -o out mount -t ext2 /dev/ftl /mntpt/
[ 175.192033] Opening the device.
[ 175.193599] IftlIoRead: offset=0x400 Length=0x400
[ 175.193875] OffsetWithinPage: 400
[ 175.195104] Read pos=1002535424, length=8192
[ 175.195474] 0001 0004 eea5 0003 fff5
0002 0002 8000 8000 2000 8a9e 4acd
0020 *ef53* 0001 0001 8a9e 4acd 4e00 00ed 0001
000b 0100 0038 0002 0003 a037 8e0c d6b3 de11 abb8
0635 bff9 2b36
003f
a037 8f0c d6b3 de11 abb8 0635 bff9 2b36 0001
8a9e 4acd
001c 001c 0001
[ 175.215929] Closing the
device.
mount: mounting /dev/ftl on /mntpt/ failed: Invalid argument
I tried printing the data in hex format just to make sure proper ext2 magic
code in present in the superblock read from the flash device. "*ef53*" is
the magic code of ext2 superblock, ftl device is correctly reading the magic
code
# cat out
execve("/bin/mount", ["mount", "-t", "ext2", "/dev/ftl", "/mntpt/"], [/* 4
vars */]) = 0
uname({sys="Linux", node="(none)", ...}) = 0
brk(0) = 0x72f000
brk(0x72ff40) = 0x72ff40
arch_prctl(ARCH_SET_FS, 0x72f880) = 0
open("/dev/urandom", O_RDONLY) = -1 ENOENT (No such file or
directory)
brk(0x750f40) = 0x750f40
brk(0x751000) = 0x751000
getuid()= 0
getuid()= 0
geteuid() = 0
stat("/dev/ftl", {st_mode=S_IFBLK|0644, st_rdev=makedev(254, 0), ...}) = 0
mount("/dev/ftl", "/mntpt/", "ext2", MS_SILENT, "") = -1 EINVAL (Invalid
argument)
vfork() = 869
--- SIGCHLD (Child exited) @ 0 (0) ---
write(2, "mount: mounting /dev/ftl on /mntp"..., 61) = 61
exit_group(-1) = ?
What could be the reason of failure of mount?
Thanks and Regards,
Prasad
RE: Changing Kernel 3g / 1g memory split
Hi, > > > > > 3) And finally, in order to complete this change and to ensure my > > applications are awrae of it and are doing the needful to restrict > > themselves in only 2G, do I also need to make changes in > the glibc or > > the gcc? > > No, you don't need changes to glibc or gcc. > I think he will need to. In the ELF user space executables in most of the cases, the address at which each synbol (function / data) will go is generally fixed at compile time. So I think mosty of the applications in user space will need a recomile with a compiler that is aware of the new 2G/2G split. Thanks, Rajat -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
RE: Recursive makefiles for module spanning over multiple dir
It works for me. See below:
[ra...@linux-server module]$ cat Makefile
obj-m := module.o
module-objs := 1/t1.o 2/t2.o
[ra...@linux-server module]$ cat 1/t1.c
#include
#include
void hello_exit(void)
{
printk(KERN_ALERT "Goodbye, cruel world\n");
}
[ra...@linux-server module]$ cat 2/t2.c
#include
#include
MODULE_LICENSE("Dual BSD/GPL");
static int hello_init(void)
{
printk(KERN_ALERT "Hello, world\n");
return 0;
}
extern void hello_exit(void);
module_init(hello_init);
module_exit(hello_exit);
[ra...@linux-server module]$ make -C ../linux-2.6.25/ M=`pwd` modules
make: Entering directory `/netapp_filer/users/rajat/linux/linux-2.6.25'
CC [M] /netapp_filer/users/rajat/linux/module/1/t1.o
CC [M] /netapp_filer/users/rajat/linux/module/2/t2.o
LD [M] /netapp_filer/users/rajat/linux/module/module.o
Building modules, stage 2.
MODPOST 1 modules
CC /netapp_filer/users/rajat/linux/module/module.mod.o
LD [M] /netapp_filer/users/rajat/linux/module/module.ko
make: Leaving directory `/netapp_filer/users/rajat/linux/linux-2.6.25'
[ra...@linux-server module]$
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecar...@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Classic confusion: initrd-initramfs
On Thu, Oct 8, 2009 at 8:49 AM, Rajat Jain wrote: > > Hi, > > OK, I know enough has already been discussed on this topic and I think > that I'm just not able to put pieces in place. So I understand the basic > difference between an initrd (having a filesystem on a block /loopback > device and mounting it on a ramdisk) and initramfs (Having a compressed > cpio archieve included in the kernel image and weaving a file system > directly on RAM to see the contents of this cpio). > I assume this > discussion is not limited to x86 architectures and initrd / initram fs > can be used on all the other architectures also? > > As per my understanding, this should work for other architectures but not sure. 1) Firstly, are initramfs and initrd mutually exclusive techniques to > achieve the same goal (providing initial drivers)? Does enabling one > disable the other OR they complement / help each other? Conceptually, > the former should be true, but browsing through the kernel config, the > latter seems true. > > All 2.6 Linux kernels contain a gzipped "cpio" format archive, which is extracted into rootfs when the kernel boots up. After extracting, the kernel checks to see if rootfs contains a file "init", and if so it executes it as PID 1. If found, this init process is responsible for bringing the system the rest of the way up, including locating and mounting the real root device (if any). If rootfs does not contain an init program after the embedded cpio archive is extracted into it, the kernel will fall through to the older code to locate and mount a root partition, then exec some variant of /sbin/init out of that. Reference: Kernel Documentation file(~/linux-2.6.18/Documentation/filesystems/ramfs-rootfs-initramfs.txt). > 2) The initrd image CANNOT be combined with kernel image to produce a > single image, and the initramfs image cannot be seperated out from > kernel image and later provided at boot time as a separate image, right? > > > 3) I understand in case of initramfs, kernel does everything including > loading of initramfs image (since it is included in kernel image only). > But in case of initrd image, who loads the initrd image into memory? The > bootloader I assume ... Because grub and lilo have a "initrd" line in > their config file. But then how is it communicated to the kernel where > in RAM (at which address) is the initrd loaded? > > initrd is loaded by BIOS. BIOS handles all the work of loading it into memory. Quick search gave me : http://www.alexonlinux.com/opening-and-modifying-the-initrd The bootloader will load the kernel and initrd image into memory and then start the kernel, passing in the memory address of the initrd http://en.wikipedia.org/wiki/Initrd 4) How about non-X86 architectures that don't have lilo / grub? Who > loads initrd image into memory in that case and how is it communicated > to kernel? > > 5) What does the "initrd=" kernel command line parameter mean, and is it > applicable only for x86? > > 6) Is there a unified way of loading initrd on all architectures? Most > of the online text suggestes to make entry into lilo or grub, which are > not available else where... > > Thanks & Best Regards, > > Rajat Jain > > > -- > To unsubscribe from this list: send an email with > "unsubscribe kernelnewbies" to ecar...@nl.linux.org > Please read the FAQ at http://kernelnewbies.org/FAQ > > -- Thanks & Regards, Ajit Subhash Mote
