RE: Device node - How does kernel know about it
Thanks for the response Phillip. See below for response. I already am using "console=ttyS0" as well as set the inittab correctly. I would like to debug this node behavior. Can you please let me know which routine gets called first when there is, for example a read() call from user program. Eventually it will result in a call to what ever read routine registered, but that must be a call back function or some thing. Right? - Siva -Original Message- From: Phillip Susi [mailto:[EMAIL PROTECTED] Sent: Thursday, December 27, 2007 12:10 PM To: Siva Prasad Cc: linux-kernel@vger.kernel.org Subject: Re: Device node - How does kernel know about it Siva Prasad wrote: > Hi, > > How do the device nodes work as an interface between user and kernel > programs, and how to go debugging it? > This is as part of my debugging effort on an embedded board. The filesystem sets specific bits in the mode mask and elsewhere in the inode to mark the file as a dev node, and which major/minor device number it should be linked to. The kernel device drivers register to handle a given device number. > * It all started with the problem of "not printing" any thing that comes > from ramdisk (echo and printf statements), while kernel printk's work > perfectly fine. > * Ramdisk is also executing fine, just that prints are not coming out of > serial. I can see the execution of various user programs with a printk > in sys_execve() routine. Ramdisk has all the required files like > /dev/console, /dev/ttyS0, etc. So you did you pass the console=ttyS0 parameter to the kernel? Did you configure your inittab to spawn the getty on the serial port instead of /dev/ttyN? You might want to take a look at the Linux Serial Console HOWTO. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Device node - How does kernel know about it
Hi, How do the device nodes work as an interface between user and kernel programs, and how to go debugging it? This is as part of my debugging effort on an embedded board. * It all started with the problem of "not printing" any thing that comes from ramdisk (echo and printf statements), while kernel printk's work perfectly fine. * Ramdisk is also executing fine, just that prints are not coming out of serial. I can see the execution of various user programs with a printk in sys_execve() routine. Ramdisk has all the required files like /dev/console, /dev/ttyS0, etc. * Looking further into tty driver, I noticed that call to tty_write() or do_tty_write() is not happening at all. So, somewhere the interface between kernel and user program is lost. * Just to check it out, I tried to write a small kernel module and a test program. - Attached memtest.c module (not really testing memory there. :-)) - Attached testmemtest.c user program, that just open's it and reads the information - Created a device node using "mknod /dev/memtest c 168 0" - When I do "insmod memtest.ko" inside the ramdisk bootup scripts, I could see all the printk's on the console - When I execute "testmemtest" next in the same script, it does not display the printk inside of memtest.c module. This only indicates that read call did not really go to the kernel side. - Just to check my program's validity, I checked on a similar machine and all the code works fine. - "uname -r" also matches with what I built. So, chances of exiting from open call because of mismatch is remote. Since userland cannot print, I have no idea what exactly is happening there. Now going back to the original question... How does a kernel know about device nodes and how to link with it. Basically I believe interface between user programs and kernel is lost at device nodes. Appreciate any help in continuing my debugging efforts. Thanks Siva memtest.c Description: memtest.c testmemtest.c Description: testmemtest.c
Testing RAM from userspace / question about memmap= arguments
Hi Matthew, I worked on some thing similar. For one of our customer product that goes to defense and security markets, we had to support maximum possible memory test. We implemented a mechanism of pre-test to test the memory with walking 1's and 0's just before Linux kernel starts allocating serious memory for its use. That way, coverage was almost 99%. Once Linux boots, we do a very through test using various algorithms, however as you said coverage of memory is little less when we test the system after Linux boots up completely. memtest86+ started as a very good alternative, until customer's customer started complaining about memory issues. Then we had no choice but to take this route and implement it ourselves from the scratch. If you want 100% coverage, it may not be possible unless you do it in BIOS early on. If you take the route of implementing some simple memory test in Linux kernel before it starts allocating memory, you get very good % of coverage. Good Luck. - Siva Date: Thu, 20 Dec 2007 14:17:10 + From: Matthew Bloch <[EMAIL PROTECTED]> Subject: Re: Testing RAM from userspace / question about memmap= arguments To: linux-kernel@vger.kernel.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 Jon Masters wrote: > On Tue, 2007-12-18 at 17:06 +, Matthew Bloch wrote: > >> I can see a few potential problems, but since my understanding of the >> low-level memory mapping is muddy at best, I won't speculate; I'd just >> appreciate any more expert views on whether this does work, or could be >> made to work. > > Yo, > > I don't think your testing approach is thorough enough. Clearly (knowing > your line of business - as a virtual machine provider), you want to do > pre-production testing as part of your provisioning. I would suggest > instead of using mlock() from userspace of simply writing a kernel > module that does this for every page of available memory. Yes this is to improve the efficiency of server burn-ins. I would consider a kernel module, but I still wouldn't be able to test the memory in which the kernel is sitting, which is my problem. I'm not sure even a kernel module could reliably test the memory in which it is residing (memtest86+ relocates itself to do this). Also I don't see how userspace testing is any less thorough than doing it in the kernel; I just need a creative way of accessing every single page of memory. I may do some experiments with the memmap args, some bad RAM and shuffling it between DIMM sockets when I have the time :) -- Matthew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: printf internals
Yes!... this is a embedded system, and will not have monitor. So, serial is the default console. I pass cmdline as "root=/dev/ram rw console=ttyS0,115200" Thanks Siva -Original Message- From: Scott Russell [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 19, 2007 3:31 PM To: Siva Prasad Cc: Clemens Koller; David Newall; linux-kernel@vger.kernel.org Subject: RE: printf internals On Wed, 2007-12-19 at 14:33 -0800, Siva Prasad wrote: > Thank you very much for your response Clemens. > > I tried strace on a regular system. It does not show which tty, etc., as it uses the stdout (fd = 1) and write(1, ...) to it. > > This is not a student project. I am trying to build my own kernel and ramdisk. Kernel boots fine to a point where it starts accessing ramdisk and executes init scripts. From there on nothing gets printed. I did some debugging and found that prints of user land programs are not coming to the serial console, while kernel prints are working fine. I found all the programs getting executed, by placing a printk in execve routine and printing the arguments. > > So, I wanted to trace down the path from user program to the kernel and see why it is not printing messages from user program. I placed a printk in drivers/char/tty_io.c:tty_write() and it is not getting called from my file system. I tried the same thing on my good system (say regular PC) and it works as expected. > > Any clues that can help debug this issue is highly appreciated. > How can I get access to the same printf string inside kernel. This sounds like you're printing out the serial console instead. -- Scott <[EMAIL PROTECTED]> AIM: BlueCame1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: printf internals
Thank you very much for your response Clemens. I tried strace on a regular system. It does not show which tty, etc., as it uses the stdout (fd = 1) and write(1, ...) to it. This is not a student project. I am trying to build my own kernel and ramdisk. Kernel boots fine to a point where it starts accessing ramdisk and executes init scripts. From there on nothing gets printed. I did some debugging and found that prints of user land programs are not coming to the serial console, while kernel prints are working fine. I found all the programs getting executed, by placing a printk in execve routine and printing the arguments. So, I wanted to trace down the path from user program to the kernel and see why it is not printing messages from user program. I placed a printk in drivers/char/tty_io.c:tty_write() and it is not getting called from my file system. I tried the same thing on my good system (say regular PC) and it works as expected. Any clues that can help debug this issue is highly appreciated. How can I get access to the same printf string inside kernel. Thanks Siva -Original Message- From: Clemens Koller [mailto:[EMAIL PROTECTED] Sent: Friday, December 14, 2007 8:16 AM To: David Newall Cc: Siva Prasad; linux-kernel@vger.kernel.org Subject: Re: printf internals David Newall schrieb: > Siva Prasad wrote: >> I am looking at how exactly does the printf in user programs succeeds in >> displaying characters to the serial console. > > Is it a student assignment? This is so not the right mailing list. Come on, are we playing hide and seek here? You can use strace to follow a typical hello world example and see what device it opens to feed the hello out. I.e. it can be to the current /dev/ttyX and not to /dev/console or if you are logged in via SSH to a machine, the device is again different... or if you use screen, ... Work your way from there and then use a Linux Source code Cross Reference (lxr, ask Google for one) and follow the code. Regards, -- Clemens Koller __ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
printf internals
Hi, I am looking at how exactly does the printf in user programs succeeds in displaying characters to the serial console. printf uses /dev/console to write the data. Once written to /dev/console, what happens to the string written? Is there any way, I can get access to those prints/string inside the kernel? Thanks Siva -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Ramdisk Vs NFS
Hi, What is the primary difference between Ramdisk and NFS with respect to the wait_queue's? If I use ramdisk, every thing works fine, but with NFS (or you may read as 'no ramdisk') kernel/sched.c:__wake_up_common() routines has a problem. Basically the value of "&q->task_list->next" is out of our memory range (not between 0xc000 and 0xF000), and this causes trouble of accessing non-existing memory. Why would this happen? Interesting thing is, this happens much before we even load the ramdisk drivers. Appreciate if any one has some insight into this. At least a pointer to where to start looking would be great. Thanks Siva - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
No Subject
Sorry for the newbie question.. Is it true that the ipc calls like msgget(),shmget()... are not really system calls? Cos in the file "asm/unistd.h" where the system calls are listed as __NR_xxx we dont find the appropriate listing for the ipc calls. What I guessed was that all the ipc calls are clubbed under the 'int ipc()' system call and this is well listed in the "asm/unistd.h" Could some one explain why the ipc is implemented this way rather that implementing them as individual system calls as in UNIX. Or is it the same way in UNIX __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
