I issued a reboot command under -mm4 and received the following oops some
time after the "Sending all processes the TERM signal" message. This
message did not make it into syslog. Following this oops are one
"sleeping function called from invalid context at
include/linux/rwsem.h:43" and one "bad: scheduling while atomic!" message.
Then I get the message "no more processes left in this runlevel", after
which processing stops. Nothing further appears to happen, but I can
still use <SHIFT><PAGE [UP|DOWN]> to scroll screen.
I've typed this in by hand so there may be errors. This machine is a
Presario 12XL325 laptop and does not have a serial port to use as a remote
console. This oops is reproducable, but does not happen on every reboot.
Unable to handle kernel paging request at virtual address c778c950
printing eip:
c0130555
*pde = 0001a063
*pte = 0778c000
Oops: 0000 (#1]
PREEMPT DEBUG_PAGEALLOC
CPU: 0
EIP: 0060:[<c0130555>] Not tainted VLI
EFLAGS: 00010086
EIP is at __tasklet_schedule+0x35/0x50
eax: c6e9c000 ebx: 00000046 ecx: 00000186 edx: c778c950
esi: 00000000 edi: c6eb6950 ebp: c6e9de74 esp: c6e9de70
ds: 007b es: 007b ss: 0068
Process S01reboot (pid: 3322, threadinfo=c6e9c000 task=c6eb6950)
Stack: 00000000 c6e9dea8 c012267e 00000000 00000000 c2213fc4 c6e9dec0
13aaa68c
00895486 3f33cb49 00001640 00000000 c6e9c000 401610c8 c6e9dec0
c012212c
00000000 00000000 c2117950 c6eb6fe0 c6e9df20 c0128880 00000000
01200011
Call Trace:
[<c012267e>] scheduler_tick+0x6e/0x6b0
[<c012212c>] sched_fork+0xbc/0xe0
[<c0128880>] copy_process+0x5e0/0xfe0
[<c01292cd>] do_fork+0x4d/0x1c1
[<c013bba7>] sigprocmask+0xf7/0x2a0
[<c017b54a>] generic_file_llseek+0x3a/0xf0
[<c017bc90>] sys_llseek+0xd0/0x100
[<c0109cef>] sys_clone+0x3f/0x50
[<c02ec24a>] sysenter_past_esp+0x43/0x65
Code: 0a 3c c0 89 10 83 0d 20 0a 3c c0 20 a3 00 0a 3c c0 b8 00 e0 ff ff 21
e0 f7 40 14 00 ff ff 00 75 15 8b 15 40 0b 3c c0 85 d2 74 0b <8b> 02 85 c0
75 0a 90 8d 74 26 00 53 9d 5b 5d c3 89 d0 e8 b4 1a
<6>note: S01reboot[2352] exited with preempt_count 1
On Sat, 17 Jan 2004, Thomas Molina wrote:
> I issued a reboot command under -mm4 and received the following oops some
> time after the "Sending all processes the TERM signal" message. This
> message did not make it into syslog. Following this oops are one
> "sleeping function called from invalid context at
> include/linux/rwsem.h:43" and one "bad: scheduling while atomic!" message.
> Then I get the message "no more processes left in this runlevel", after
> which processing stops. Nothing further appears to happen, but I can
> still use <SHIFT><PAGE [UP|DOWN]> to scroll screen.
>
> I've typed this in by hand so there may be errors. This machine is a
> Presario 12XL325 laptop and does not have a serial port to use as a remote
> console. This oops is reproducable, but does not happen on every reboot.
>
> Unable to handle kernel paging request at virtual address c778c950
> printing eip:
> c0130555
> *pde = 0001a063
> *pte = 0778c000
> Oops: 0000 (#1]
> PREEMPT DEBUG_PAGEALLOC
> CPU: 0
> EIP: 0060:[<c0130555>] Not tainted VLI
> EFLAGS: 00010086
> EIP is at __tasklet_schedule+0x35/0x50
> eax: c6e9c000 ebx: 00000046 ecx: 00000186 edx: c778c950
> esi: 00000000 edi: c6eb6950 ebp: c6e9de74 esp: c6e9de70
> ds: 007b es: 007b ss: 0068
> Process S01reboot (pid: 3322, threadinfo=c6e9c000 task=c6eb6950)
> Stack: 00000000 c6e9dea8 c012267e 00000000 00000000 c2213fc4 c6e9dec0
> 13aaa68c
> 00895486 3f33cb49 00001640 00000000 c6e9c000 401610c8 c6e9dec0
> c012212c
> 00000000 00000000 c2117950 c6eb6fe0 c6e9df20 c0128880 00000000
> 01200011
> Call Trace:
> [<c012267e>] scheduler_tick+0x6e/0x6b0
> [<c012212c>] sched_fork+0xbc/0xe0
> [<c0128880>] copy_process+0x5e0/0xfe0
> [<c01292cd>] do_fork+0x4d/0x1c1
> [<c013bba7>] sigprocmask+0xf7/0x2a0
> [<c017b54a>] generic_file_llseek+0x3a/0xf0
> [<c017bc90>] sys_llseek+0xd0/0x100
> [<c0109cef>] sys_clone+0x3f/0x50
> [<c02ec24a>] sysenter_past_esp+0x43/0x65
>
> Code: 0a 3c c0 89 10 83 0d 20 0a 3c c0 20 a3 00 0a 3c c0 b8 00 e0 ff ff 21
> e0 f7 40 14 00 ff ff 00 75 15 8b 15 40 0b 3c c0 85 d2 74 0b <8b> 02 85 c0
> 75 0a 90 8d 74 26 00 53 9d 5b 5d c3 89 d0 e8 b4 1a
> <6>note: S01reboot[2352] exited with preempt_count 1
I was getting something like that on reboot a few days ago, I think it
was with 2.6.1-mm2. I had to move on before debugging it fully, but
the impression I got (maybe vile calumny, sue me Rusty) was that the
new kthread_create for 2.6.1-mm's ksoftirqd was leaving it vulnerable
to shutdown kill, whereas other things (RCU in my traces) still needed
it around and assumed its task address still valid.
Hope this helps instead of misleading,
Hugh
Hugh Dickins <[email protected]> wrote:
>
> > Code: 0a 3c c0 89 10 83 0d 20 0a 3c c0 20 a3 00 0a 3c c0 b8 00 e0 ff ff 21
> > e0 f7 40 14 00 ff ff 00 75 15 8b 15 40 0b 3c c0 85 d2 74 0b <8b> 02 85 c0
> > 75 0a 90 8d 74 26 00 53 9d 5b 5d c3 89 d0 e8 b4 1a
> > <6>note: S01reboot[2352] exited with preempt_count 1
>
> I was getting something like that on reboot a few days ago, I think it
> was with 2.6.1-mm2. I had to move on before debugging it fully, but
> the impression I got (maybe vile calumny, sue me Rusty) was that the
> new kthread_create for 2.6.1-mm's ksoftirqd was leaving it vulnerable
> to shutdown kill, whereas other things (RCU in my traces) still needed
> it around and assumed its task address still valid.
Yes. ksoftirqd and the migration threads can now be killed off
with `kill -9'.
In message <[email protected]> you write:
> Yes. ksoftirqd and the migration threads can now be killed off
> with `kill -9'.
Fix below.
Thanks,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Name: Block Signals For Early Kthreads
Author: Rusty Russell
Status: Booted on 2.6.1-bk4
Depends: Hotcpu-New-Kthread/use-kthread-simple.patch.gz
D: Kthreads created at boot before "keventd" are spawned directly.
D: However, this means that they don't have all signals blocked, and
D: hence can be killed. The simplest solution is to always explicitly
D: block all signals in the kthread.
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .29870-linux-2.6.1-mm4/kernel/kthread.c .29870-linux-2.6.1-mm4.updated/kernel/kthread.c
--- .29870-linux-2.6.1-mm4/kernel/kthread.c 2004-01-19 18:12:53.000000000 +1100
+++ .29870-linux-2.6.1-mm4.updated/kernel/kthread.c 2004-01-19 21:45:53.000000000 +1100
@@ -32,12 +32,18 @@ static int kthread(void *_create)
struct kthread_create_info *create = _create;
int (*threadfn)(void *data);
void *data;
+ sigset_t blocked;
int ret = -EINTR;
/* Copy data: it's on keventd's stack */
threadfn = create->threadfn;
data = create->data;
+ /* Block and flush all signals (in case we're not from keventd). */
+ sigfillset(&blocked);
+ sigprocmask(SIG_BLOCK, &blocked, NULL);
+ flush_signals(current);
+
/* OK, tell user we're spawned, wait for stop or wakeup */
__set_current_state(TASK_INTERRUPTIBLE);
complete(&create->started);
In message <[email protected]> you write:
> Hugh Dickins <[email protected]> wrote:
> > I was getting something like that on reboot a few days ago, I think it
> > was with 2.6.1-mm2. I had to move on before debugging it fully, but
> > the impression I got (maybe vile calumny, sue me Rusty) was that the
> > new kthread_create for 2.6.1-mm's ksoftirqd was leaving it vulnerable
> > to shutdown kill, whereas other things (RCU in my traces) still needed
> > it around and assumed its task address still valid.
>
> Yes. ksoftirqd and the migration threads can now be killed off
> with `kill -9'.
"That shouldn't happen".
We block and flush all signals in workqueue.c. How is that kill -9
getting through?
It also implies that previously ksoftirqd and migration threads would
tight spin after kill -9, since they slept with TASK_INTERRUPTIBLE.
Will dig...
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Rusty Russell <[email protected]> writes:
> Migrating to module_param() is the Right Thing here IMHO, which actually
> takes the damn address,
The main problem is that module_parm renames the boot time arguments and
makes them long and hard to remember. E.g. the new argument needed to
make the mouse work on KVMs is mindboogling, could be nearly a Windows
registry entry.
-Andi
In message <[email protected]> you write:
> Rusty Russell <[email protected]> writes:
>
> > Migrating to module_param() is the Right Thing here IMHO, which actually
> > takes the damn address,
>
> The main problem is that module_parm renames the boot time arguments and
> makes them long and hard to remember.
Um, if the module name is neat, and the parameter name is neat, the
combination of the two with a "." between them will be nest.
> E.g. the new argument needed to make the mouse work on KVMs is
> mindboogling, could be nearly a Windows registry entry.
I have no idea what you are talking about. 8(
Please explain,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
On Wed, 21 Jan 2004 15:06:57 +1100, Rusty Russell said:
> > E.g. the new argument needed to make the mouse work on KVMs is
> > mindboogling, could be nearly a Windows registry entry.
>
> I have no idea what you are talking about. 8(
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs
That's the name of a registry entry. I don't think iwe're quite THAT bad. ;)
On Wed, Jan 21, 2004 at 03:06:57PM +1100, Rusty Russell wrote:
> In message <[email protected]> you write:
> > Rusty Russell <[email protected]> writes:
> >
> > > Migrating to module_param() is the Right Thing here IMHO, which actually
> > > takes the damn address,
> >
> > The main problem is that module_parm renames the boot time arguments and
> > makes them long and hard to remember.
>
> Um, if the module name is neat, and the parameter name is neat, the
> combination of the two with a "." between them will be nest.
>
> > E.g. the new argument needed to make the mouse work on KVMs is
> > mindboogling, could be nearly a Windows registry entry.
>
> I have no idea what you are talking about. 8(
Inbetween the module changes and the input changes there was a
situation, where you'd have to pass
psmouse.psmouse_maxproto=imps2
as a kernel argument. This should (I hope so, I have to check) be fixed
now.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Wed, 21 Jan 2004 15:06:57 +1100
Rusty Russell <[email protected]> wrote:
> In message <[email protected]> you write:
> > Rusty Russell <[email protected]> writes:
> >
> > > Migrating to module_param() is the Right Thing here IMHO, which actually
> > > takes the damn address,
> >
> > The main problem is that module_parm renames the boot time arguments and
> > makes them long and hard to remember.
>
> Um, if the module name is neat, and the parameter name is neat, the
> combination of the two with a "." between them will be nest.
Unfortunately we have lots of non neat module names and many previous boot
time arguments note their subsystem which adds even more redundancy.
And you're suggesting people to move to module_parm now in the stable
series leads to renaming of module parameters, which breaks previously
working configurations in often subtle ways. Maybe that's acceptable
in a unstable development kernel, but I don't think it is in 2.6.
How about adding a "setup option alias" table and require that everybody
changing an existing __setup to module_parm adds an alias there?
> > E.g. the new argument needed to make the mouse work on KVMs is
> > mindboogling, could be nearly a Windows registry entry.
>
> I have no idea what you are talking about. 8(
psmouse_base.psmouse_noext
(brought to you by the department of redundancy department)
The "new" and "improved" version is apparently:
psmouse_base.psmouse_proto=bare
which is even worse.
And 2.6.0 -> 2.6.1 silently changing to that without any documentation anywhere,
silently breaking my mouse. And debugging it requires a lot of reboots
because we have regressed to Windows state where every mouse setting change
requires a reboot :-/
Sorry Rusty. You are probably the wrong target for the flame, but a combination
of probably well intended changes including module_parm brought a total usability
disaster here.
-Andi
On Wed, Jan 21, 2004 at 01:23:37PM +0100, Andi Kleen wrote:
> (brought to you by the department of redundancy department)
>
> The "new" and "improved" version is apparently:
>
> psmouse_base.psmouse_proto=bare
2.6.2 will have it as:
psmouse.proto=bare
which isn't that bad.
> And 2.6.0 -> 2.6.1 silently changing to that without any documentation
> anywhere, silently breaking my mouse. And debugging it requires a lot
> of reboots because we have regressed to Windows state where every
> mouse setting change requires a reboot :-/
>
> Sorry Rusty. You are probably the wrong target for the flame, but a
> combination of probably well intended changes including module_parm
> brought a total usability disaster here.
Keep prepared for yet another silent change (documentation _is_ getting
updated, though). And I'll don my asbestos overall ...
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Wed, Jan 21, 2004 at 01:27:44PM +0100, Andi Kleen wrote:
> On Wed, 21 Jan 2004 09:40:09 +0100
> Vojtech Pavlik <[email protected]> wrote:
>
> >
> > Inbetween the module changes and the input changes there was a
> > situation, where you'd have to pass
> >
> > psmouse.psmouse_maxproto=imps2
> >
> > as a kernel argument. This should (I hope so, I have to check) be fixed
> > now.
>
> No, 2.6.1 requires it.
>
> And worst is that you have to reboot to change mouse settings at all.
> That just doesn't make any sense. Can you please add an runtime sysfs
> interface for this?
It's planned, though not easy to implement at all. I don't think I'll be
able to get this into 2.6.2. For now you can enable EMBEDDED, compile
psmouse as a module, and just rmmod/insmod it with new parameters.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Wed, 21 Jan 2004 09:40:09 +0100
Vojtech Pavlik <[email protected]> wrote:
>
> Inbetween the module changes and the input changes there was a
> situation, where you'd have to pass
>
> psmouse.psmouse_maxproto=imps2
>
> as a kernel argument. This should (I hope so, I have to check) be fixed
> now.
No, 2.6.1 requires it.
And worst is that you have to reboot to change mouse settings at all.
That just doesn't make any sense. Can you please add an runtime sysfs
interface for this?
-Andi
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 21 Jan 2004, Andi Kleen wrote:
> On Wed, 21 Jan 2004 15:06:57 +1100
> Rusty Russell <[email protected]> wrote:
>
> > In message <[email protected]> you write:
> > > Rusty Russell <[email protected]> writes:
> > >
> > > > Migrating to module_param() is the Right Thing here IMHO, which actually
> > > > takes the damn address,
> > >
> > > The main problem is that module_parm renames the boot time arguments and
> > > makes them long and hard to remember.
> >
> > Um, if the module name is neat, and the parameter name is neat, the
> > combination of the two with a "." between them will be nest.
>
> Unfortunately we have lots of non neat module names and many previous boot
> time arguments note their subsystem which adds even more redundancy.
>
> And you're suggesting people to move to module_parm now in the stable
> series leads to renaming of module parameters, which breaks previously
> working configurations in often subtle ways. Maybe that's acceptable
> in a unstable development kernel, but I don't think it is in 2.6.
>
> How about adding a "setup option alias" table and require that everybody
> changing an existing __setup to module_parm adds an alias there?
>
> > > E.g. the new argument needed to make the mouse work on KVMs is
> > > mindboogling, could be nearly a Windows registry entry.
> >
> > I have no idea what you are talking about. 8(
>
> psmouse_base.psmouse_noext
>
> (brought to you by the department of redundancy department)
>
> The "new" and "improved" version is apparently:
>
> psmouse_base.psmouse_proto=bare
Actually it's psmouse.proto=bare
> which is even worse.
>
> And 2.6.0 -> 2.6.1 silently changing to that without any documentation anywhere,
> silently breaking my mouse. And debugging it requires a lot of reboots
> because we have regressed to Windows state where every mouse setting change
> requires a reboot :-/
>
> Sorry Rusty. You are probably the wrong target for the flame, but a combination
> of probably well intended changes including module_parm brought a total usability
> disaster here.
>
> -Andi
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
- --
==================================================
Marcos Daniel Marado Torres AKA Mind Booster Noori
/"\ http://student.dei.uc.pt/~marado
\ / [email protected]
X ASCII Ribbon Campaign
/ \ against HTML e-mail and Micro$oft attachments
==================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFADnEbmNlq8m+oD34RAmatAKCBEpHzK1KzpmOQ6T8fveaL5j6bJgCeP+AA
N57BBoKD2an9Cg3ifJVYvh0=
=ikyB
-----END PGP SIGNATURE-----
On Wed, 21 Jan 2004 12:31:21 +0000 (WET)
"Marcos D. Marado Torres" <[email protected]> wrote:
> apparently:
> >
> > psmouse_base.psmouse_proto=bare
>
> Actually it's psmouse.proto=bare
In 2.6.1 it is definitely psmouse_base.psmouse_proto=bare
-Andi
On Wed, 21 Jan 2004 13:34:54 +0100
Vojtech Pavlik <[email protected]> wrote:
> On Wed, Jan 21, 2004 at 01:27:44PM +0100, Andi Kleen wrote:
> > On Wed, 21 Jan 2004 09:40:09 +0100
> > Vojtech Pavlik <[email protected]> wrote:
> >
> > >
> > > Inbetween the module changes and the input changes there was a
> > > situation, where you'd have to pass
> > >
> > > psmouse.psmouse_maxproto=imps2
> > >
> > > as a kernel argument. This should (I hope so, I have to check) be fixed
> > > now.
> >
> > No, 2.6.1 requires it.
> >
> > And worst is that you have to reboot to change mouse settings at all.
> > That just doesn't make any sense. Can you please add an runtime sysfs
> > interface for this?
>
> It's planned, though not easy to implement at all. I don't think I'll be
> able to get this into 2.6.2. For now you can enable EMBEDDED, compile
> psmouse as a module, and just rmmod/insmod it with new parameters.
Really. I don't want a modular mouse driver, just a mouse that keeps working
over kernel releases without me requiring tracking undocumented changes
every release. Thanks for the warning that you renamed it again, at least
that will save some reboots next time.
Could you perhaps readd the old __setup that at least the old version
keeps working? After that you can rename it again as often as you
want as long as the old alias keeps working ;-)
As for the implementation of doing it at runtime - i took a look at it
but got scared by sysfs livetime rules and the lack of callbacks in module_parm.
I think the easiest way would be to just poll the value: make it a module_parm with the
w bit enabled, add a second set of state variables and every time you access
the mouse you compare the module_parm variables and the shadow variables and change
the mouse setting if they differ. Not pretty, but would probably work without
too much sysfs black magic.
-Andi
>
On Wed, 21 Jan 2004 12:53:12 +0000 (WET)
"Marcos D. Marado Torres" <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 21 Jan 2004, Andi Kleen wrote:
>
> > On Wed, 21 Jan 2004 12:31:21 +0000 (WET)
> > "Marcos D. Marado Torres" <[email protected]> wrote:
> >
> > > apparently:
> > > >
> > > > psmouse_base.psmouse_proto=bare
> > >
> > > Actually it's psmouse.proto=bare
> >
> > In 2.6.1 it is definitely psmouse_base.psmouse_proto=bare
>
> Do you have it compiled as a module?
No of course not. For a module it would be psmouse_proto=bare
-Andi
On Wednesday 21 January 2004 07:34 am, Vojtech Pavlik wrote:
> On Wed, Jan 21, 2004 at 01:27:44PM +0100, Andi Kleen wrote:
> > On Wed, 21 Jan 2004 09:40:09 +0100
> >
> > Vojtech Pavlik <[email protected]> wrote:
> > > Inbetween the module changes and the input changes there was a
> > > situation, where you'd have to pass
> > >
> > > psmouse.psmouse_maxproto=imps2
> > >
> > > as a kernel argument. This should (I hope so, I have to check) be
> > > fixed now.
> >
> > No, 2.6.1 requires it.
> >
> > And worst is that you have to reboot to change mouse settings at all.
> > That just doesn't make any sense. Can you please add an runtime sysfs
> > interface for this?
>
> It's planned, though not easy to implement at all. I don't think I'll
> be able to get this into 2.6.2. For now you can enable EMBEDDED,
> compile psmouse as a module, and just rmmod/insmod it with new
> parameters.
No, it's just mousedev that is always built-in, psmouse can be compiled
as a module (and that's the reason the whole naming mess happened - I use
it as a module and haven't noticed the necessity of the prefixes when
converted to the module_param()).
--
Dmitry
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 21 Jan 2004, Andi Kleen wrote:
> On Wed, 21 Jan 2004 12:31:21 +0000 (WET)
> "Marcos D. Marado Torres" <[email protected]> wrote:
>
> > apparently:
> > >
> > > psmouse_base.psmouse_proto=bare
> >
> > Actually it's psmouse.proto=bare
>
> In 2.6.1 it is definitely psmouse_base.psmouse_proto=bare
Do you have it compiled as a module?
> -Andi
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
- --
==================================================
Marcos Daniel Marado Torres AKA Mind Booster Noori
/"\ http://student.dei.uc.pt/~marado
\ / [email protected]
X ASCII Ribbon Campaign
/ \ against HTML e-mail and Micro$oft attachments
==================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFADnY7mNlq8m+oD34RAjSgAKDfYlvGpTiBTnlr8NXWbfpWcyAV5wCfafMb
aihlrtCkWQNtIXI4EuhERos=
=oxw2
-----END PGP SIGNATURE-----
On Wednesday 21 January 2004 07:42 am, Andi Kleen wrote:
> On Wed, 21 Jan 2004 12:31:21 +0000 (WET)
>
> "Marcos D. Marado Torres" <[email protected]> wrote:
> > apparently:
> > > psmouse_base.psmouse_proto=bare
> >
> > Actually it's psmouse.proto=bare
>
> In 2.6.1 it is definitely psmouse_base.psmouse_proto=bare
>
You really should see psmouse.psmouse_proto=bare in 2.6.1 (and it's
changed to psmouse.proto=bare in 2.6.2-rc1):
make KBUILD_MODULES=1 -f scripts/Makefile.build obj=drivers/input/mouse
gcc -Wp,-MD,drivers/input/mouse/.psmouse-base.o.d -nostdinc -iwithprefix
include -D__KERNEL__ -Iinclude -D__KERNEL__ -Iinclude
-Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-pipe -mpreferred-stack-boundary=2 -march=pentium3
-Iinclude/asm-i386/mach-default -O2
-DMODULE -DKBUILD_BASENAME=psmouse_base -DKBUILD_MODNAME=psmouse
-c -o drivers/input/mouse/.tmp_psmouse-base.o
drivers/input/mouse/psmouse-base.c
As you can see KBUILD_MODNAME is just psmouse and module_param() uses it
as a prefix.
--
Dmitry
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 21 Jan 2004, Andi Kleen wrote:
> On Wed, 21 Jan 2004 12:53:12 +0000 (WET)
> "Marcos D. Marado Torres" <[email protected]> wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Wed, 21 Jan 2004, Andi Kleen wrote:
> >
> > > On Wed, 21 Jan 2004 12:31:21 +0000 (WET)
> > > "Marcos D. Marado Torres" <[email protected]> wrote:
> > >
> > > > apparently:
> > > > >
> > > > > psmouse_base.psmouse_proto=bare
> > > >
> > > > Actually it's psmouse.proto=bare
> > >
> > > In 2.6.1 it is definitely psmouse_base.psmouse_proto=bare
> >
> > Do you have it compiled as a module?
>
> No of course not. For a module it would be psmouse_proto=bare
>
> -Andi
>
Oh, I'm sorry, I was talking about 2.6.2-rc1.
Starting in 2.6.1-mm* and now in 2.6.2-rc1 you just have to pass
psmouse.proto=bare .
- --
==================================================
Marcos Daniel Marado Torres AKA Mind Booster Noori
/"\ http://student.dei.uc.pt/~marado
\ / [email protected]
X ASCII Ribbon Campaign
/ \ against HTML e-mail and Micro$oft attachments
==================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFADnlOmNlq8m+oD34RAgdPAKDeeGMpZOq2ObzIEVHyzUb8ovBarACfdIk0
owGg+aqr2clAfXNod323y9c=
=6PbO
-----END PGP SIGNATURE-----
On Wed, Jan 21, 2004 at 01:46:57PM +0100, Andi Kleen wrote:
> As for the implementation of doing it at runtime - i took a look at it
> but got scared by sysfs livetime rules and the lack of callbacks in module_parm.
> I think the easiest way would be to just poll the value: make it a module_parm with the
> w bit enabled, add a second set of state variables and every time you access
> the mouse you compare the module_parm variables and the shadow variables and change
> the mouse setting if they differ. Not pretty, but would probably work without
> too much sysfs black magic.
The second problem (after the sysfs magic) is that I'd have to
completely reinitialize the mouse as well, down to the features of the
mouse changing (for example no wheel anymore).
So, it's planned, but don't expect it in 2.6.2.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
In message <[email protected]> you write:
> As for the implementation of doing it at runtime - i took a look at
> it but got scared by sysfs livetime rules and the lack of callbacks
> in module_parm.
FYI module_parm is just a convenience wrapper around
module_param_call(name, set, get, arg, perm)
Where get and set are the callbacks:
/* Returns 0, or -errno. arg is in kp->arg. */
typedef int (*param_set_fn)(const char *val, struct kernel_param *kp);
/* Returns length written or -errno. Buffer is 4k (ie. be short!) */
typedef int (*param_get_fn)(char *buffer, struct kernel_param *kp);
With these the implementation should be fairly neat.
Hope that clarifies,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
In message <[email protected]> you write:
> Unfortunately we have lots of non neat module names and many previous boot
> time arguments note their subsystem which adds even more redundancy.
>
> And you're suggesting people to move to module_parm now in the stable
> series leads to renaming of module parameters, which breaks previously
> working configurations in often subtle ways. Maybe that's acceptable
> in a unstable development kernel, but I don't think it is in 2.6.
I think we're getting a little confused here.
I'm saying that people should start using module_param instead of
MODULE_PARM in new code, or code being reworked. This adds a boot
param where there was none before.
I'm explicitly not advocating replacing __setup() for existing code.
> And 2.6.0 -> 2.6.1 silently changing to that without any
> documentation anywhere, silently breaking my mouse.
That's bad. I would have left the old __setup under #ifdef
CONFIG_OBSOLETE_MODPARM (or something where it can eventually go
away). And maybe a printk warning about using the old name.
> Sorry Rusty. You are probably the wrong target for the flame, but a
> combination of probably well intended changes including module_parm
> brought a total usability disaster here.
Perhaps I am the wrong target, but I'm glad you brought it up.
I thought that changing __setup to module_param() would have obvious
effects, and authors would make their own call on that.
FYI: __setup and module_param() *CAN* be freely mixed, unlike
MODULE_PARM and module_param().
Hope that clarifies,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.