From: "K.R. Foley" <kr@cybsft.com>
To: Steve Lord <lord@xfs.org>
Cc: Andrew Morton <akpm@osdl.org>,
pozsy@uhulinux.hu, linux-kernel@vger.kernel.org,
rusty@rustcorp.com.au
Subject: Re: Race condition in module load causing undefined symbols
Date: Tue, 14 Jun 2005 10:33:38 -0500 [thread overview]
Message-ID: <42AEF8D2.7070507@cybsft.com> (raw)
In-Reply-To: <42AEDCFB.8080002@xfs.org>
Steve Lord wrote:
> Andrew Morton wrote:
>
>> Stephen Lord <lord@xfs.org> wrote:
>>
>>> Pozsár Balázs wrote:
>>> > On Sat, Jun 11, 2005 at 08:23:20AM -0500, Steve Lord wrote:
>>> > >>I think this is not actually module loading itself, but a problem
>>> >>between the fork/exec/wait code in nash and the kernel.
>>> > > > I do not use nash, only bash, so this is not a nash-specific
>>> issue.
>>> > >
>>> I disabled hyperthreading and things started working, so are there any
>>> HT related scheduling bugs right now?
>>
>>
>>
>> There haven't been any scheduler changes for some time. There have
>> been a
>> few low-level SMT changes I think.
>>
>> Are you able to identify which kernel version broke it?
>>
>
> Still have not narrowed this down too far, disabling SMT made no
> difference, disabling SMP did, which I was expecting.
>
> Steve
>
I initially saw this with 2.6.12-rc1 and every version up through rc3. I
haven't tried with later versions. :-/ I initially reported here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=111235814529008&w=2
The way that I got around it was to compile in my aic7xxx driver instead
of making it a module. I have also recently received an email from
someone saying that disabling module unloading would also solve it. That
very well may be true since I did run into another booting problem
(2.6.12-rc5) that disabling module unloading fixed :-/ I haven't had a
chance to go back and check this out though.
So to summarize: I have a dual 933 with aic7xxx compiled in to get
passed the problem described above. I have a dual 2.6 w/HT that I have
disabled module unloading to get passed another boot condition.
--
kr
next prev parent reply other threads:[~2005-06-14 15:41 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-10 14:03 Race condition in module load causing undefined symbols Stephen Lord
2005-06-10 18:25 ` Andrew Morton
2005-06-10 19:06 ` Steve Lord
2005-06-11 3:30 ` Stephen Lord
2005-06-11 8:26 ` Pozsár Balázs
2005-06-11 13:23 ` Steve Lord
2005-06-11 15:05 ` Pozsár Balázs
2005-06-11 17:56 ` Stephen Lord
2005-06-11 19:00 ` Andrew Morton
2005-06-11 19:08 ` Pozsár Balázs
2005-06-11 20:09 ` Steve Lord
2005-06-11 20:18 ` Pozsár Balázs
2005-06-14 13:34 ` Steve Lord
2005-06-14 15:33 ` K.R. Foley [this message]
2005-06-14 15:36 ` K.R. Foley
2005-06-14 16:38 ` Steve Lord
2005-06-14 16:56 ` Andi Kleen
2005-06-14 17:16 ` Steve Lord
2005-06-14 20:56 ` Pozsár Balázs
2005-06-14 17:10 ` K.R. Foley
2005-06-14 17:39 ` Steve Lord
2005-06-14 18:23 ` Prarit Bhargava
2005-06-14 19:27 ` Steve Lord
2005-06-14 19:32 ` Christoph Hellwig
2005-06-14 20:59 ` Pozsár Balázs
2005-06-15 11:28 ` Prarit Bhargava
2005-06-15 11:34 ` Pozsár Balázs
2005-06-15 11:35 ` Prarit Bhargava
2005-06-15 11:43 ` Pozsár Balázs
2005-06-15 12:33 ` Stephen Lord
2005-07-28 19:42 ` David Howells
2005-06-12 6:49 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42AEF8D2.7070507@cybsft.com \
--to=kr@cybsft.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lord@xfs.org \
--cc=pozsy@uhulinux.hu \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.