On 12/27/07, Siva Prasad [off-list ref] wrote:

Thank you Jon and Nicholas.

I already have "console=ttyS0" in the kernel command line. That is not
helping me.

Do you have
CONFIG_EARLY_PRINTK=y
in .config?

I looked at the major/minor numbers with a good working system and it
looks correct for the nodes created in ramdisk.

What is the kernel routine that is first called when there is, for
example a read() function call from user program?
I would like to start debugging from there and see if any thing at all
happens when there is a call. Appreciate your help with this question.

Thanks
Siva


-----Original Message-----
From: Nicholas Mc Guire [mailto:der.herr@hofr.at]
Sent: Friday, December 28, 2007 12:39 AM
To: Siva Prasad
Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
Subject: Re: Device node - How does kernel know about it

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

quoted

* Ramdisk is also executing fine, just that prints are not coming out

of

quoted

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

quoted

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

quoted

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.

The kernel will simply look at the major:minor numbers - so maybe you
simply have a wrong major/minor for /dev/ttyS0 ? in that case you will
see nothing but other than that most things will go on working.

hofrat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFHdLY2nU7rXZKfY2oRApFpAKCKfGanKHGuFFJmUFy3aQtjmWNjEACfU7uK
hrfpn2RMn5l23ZqCOXV5rd8=
=GfsF
-----END PGP SIGNATURE-----

-- 
Jon Smirl
jonsmirl@gmail.com