March 2011 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

Debug Kernel Crash
by swathi suresh March 31, 2011

March 31, 2011

Hello All, I wanted to know what is the best way to generate the kernel crash dump on kernel panic, after doing some searching, i came to know we can use kexec to load a new kernel on the kernel, i followed the instruction from the following links http://www.dedoimedo.com/computers/kdump.html http://www.developertutorials.com/tutorials/linux/reboot-linux-faster-07220… I do found that the kernel load properly with the, kexec -l option followed by kexec -e option, but when i set the kernel to be loaded on kernel panic using the option kexec -p, i see that after kernel crash, the system just hangs, it wont even try to load the new kernel. following are the commands am using. Can some one point, if there is any thing wrong with this. chkconfig kdump on /etc/init.d/kdump start kexec -l --append="`cat /proc/cmdline`" --initrd=/boot/initrd.img-2.6.35.10-kdump /boot/vmlinuz-2.6.35.10-kdump kexec -e works fine and loads the kernel successfully, i will be able to see *starting new kernel* in the shell * * * chkconfig kdump on /etc/init.d/kdump start * kexec -p --append="`cat /proc/cmdline`" --initrd=/boot/initrd.img-2.6.35.10* -kdump ** /boot/vmlinuz-2.6.35.10 -kdump * * * i simulate the panic by using echo 1 > /proc/sys/kernel/sysrq echo c > /proc/sysrq-trigger which just crash the kernel and system hangs, and it does not show any message *starting new kernel.* * * Thanks,

1 0

Re: Avoid mandatory locks? Really? According to linux/Documentation/filesystems/mandatory-locking.txt
by Mulyadi Santosa March 30, 2011

March 30, 2011

On Wed, Mar 30, 2011 at 22:08, Kevin O'Gorman <kogorman(a)gmail.com> wrote: > That may be an overstatement. Most of the complaints are about DoS attacks > and/or > distributed systems. That's pretty awful, and means the locking is not > scaleable, but alright...maybe that's why, e.g in distributed fs such as GFS, we need (gfs) lockd or something like that...ok, now I could guess, that's due to some of POSIX lock weaknesses.. CMIIW -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com

1 0

Avoid mandatory locks? Really? According to linux/Documentation/filesystems/mandatory-locking.txt
by Kevin O'Gorman March 30, 2011

March 30, 2011

I have become suspicious of Section 0 of /usr/src/linux/Documentation/filesystems/mandatory-locking.txt. I am going to tell this as it unfolded, so that if I went wrong somewhere you can point it out to me. For some time I have been lecturing in computer science at the local public university. Last term, I had 75 students for "Systems Programming", and we reach a point about 2 weeks from the end where the topics become more or less optional, because the students have already been told the things necessary for all of the programming assignments. This time I had decided to go a bit beyond my own familiarity and lecture on file locking, down to mandatory locks. Naturally, wanting to get the details right, I did some browsing of documentation. It seems the Stevens & Rago text that I'm using has a pretty good section on file locking in the Advanced I/O chapter, and it agreed with what I had expected well enough. But I found a reference to this file mentioned above, and was shocked to find it began with a warning to avoid this feature. It seemed it was like the BUGS section of the linux man page for the gets() function: do not use gets. I gave up on this topic, but told my students about it. Here is the section of concern: > 15 April 1996 > (Updated September 2007) > > 0. Why you should avoid mandatory locking > ----------------------------------------- > > The Linux implementation is prey to a number of difficult-to-fix race > conditions which in practice make it not dependable: > > - The write system call checks for a mandatory lock only once > at its start. It is therefore possible for a lock request to > be granted after this check but before the data is modified. > A process may then see file data change even while a mandatory > lock was held. > - Similarly, an exclusive lock may be granted on a file after > the kernel has decided to proceed with a read, but before the > read has actually completed, and the reading process may see > the file data in a state which should not have been visible > to it. > - Similar races make the claimed mutual exclusion between lock > and mmap similarly unreliable. But it nagged at me. For one thing, it seems pretty horrible to provide a fix for a synchronization feature that introduces race conditions. UGH. Moreover, it doesn't seem hard to fix: I can think of two approaches that both seem workable: 1) Make mandatory locks mandatory: that is, disallow any file operation on a section of the file that is not locked by the invoking process. 2) Actually lock any such section of the file on behalf of the process, and release the lock when done. Both have some details to be worked out, but it doesn't strike me as anything like impossible. But I'm not the only guy on the planet who has done stuff like this before, but here's this warning that's been there in one form or another for at least 15 years, and the feature has not been fixed. What's wrong with this picture? Does nobody in his right mind use mandatory locking? Is the entire universe of competent programmers too busy with something else? I had to think things through, which had to wait for the end of the term. First, my impression of the relevant history is that advisory locks were upgraded to mandatory to deal with the possibility of a race with a program that was not properly locking a file before access. The race conditions in mandatory locking arise only in the same circumstances -- a program is issuing file operations without owning a lock. Is this a legitimate concern? The fcntl() locks were introduced to support database operations. In most databases I've seen deployed, system administrators arrange to protect the database files from access other than through the database. So while there is certainly a lot of bad code out there, I would expect the database engine itself to do proper locking on all operations, or else that the database will be heaped with scorn and promptly thrown away. Likewise system admins who don't protect their crucial files should be treated similarly. It is true that there's a lot of bad code out there, but any project that is using locks at all is showing some effort to "get it right", and it should be easy to make the locking easily verifiable. Even advisory locks should be sufficient if all operations are performed under such a lock. So here's the question: This short bit of documentation prevented my class from hearing about an important feature of Unix OSen. I think something should be done, but I'm not sure just what. The likely candidates are: 1) Fix that section 0 so it tells the whole truth, and change its heading to something like "Cautions and concerns to observe when using advisory or mandatory locks." 2) Fix the race conditions and ditch section 0, using some method -- maybe one of my suggestions above. 3) Somebody points out that I've misunderstood the situation, proves it, and tells me to go away. As things now stand, I'm upset that section 0 exists in the current form. I only hope I'm the only fool who got misled by it. I eagerly await reactions and advice. -- Kevin O'Gorman, PhD

3 2

A query on GARP updates
by Sowmya Sridharan March 30, 2011

March 30, 2011

Hi All, I am having a scenario wherein an IP address is transferred from one processor to another in case of a failure. These two processors are in communication with a central server, and frequently send out GARPs to update their details. Consider the processors X and Y which report to server Z. Processor X had the IP, and sent out a GARP at 't' second. The server Z updated the ip and mac addresses of processor X. Processor X rebooted immediately, and therefore the ip address got transferred to processor Y within 300-400 milliseconds. Now processor Y sends out a GARP immediately within 't+1' second, and since the interval has not crossed 1 second threshold, this GARP is ignored by the server. Hence there is a loss of traffic until the ARP cache is refreshed in the server, and the older entry is deleted, before the new request is considered. This happens due to a condition specified in net/ipv4/arp.c /* If several different ARP replies follows back-to-back, use the FIRST one. It is possible, if several proxy agents are active. Taking the first reply prevents arp trashing and chooses the fastest router. */ override = time_after(jiffies, n->updated + n->parms->locktime); ==============> n->params->locktime being one second /* Broadcast replies and request packets do not assert neighbour reachability. */ if (arp->ar_op != htons(ARPOP_REPLY) || skb->pkt_type != PACKET_HOST) state = NUD_STALE; neigh_update(n, sha, state, override ? NEIGH_UPDATE_F_OVERRIDE : 0); neigh_release(n); The above condition is for ignoring the arps from proxies, but in my case, the GARPs which is not from a proxy are also ignored. I think this condition is breaking the functionality under the scenario I explained. Or is there any other reason for this condition, and I am missing it? P.S: I came across a similar post on the net, but there wasn't any solution provided :( Regards, Sowmya =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

1 0

Re: Kernelnewbies Digest, Vol 4, Issue 41
by solmac john March 29, 2011

March 29, 2011

Thanks for reply I am looking memory compaction support on arm. compaction which is hugtlb dependent. does hugetlb supports arm if not then why Thanks, Solmac On Sun, Mar 27, 2011 at 9:30 PM, <kernelnewbies-request(a)kernelnewbies.org>wrote: > Send Kernelnewbies mailing list submissions to > kernelnewbies(a)kernelnewbies.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > or, via email, send a message with subject or body 'help' to > kernelnewbies-request(a)kernelnewbies.org > > You can reach the person managing the list at > kernelnewbies-owner(a)kernelnewbies.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Kernelnewbies digest..." > > > Today's Topics: > > 1. Re: Regarding Hugetlbfs (Rik van Riel) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 27 Mar 2011 09:56:13 -0400 > From: Rik van Riel <riel(a)surriel.com> > Subject: Re: Regarding Hugetlbfs > To: kernelnewbies(a)kernelnewbies.org > Message-ID: <4D8F41FD.3000702(a)surriel.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 03/24/2011 06:55 AM, solmac john wrote: > > > I am having the following query regarding Huge pages and hugetlbfs. > > 1-> How Hugetlbfs is dependent on hardware ? > > Hugetlbfs needs two things: > 1) the hardware supports large pages, simultaneously running > with normal sized pages > 2) someone wrote the hugetlbfs architecture dependent code > for that hardware > > > 2-> Huge pages which is architecture dependent and ARM arm > > architecture supports Tiny, small and large pages will it support > > hugetlbfs if not then why ? > > That I don't know. Does ARM support running with normal and > large pages simultaneously? > > -- > All rights reversed. > > > > ------------------------------ > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies(a)kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > End of Kernelnewbies Digest, Vol 4, Issue 41 > ******************************************** >

1 0

libpci for MIPS cross compilation
by Sengottuvelan S March 28, 2011

March 28, 2011

Hi All, I need to use libpci library for cross-compiled for MIPS processor running with linux 2.6.28.9 kernel. I found libpci http://www.kernel.org/pub/software/utils/pciutils/ and I could natively compile it for i386. Is there any procedure to compile this with cross-compiler for MIPS processor. Please throw some light on this if you know this already. -- Regards, S. Sengottuvelan.

1 0

kernel space logging
by Anand Arumugam March 28, 2011

March 28, 2011

Hello all! I would like to know how logging is done while the kernel is booting up. More importantly I am looking for those files in the kernel source that handles the logging part. Also I would like to know what gets logged after the kernel is up and running. Thanks for your time. cheers, -anand.

4 8

kernel optimized for core 2 and later processors Debian/Ubuntu
by Andev March 28, 2011

March 28, 2011

I found some kernel images optimized for core 2 and later processsors. There are also some interactivity related improvements in this image. I thought someone might find them useful. Comments/suggestions welcome :) http://code.google.com/p/linux-kernel-core2/ Regards.

2 3

Regarding Hugetlbfs
by solmac john March 27, 2011

March 27, 2011

Hi All, I am having the following query regarding Huge pages and hugetlbfs. 1-> How Hugetlbfs is dependent on hardware ? 2-> Huge pages which is architecture dependent and ARM arm architecture supports Tiny, small and large pages will it support hugetlbfs if not then why ? can some one guide me thanks in advance Thanks, Akhilesh

2 1

mac address inside eeprom.
by Andrea Gasparini March 25, 2011

March 25, 2011

Hi, My system has an AT24 eeprom (drivers/misc/eeprom/at24.c), that contains the mac adress of my ethernet. Is there a standard way to retrieve data from other devices, that should be used inside drivers? I've already modified both at24.c and the ethernet driver to do so, but I'm wondering if there was already a better way. Thanks, bye! -- -gaspa- ----------------------------------------------- -------- https://launchpad.net/~gaspa --------- ----- HomePage: http://gaspa.yattaweb.it ------

2 2