Race condition in module load causing undefined symbols
in [Kernel]
|
Next: Am1771 wireless driver?
From: Steve Lord on 14 Jun 2005 15:30 Thanks Prarit, I updated mkinitrd from 4.1.18 to 4.2.15 and udev from 039 to 058. This appears to have cured it on my work machine, I will try the other box later. Looking at Documentation/Changes, which appears to still be the official repository for required tool versions, it seems somewhat dated, and makes no mention of mkinitrd version requirements. Steve Prarit Bhargava wrote: > Colleagues, > > (Copied and edited from a post I made on linux-hotplug-devel last month.) > > I've privately emailed Steve with a quick-and-dirty solution for the > problems he was experiencing with the system boot. I wasn't sure if he > was having the same problems I've had with 2.6.12 and old packages but > it looks like he was. > > I'm surprised we haven't had more people on this list wondering about > the strange behaviour of their initrd/initramfs :) . > > When I looked at the original output Steve had posted I noticed that it > looked like drivers were attempting to load at the same time and because > of this he eventually hit an oops. I (and an engineer from another > company working on another arch) have hit the same problem due to the > requirements of our current work. > > (Unfortunately, I'm more familiar with RedHat/Fedora than I am with > other distro's -- please bear with me.) > > The issue is that David Howells posted a patch that changed the > behaviour of kallsyms/insmod/rmmod sometime ago. The patch *is correct* > in what it does, however, the patch requires that /sbin/sh must be aware > of pid returns by wait(). > > http://lkml.org/lkml/2005/1/17/132 > > There are two fixes that I'm aware of, and depending on what you're > doing they are both "correct" (although in the case of developing in > 2.6.12, IMO, you > _must_ do the latter). > > The first fix is for the situation where you're developing for a > specific distribution. If this is the case, then you should back out > the patch above and continue moving forward. > > The second fix, and again you must do this if you're developing 2.6.12, > is to *update the mkinitrd package* which has a new version of /bin/sh. > > P. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Hellwig on 14 Jun 2005 15:40 On Tue, Jun 14, 2005 at 02:27:29PM -0500, Steve Lord wrote: > Thanks Prarit, > > I updated mkinitrd from 4.1.18 to 4.2.15 and udev from 039 to 058. > This appears to have cured it on my work machine, I will try the > other box later. > > Looking at Documentation/Changes, which appears to still be the > official repository for required tool versions, it seems somewhat > dated, and makes no mention of mkinitrd version requirements. One of the reasons for that is that there is not generic mkinitrd. Every distribution has it's own variant. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pozsár Balázs on 14 Jun 2005 17:00 On Tue, Jun 14, 2005 at 06:56:22PM +0200, Andi Kleen wrote: > Steve Lord <lord(a)xfs.org> writes: > > > > So is this some P4 specific optimization which is not working as > > intended? > > The only pentium specific optimizations that are enabled by MPENTIUM4 > is to tell the compiler to compile for pentium4 and a few settings > in arch/i386/Kconfig. > > You could enable/disable these individually and see if you can track > it down with a binary search. > > Most of this stuff should be fairly harmless though and be only > microoptimizations; I cannot see how they should cause user visible > races. I am 100% sure this is not a P4 optimization problem since I compiled my kernel for i586 and saw the same problem. -- pozsy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pozsár Balázs on 14 Jun 2005 17:10 On Tue, Jun 14, 2005 at 02:23:04PM -0400, Prarit Bhargava wrote: > The second fix, and again you must do this if you're developing 2.6.12, is > to *update the mkinitrd package* which has a new version of /bin/sh. This sounds insane to me. I am using bash in my initrd, does this mean that every shell and whatever has to be updated? Exactly what modifications has to be made? -- pozsy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pozsár Balázs on 15 Jun 2005 07:40
On Wed, Jun 15, 2005 at 07:28:00AM -0400, Prarit Bhargava wrote: > Pozsýr Balýzs wrote: > >On Tue, Jun 14, 2005 at 02:23:04PM -0400, Prarit Bhargava wrote: > > > >>The second fix, and again you must do this if you're developing 2.6.12, > >>is to *update the mkinitrd package* which has a new version of /bin/sh. > > > > > >This sounds insane to me. I am using bash in my initrd, does this mean > >that every shell and whatever has to be updated? Exactly what > >modifications has to be made? > > > > > > If you're using bash, I would suggest starting with an update of the bash > package. Well, I'm using 3.0 and afaik there's no newer version, but I don't think this is the problem either. Exactlywhat modifications have to be made and to what to work around this kernel regression? -- pozsy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |