Hi,
As I have a large quantity of IrDA and wireless patches that
need to get merged in 2.5.X, I thought that I would give a try to the
latest 2.5.51 and its new module support.
This is a short list of problems that I've found with my
setup. They of course will need to be fixed before I can do useful
work on 2.5.X, but I can wait until things get more polished, because
I understand that Rusty has a todo list pretty full.
Have fun, and sorry for the spam...
Jean
--------------------------------------------------------------
Setup :
-----
o kernel 2.5.51 ; SMP
o module-init-tools-0.9.3
o dual PPro 200 MHz, Debian 3.0
Debian Boot :
-----------
o Din't pick up new modutils in the init scripts. Probably
because I used install option 1b in README (/usr/local/sbin).
o Re-install with option 1a (/sbin), works fine.
o Maybe this needs to be in README.
hp100 (my Ethernet card) :
------------------------
o When loading, module options (various hp100_XXX) are
ignored, however they are necessary to get the card up and
running. So, no network :-(
o Seems that the section handling "param" support in the
kernel is #if 0, so probably not finished up yet. I see that it's on
your TODO list.
o No further tests.
Wavelan ISA :
-----------
o Didn't try old wavelan ISA card because I know that it
requires module parameters as well.
Pcmcia and airo_cs :
------------------
o Loads with error below, airo_cs driver is functional.
o i82365 cannot be unloaded, it's unsafe.
o removal of airo_cs : "Uninitialised timer!/nThis is a
warning. Your computer is OK". Call trace on demand. Also, the module
airo not removed (probably due to problem with airo_cs).
o re-insertion of the card : nothing happens. No messages.
o After reboot, /etc/init.d/pcmcia stop -> same thing + script
hang + a few [kmodule1? <defunct>]. This prevent the computer to
reboot or shutdown properly (== fsck at next boot).
I never had those problem before, this driver has always been
rock solid, and I don't really know where to start... I don't use
auto_wep, so the only timer used in airo is &link->release, which is
Pcmcia stuff. This is where the lack of Pcmcia maintainer in 2.5.X
makes me really nervous.
Pcmcia and orinoco_cs :
---------------------
o Same deal as airo_cs, fail removal of card. Actually, the
whole computer did lock-up.
o Definitely looks like a generic Pcmcia problem (BTW, both
cards are 16 bits, as well as the bridge).
IrDA :
----
o Try irtty and irda-usb drivers, both load fine, as well as
the Linux-IrDA stack, only with message below. Basic IrDA
communication test passed.
o af_irda, irda-usb & irtty-sir are "unsafe". I tracked that
down to the use of MOD_INC_USE_COUNT. The header file module.h give
hints on how I should convert that to the new world (use
try_module_get), however your FAQ seems to say something else (just
remove them, they are useless). I'm quite confused, because those
MOD_INC_USE_COUNT have a definite purpose... I would appreciate more
guidance.
o When/if I will understand what's the best course of action,
I can fix those myself.
o Also, maybe you should put a pointer to your FAQ in the
usual places (like in the README of module-init-tools-0.9.3), because
it's only because I knew it existed that I've found it.
In message <[email protected]> you write:
> Hi,
Hi Jean!
Thanks for the report.
> Debian Boot :
> -----------
> o Din't pick up new modutils in the init scripts. Probably
> because I used install option 1b in README (/usr/local/sbin).
> o Re-install with option 1a (/sbin), works fine.
> o Maybe this needs to be in README.
Debian have picked up the module-init-tools, so although they're a bit
lagged as I type this, I expect this to become a less common occurrance.
> hp100 (my Ethernet card) :
> ------------------------
> o When loading, module options (various hp100_XXX) are
> ignored, however they are necessary to get the card up and
> running. So, no network :-(
> o Seems that the section handling "param" support in the
> kernel is #if 0, so probably not finished up yet. I see that it's on
> your TODO list.
No, it's finished, it's just not merged 8(. Testers welcome! See:
http://www.kernel.org/pub/linux/kernel/people/rusty/modules/2.5.51.patches.gz
> Pcmcia and airo_cs :
> ------------------
> o Loads with error below, airo_cs driver is functional.
> o i82365 cannot be unloaded, it's unsafe.
> o removal of airo_cs : "Uninitialised timer!/nThis is a
> warning. Your computer is OK". Call trace on demand. Also, the module
> airo not removed (probably due to problem with airo_cs).
That, in itself, should be harmless.
> o re-insertion of the card : nothing happens. No messages.
> o After reboot, /etc/init.d/pcmcia stop -> same thing + script
> hang + a few [kmodule1? <defunct>]. This prevent the computer to
> reboot or shutdown properly (== fsck at next boot).
Wierd. The PCMCIA scripts make assumptions about layout of
/lib/modules/`uname -r` which was broken by the removal of the
directory hierarchy. It's not the only thing (mkinitrd also wants
this). While relying on the layout of the kernel source tree is
broken, no better alternatives have some up, so this is queued to be
reverted once I test that it doesn't break the current tools (which
*should* handle it).
There is a known bug where an *old* rmmod will hang (it has the effect
of "rmmod --wait": I have a patch to differentiate the two
effectively, but it requires everyone to upgrade to 0.9 or above,
which they have probably done by now).
> o af_irda, irda-usb & irtty-sir are "unsafe". I tracked that
> down to the use of MOD_INC_USE_COUNT. The header file module.h give
> hints on how I should convert that to the new world (use
> try_module_get), however your FAQ seems to say something else (just
> remove them, they are useless). I'm quite confused, because those
> MOD_INC_USE_COUNT have a definite purpose... I would appreciate more
> guidance.
Looking at these files:
idra-usb.c: add "netdev->owner = THIS_MODULE;" and get rid of the
MOD_INC_USE_COUNT.
irtty-sir.c: The ldisc code needs an owner field, and it needs to use
it. Until then, this warning is best left where it is.
af_irda: The caller needs to do something here, too. Dave?
> o When/if I will understand what's the best course of action,
> I can fix those myself.
Well, you can rmmod -f in the meantime.
> o Also, maybe you should put a pointer to your FAQ in the
> usual places (like in the README of module-init-tools-0.9.3), because
> it's only because I knew it existed that I've found it.
Hmm the contents of the FAQ are still in flux, which is why it's not
published. The init stuff is still up for debate.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
On Wed, Dec 11, 2002 at 07:34:53PM +1100, Rusty Russell wrote:
> In message <[email protected]> you write:
> > Hi,
>
> Hi Jean!
>
> Thanks for the report.
Yes, for a change I'm trying to be helpful ;-)
> > Debian Boot :
> > -----------
> > o Din't pick up new modutils in the init scripts. Probably
> > because I used install option 1b in README (/usr/local/sbin).
> > o Re-install with option 1a (/sbin), works fine.
> > o Maybe this needs to be in README.
>
> Debian have picked up the module-init-tools, so although they're a bit
> lagged as I type this, I expect this to become a less common occurrance.
I'm using stable, which mean that I'm lagging behind Debian...
> > Pcmcia and airo_cs :
> > ------------------
> > o Loads with error below, airo_cs driver is functional.
> > o i82365 cannot be unloaded, it's unsafe.
> > o removal of airo_cs : "Uninitialised timer!/nThis is a
> > warning. Your computer is OK". Call trace on demand. Also, the module
> > airo not removed (probably due to problem with airo_cs).
>
> That, in itself, should be harmless.
Yes, but this is new and I don't really like it. I suspect
something is wrong in the Pcmcia code itself. Last I tried was 2.5.46
and I see some suspicious init_timer() added where I would not expect,
and some missing where they would be needed.
Hum... Who is in charge ?
> > o re-insertion of the card : nothing happens. No messages.
> > o After reboot, /etc/init.d/pcmcia stop -> same thing + script
> > hang + a few [kmodule1? <defunct>]. This prevent the computer to
> > reboot or shutdown properly (== fsck at next boot).
>
> Wierd. The PCMCIA scripts make assumptions about layout of
> /lib/modules/`uname -r` which was broken by the removal of the
> directory hierarchy. It's not the only thing (mkinitrd also wants
> this). While relying on the layout of the kernel source tree is
> broken, no better alternatives have some up, so this is queued to be
> reverted once I test that it doesn't break the current tools (which
> *should* handle it).
I personally believe the timer thingy is important and cause
of problems.
> There is a known bug where an *old* rmmod will hang (it has the effect
> of "rmmod --wait": I have a patch to differentiate the two
> effectively, but it requires everyone to upgrade to 0.9 or above,
> which they have probably done by now).
> > o af_irda, irda-usb & irtty-sir are "unsafe". I tracked that
> > down to the use of MOD_INC_USE_COUNT. The header file module.h give
> > hints on how I should convert that to the new world (use
> > try_module_get), however your FAQ seems to say something else (just
> > remove them, they are useless). I'm quite confused, because those
> > MOD_INC_USE_COUNT have a definite purpose... I would appreciate more
> > guidance.
>
> Looking at these files:
>
> idra-usb.c: add "netdev->owner = THIS_MODULE;" and get rid of the
> MOD_INC_USE_COUNT.
This was the easy one.
> irtty-sir.c: The ldisc code needs an owner field, and it needs to use
> it. Until then, this warning is best left where it is.
Ok.
> af_irda: The caller needs to do something here, too. Dave?
Ok.
> Rusty.
Thanks a lot !
Jean
On Wed, Dec 11, 2002 at 07:34:53PM +1100, Rusty Russell wrote:
> In message <[email protected]> you write:
> > o af_irda, irda-usb & irtty-sir are "unsafe". I tracked that
> > down to the use of MOD_INC_USE_COUNT. The header file module.h give
> > hints on how I should convert that to the new world (use
> > try_module_get), however your FAQ seems to say something else (just
> > remove them, they are useless). I'm quite confused, because those
> > MOD_INC_USE_COUNT have a definite purpose... I would appreciate more
> > guidance.
>
> Looking at these files:
>
> idra-usb.c: add "netdev->owner = THIS_MODULE;" and get rid of the
> MOD_INC_USE_COUNT.
Incorrect but close: one uses SET_MODULE_OWNER(netdev) for this.
In message <[email protected]> you write:
> On Wed, Dec 11, 2002 at 07:34:53PM +1100, Rusty Russell wrote:
> > idra-usb.c: add "netdev->owner = THIS_MODULE;" and get rid of the
> > MOD_INC_USE_COUNT.
>
> Incorrect but close: one uses SET_MODULE_OWNER(netdev) for this.
BTW, what *is* the purpose of that macro, other than obfuscation?
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
In message <[email protected]> you write:
> On Wed, Dec 11, 2002 at 07:34:53PM +1100, Rusty Russell wrote:
> > > o removal of airo_cs : "Uninitialised timer!/nThis is a
> > > warning. Your computer is OK". Call trace on demand. Also, the module
> > > airo not removed (probably due to problem with airo_cs).
> >
> > That, in itself, should be harmless.
>
> Yes, but this is new and I don't really like it. I suspect
> something is wrong in the Pcmcia code itself. Last I tried was 2.5.46
> and I see some suspicious init_timer() added where I would not expect,
> and some missing where they would be needed.
> Hum... Who is in charge ?
Well, Andrew Morton made the change that required timers to be
initialized, and the check which locates ones which are not. As to
who is responsible for airo_cs, I'm guessing Ben Reed, as author.
> I personally believe the timer thingy is important and cause
> of problems.
I disagree: the warning is supposed to silently fix it up.
> Thanks a lot !
>
> Jean
That's what I'm here for,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Rusty Russell wrote:
>
> In message <[email protected]> you write:
> > On Wed, Dec 11, 2002 at 07:34:53PM +1100, Rusty Russell wrote:
> > > > o removal of airo_cs : "Uninitialised timer!/nThis is a
> > > > warning. Your computer is OK". Call trace on demand. Also, the module
> > > > airo not removed (probably due to problem with airo_cs).
> > >
> > > That, in itself, should be harmless.
> >
> > Yes, but this is new and I don't really like it. I suspect
> > something is wrong in the Pcmcia code itself. Last I tried was 2.5.46
> > and I see some suspicious init_timer() added where I would not expect,
> > and some missing where they would be needed.
> > Hum... Who is in charge ?
>
> Well, Andrew Morton made the change that required timers to be
> initialized, and the check which locates ones which are not. As to
> who is responsible for airo_cs, I'm guessing Ben Reed, as author.
wakes up.
> > I personally believe the timer thingy is important and cause
> > of problems.
>
> I disagree: the warning is supposed to silently fix it up.
>
yes. It goes like this:
1: The new super-scalable SMP timers code had a locking problem which
made 8-ways go oops.
2: The fix was to add a spinlock to struct timer_list.
3: spinlocks need to be initialised.
3a: struct timer_list needs to be initialised.
This is a problem, because it has traditionally been the case that
an all-zeroes struct timer_list is "initialised". That is no longer
the case. All timers must now be prepared with init_timer() or
TIMER_INITIALIZER()
So debugging code was added to the timer layer to detect when someone
passes an uninitialised timer into the core timer functions. That debug
code generates a warning, a backtrace and then initialises the timer
for you, so things run happily.
I did an audit and fixed up probably a hundred or so uninitialised timers,
but there will be a few leftovers.
The intent is that people will report these leftovers, they get fixed up
and then one day we pull out the debug code.
Sorry, I missed the original message.
As far as the timer message from airo_cs when you try
to remove the card: This executes some code that is
pretty much common to all PCMCIA drivers that sets a
timer to do the actual driver removal asynchronous to
the REMOVAL event. You can find it in airo_cs.c.
I'll update the driver.
I haven't tried the recent 2.5 kernels, so I check if
I see anything.
ben
In relation to:
--- Rusty Russell <[email protected]> wrote:
> In message
> <[email protected]> you
> write:
> > On Wed, Dec 11, 2002 at 07:34:53PM +1100, Rusty
> Russell wrote:
> > > > o removal of airo_cs : "Uninitialised
> timer!/nThis is a
> > > > warning. Your computer is OK". Call trace on
> demand. Also, the module
> > > > airo not removed (probably due to problem with
> airo_cs).
> > >
> > > That, in itself, should be harmless.
> >
> > Yes, but this is new and I don't really like it.
> I suspect
> > something is wrong in the Pcmcia code itself. Last
> I tried was 2.5.46
> > and I see some suspicious init_timer() added where
> I would not expect,
> > and some missing where they would be needed.
> > Hum... Who is in charge ?
>
> Well, Andrew Morton made the change that required
> timers to be
> initialized, and the check which locates ones which
> are not. As to
> who is responsible for airo_cs, I'm guessing Ben
> Reed, as author.
>
On Thu, Dec 12, 2002 at 01:51:26PM -0800, Benjamin Reed wrote:
> Sorry, I missed the original message.
>
> As far as the timer message from airo_cs when you try
> to remove the card: This executes some code that is
> pretty much common to all PCMCIA drivers that sets a
> timer to do the actual driver removal asynchronous to
> the REMOVAL event. You can find it in airo_cs.c.
> I'll update the driver.
>
> I haven't tried the recent 2.5 kernels, so I check if
> I see anything.
>
> ben
Well, I said earlier that it was a generic Pcmcia problem,
because I have the same problem with the orinoco driver. But, we need
to separate the noise from the problem (Andrew says that the timer
is only a harmless warning).
I personally never liked the release timer, and I personally
avoided it in the wavelan_cs driver for a long time (before David
forced me to it). But, anyway at some point this will need to be
investigated.
Have fun..
Jean