Aargh. Now if I had actually *read* your message I'd have picked that up.
Well, it's not maybe some *other* module that gets left behind in
/lib/modules/$VERSION? No, that doesn't make too much sense. That
doesn't gel with the crashes happening from the time you load *your*
module.
Uh, could it maybe be (gasp!) a *bug* in your module? Maybe some
assumption your code is making is being invalidated by a new! improved!
optimization in GCC 3.x? I know my module ha[ds] bugs...
Although... I must say that ever since I recompiled 2.4.18 with 3.2.x
(now 3.2.3), my machine seems somewhat less stable. (I think) I *had* to
reboot yesterday after just 16 days' uptime after X or something else
with the keyboard went berserk. But I'm not quite ready yet to "blame"
GCC for that.
> On Fri, 30 May 2003, Bernd Jendrissek wrote:
>
> > Not *exactly* on-topic for gcc@gcc.gnu.org I suppose, but here goes.
> >
> > [Cc'ed to linux-kernel@vger.kernel.org]
> >
> > On Fri, May 30, 2003 at 09:26:51AM -0600, Kendrick Hamilton wrote:
> > > I have a module for a custom developped PCI card. The device
> > > driver is written for the Linux 2.4 series kernels. When I build the
> > > module and the Linux kernel with gcc-2.95.3, the module installs
> > > correctly. When I build the module and the Linux kernel with gcc-3.2.3
> > > (also other gcc-3.2.x), the module installs but the Linux kernel crashes
> > > in random places outside of the module. Do you have any suggestions of
> > > what to look for? I can email you the complete module source code. I have
> > > not tried gcc-3.3 because I cannot compile the current Linux kernel with
> > > it (there is a known bug that is being fixed and should be out in
> > > Linux-2.4.21).
> >
> > Been there, done that, got the T-shirt. I was lucky: while my module
> > installed, it broke in a fairly harmless way. (It just didn't work; it
> > didn't screw with my system.)
> >
> > If you look at linux/include/linux/spinlock.h, you'll see:
> >
> > /*
> > * Your basic spinlocks, allowing only a single CPU anywhere
> > *
> > * Most gcc versions have a nasty bug with empty initializers.
> > */
> > #if (__GNUC__ > 2)
> > typedef struct { } spinlock_t;
> > #define SPIN_LOCK_UNLOCKED (spinlock_t) { }
> > #else
> > typedef struct { int gcc_is_buggy; } spinlock_t;
> > #define SPIN_LOCK_UNLOCKED (spinlock_t) { 0 }
> > #endif
> >
> > There are a couple of spinlock_t's (directly or through other structs) in
> > the task_struct. So when your module accesses parts of the "current"
> > task_struct beyond the first spinlock_t, you better hope it's reading and
> > not writing (which was the case with my module).
> >
> > I bet your module modifies "current".
> >
> > Hmm, actually I thought the kernel had a mechanism to prevent a GCC 3.x
> > module from being loaded into a GCC 2.x kernel and vice versa?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/