Re: 2.6.15-rc2-mm1

Re: 2.6.15-rc2-mm1

[Andrew Morton]

Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
>
>  Debug: sleeping function called from invalid context at
>  include/asm/semaphore.h:123
>  in_atomic():1, irqs_disabled():0
>   [<c0103be6>] dump_stack+0x17/0x19
>   [<c011a0c3>] __might_sleep+0x9c/0xae
>   [<fd9a090d>] translate_table+0x147/0xc14 [ip_tables]
>   [<fd9a2b2a>] ipt_register_table+0x93/0x20d [ip_tables]
>   [<f98fe027>] init+0x27/0x9e [iptable_filter]
>   [<c01376d0>] sys_init_module+0xd7/0x26c
>   [<c0102cc7>] sysenter_past_esp+0x54/0x75
>  ---------------------------
>  | preempt count: 00000001 ]
>  | 1 level deep critical section nesting:
>  ----------------------------------------
>  .. [<fd9a2aca>] .... ipt_register_table+0x33/0x20d [ip_tables]
>  .....[<f98fe027>] ..   ( <= init+0x27/0x9e [iptable_filter])
> 

ipt_register_table() does get_cpu() then calls translate_table(), and
somewhere under translate_table() we do something which sleeps, only I'm not
sure what it is - netfilter likes to hide things in unexpected places.

check_entry() will do sleepy things under that get_cpu(), but that doesn't
seem to be in this particular call chain.

Anyway, the new get_cpu() in ipt_register_table() is the problem.

Re: 2.6.15-rc2-mm1

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]

On Wed, Nov 23, 2005 at 11:22:18AM -0800, Andrew Morton wrote:
> Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> >
> >  Debug: sleeping function called from invalid context at
> >  include/asm/semaphore.h:123
> >  in_atomic():1, irqs_disabled():0
> >   [<c0103be6>] dump_stack+0x17/0x19
> >   [<c011a0c3>] __might_sleep+0x9c/0xae
> >   [<fd9a090d>] translate_table+0x147/0xc14 [ip_tables]
> >   [<fd9a2b2a>] ipt_register_table+0x93/0x20d [ip_tables]
> >   [<f98fe027>] init+0x27/0x9e [iptable_filter]
> >   [<c01376d0>] sys_init_module+0xd7/0x26c
> >   [<c0102cc7>] sysenter_past_esp+0x54/0x75
> >  ---------------------------
> >  | preempt count: 00000001 ]
> >  | 1 level deep critical section nesting:
> >  ----------------------------------------
> >  .. [<fd9a2aca>] .... ipt_register_table+0x33/0x20d [ip_tables]
> >  .....[<f98fe027>] ..   ( <= init+0x27/0x9e [iptable_filter])
> > 
> 
> ipt_register_table() does get_cpu() then calls translate_table(), and
> somewhere under translate_table() we do something which sleeps, only I'm not
> sure what it is - netfilter likes to hide things in unexpected places.

I'll investigate this.  the get_cpu() scheme was introduced as a fix for
a different (less serious) problem.  

You'll get a reply until later today.

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.15-rc2-mm1

[Andrew Morton]

Marc Koschewski <marc@osknowledge.org> wrote:
>
> * Andrew Morton <akpm@osdl.org> [2005-11-23 03:35:50 -0800]:
> 
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc2/2.6.15-rc2-mm1/
> > 
> > (temp copy at http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.15-rc2-mm1.gz)
> > 
> > - Added git-sym2.patch to the -mm lineup: updates to the sym2 scsi driver
> >   (Matthew Wilcox).  
> > 
> > - The JSM tty driver still doesn't compile.
> > 
> > - The git-powerpc tree is included now.
> 
> Just booted into 2.6.15-rc2-mm1. The 'mouse problem' (as reported earlier) still
> persists,

You'l probably need to re-report the mouse problem if the previous report
didn't get any action.

> moreover, some stuff's now really not gonna work anymore. I logged in
> via gdm once and rebooted. 

Yes, netfilter broke.

> ...
> Nov 23 18:34:01 stiffy kernel: 0.0: ttyS3 at I/O 0xe108 (irq = 3) is a 8250
> Nov 23 18:34:01 stiffy kernel: ip_conntrack version 2.4 (4095 buckets, 32760 max) - 212 bytes per conntrack
> Nov 23 18:34:01 stiffy kernel: ip_tables: (C) 2000-2002 Netfilter core team
> Nov 23 18:34:01 stiffy kernel:  [schedule+1453/1679] schedule+0x5ad/0x68f
> Nov 23 18:34:01 stiffy kernel:  [__wake_up_common+60/94] __wake_up_common+0x3c/0x5e
> Nov 23 18:34:01 stiffy kernel:  [wait_for_completion+134/242] wait_for_completion+0x86/0xf2
> Nov 23 18:34:01 stiffy kernel:  [default_wake_function+0/18] default_wake_function+0x0/0x12
> Nov 23 18:34:01 stiffy kernel:  [call_usermodehelper_keys+175/186] call_usermodehelper_keys+0xaf/0xba
> Nov 23 18:34:01 stiffy kernel:  [__call_usermodehelper+0/110] __call_usermodehelper+0x0/0x6e
> Nov 23 18:34:01 stiffy kernel:  [request_module+175/240] request_module+0xaf/0xf0
> Nov 23 18:34:01 stiffy kernel:  [buffered_rmqueue+241/514] buffered_rmqueue+0xf1/0x202
> Nov 23 18:34:01 stiffy kernel:  [get_page_from_freelist+136/162] get_page_from_freelist+0x88/0xa2
> Nov 23 18:34:01 stiffy kernel:  [pg0+553595222/1069659136] translate_table+0x95f/0xbcb [ip_tables]
> Nov 23 18:34:01 stiffy kernel:  [map_vm_area+109/149] map_vm_area+0x6d/0x95
> Nov 23 18:34:01 stiffy kernel:  [__vmalloc_area_node+246/362] __vmalloc_area_node+0xf6/0x16a
> Nov 23 18:34:01 stiffy kernel:  [__vmalloc_node+79/110] __vmalloc_node+0x4f/0x6e
> Nov 23 18:34:01 stiffy kernel:  [__vmalloc+39/43] __vmalloc+0x27/0x2b
> Nov 23 18:34:01 stiffy kernel:  [pg0+553597367/1069659136] do_replace+0x145/0x6d6 [ip_tables]
> Nov 23 18:34:03 stiffy kernel:  [pg0+553596209/1069659136] copy_entries_to_user+0xaf/0x1e3 [ip_tables]
> Nov 23 18:34:04 stiffy kernel:  [pg0+553599347/1069659136] do_ipt_set_ctl+0x1e/0x62 [ip_tables]
> Nov 23 18:34:04 stiffy kernel:  [nf_sockopt+198/277] nf_sockopt+0xc6/0x115
> Nov 23 18:34:04 stiffy kernel:  [nf_setsockopt+55/59] nf_setsockopt+0x37/0x3b
> Nov 23 18:34:04 stiffy kernel:  [ip_setsockopt+219/3448] ip_setsockopt+0xdb/0xd78
> Nov 23 18:34:04 stiffy kernel:  [nf_sockopt+136/277] nf_sockopt+0x88/0x115
> Nov 23 18:34:04 stiffy kernel:  [nf_getsockopt+55/59] nf_getsockopt+0x37/0x3b
> Nov 23 18:34:04 stiffy kernel:  [ip_getsockopt+254/1764] ip_getsockopt+0xfe/0x6e4
> Nov 23 18:34:04 stiffy kernel:  [prio_tree_remove+150/191] prio_tree_remove+0x96/0xbf
> Nov 23 18:34:04 stiffy kernel:  [free_pgtables+59/167] free_pgtables+0x3b/0xa7
> Nov 23 18:34:04 stiffy kernel:  [buffered_rmqueue+241/514] buffered_rmqueue+0xf1/0x202
> Nov 23 18:34:04 stiffy kernel:  [get_page_from_freelist+136/162] get_page_from_freelist+0x88/0xa2
> ...

Mouse issues in -mm

[Frank Sorenson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Morton wrote:
> Marc Koschewski <marc@osknowledge.org> wrote:
>>Just booted into 2.6.15-rc2-mm1. The 'mouse problem' (as reported earlier) still
>>persists,
> 
> You'l probably need to re-report the mouse problem if the previous report
> didn't get any action.

I'm not certain whether this is the same 'mouse problem', but I'll
report the mouse problems I've been seeing.  In the past several -mm
kernels, my touchpad has initially worked at boot, but 'tapping' has
stopped working at some point later (with no obvious kernel messages).

I've experienced this problem at least with 2.6.15-rc1-mm2 and
2.6.15-rc2-mm1, and reverting
input-attempt-to-re-synchronize-mouse-every-5-seconds.patch gives a
kernel without the touchpad problems.

Thanks,

Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFDhSAuaI0dwg4A47wRAvzYAJ94ifBDBTm7MfVsbTOZE8QG3NjZUwCggHv0
SQvehLxz6pLHs+5J+jTeaKU=
=Pkg2
-----END PGP SIGNATURE-----

Re: Mouse issues in -mm

[Dmitry Torokhov]

On Wednesday 23 November 2005 21:06, Frank Sorenson wrote:
> Andrew Morton wrote:
> > Marc Koschewski <marc@osknowledge.org> wrote:
> >>Just booted into 2.6.15-rc2-mm1. The 'mouse problem' (as reported earlier) still
> >>persists,
> >
> > You'l probably need to re-report the mouse problem if the previous report
> > didn't get any action.
> 
> I'm not certain whether this is the same 'mouse problem', but I'll
> report the mouse problems I've been seeing.  In the past several -mm
> kernels, my touchpad has initially worked at boot, but 'tapping' has
> stopped working at some point later (with no obvious kernel messages).
> 
> I've experienced this problem at least with 2.6.15-rc1-mm2 and
> 2.6.15-rc2-mm1, and reverting
> input-attempt-to-re-synchronize-mouse-every-5-seconds.patch gives a
> kernel without the touchpad problems.
>

What kind of touchpad do you have? Could you post your
/pros/bus/input/devices please?

-- 
Dmitry

Re: Mouse issues in -mm

[Frank Sorenson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dmitry Torokhov wrote:
> What kind of touchpad do you have? Could you post your
> /pros/bus/input/devices please?

AlpsPS/2 ALPS GlidePoint

/proc/bus/input/devices:
I: Bus=0010 Vendor=001f Product=0001 Version=0100
N: Name="PC Speaker"
P: Phys=isa0061/input0
S: Sysfs=/class/input/input0
H: Handlers=kbd event0
B: EV=40001
B: SND=46

I: Bus=0011 Vendor=0001 Product=0001 Version=ab41
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
S: Sysfs=/class/input/input1
H: Handlers=kbd event1
B: EV=120013
B: KEY=4 2000000 3802078 f840d001 f2ffffdf ffefffff ffffffff fffffffe
B: MSC=10
B: LED=7

I: Bus=0011 Vendor=0002 Product=0008 Version=0000
N: Name="PS/2 Mouse"
P: Phys=isa0060/serio1/input1
S: Sysfs=/class/input/input2
H: Handlers=mouse0 event2
B: EV=7
B: KEY=70000 0 0 0 0 0 0 0 0
B: REL=3

I: Bus=0011 Vendor=0002 Product=0008 Version=7321
N: Name="AlpsPS/2 ALPS GlidePoint"
P: Phys=isa0060/serio1/input0
S: Sysfs=/class/input/input3
H: Handlers=mouse1 event3
B: EV=f
B: KEY=420 0 70000 0 0 0 0 0 0 0 0
B: REL=3
B: ABS=1000003


Note: I believe this issue may also be related to the mouse protocol
extension.  I typically run with 'psmouse.proto=exps' on the kernel
command line, and the psmouse resync patch seems to break tapping in
that mode.  However, booting without proto=exps seems to continue to
work, even with the resync patch (though the touchpad is unusably
sensitive--hence the use of exps in the first place).

Thanks,

Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFDhVpQaI0dwg4A47wRAgxMAKCgcX59rpVR2umCUz4IBNls8L+8EQCfQprd
4v8Qxv3890dRIus0ptIyGxs=
=AJGF
-----END PGP SIGNATURE-----

Re: Mouse issues in -mm

[Dmitry Torokhov]

On Thursday 24 November 2005 01:14, Frank Sorenson wrote:
> Note: I believe this issue may also be related to the mouse protocol
> extension.  I typically run with 'psmouse.proto=exps' on the kernel
> command line, and the psmouse resync patch seems to break tapping in
> that mode.

So the resync patch - is it only tapping that is broken or you also
loosing the touchpad completely?

> However, booting without proto=exps seems to continue to 
> work, even with the resync patch (though the touchpad is unusably
> sensitive--hence the use of exps in the first place).

Without the parameter your touchpad is using native ALPS protocol and
resync is disabled for it. You may have better liuck with toucpad
sensitivity using synaptics X driver.

-- 
Dmitry

Re: Mouse issues in -mm

[Marc Koschewski]

* Dmitry Torokhov <dtor_core@ameritech.net> [2005-11-23 22:26:43 -0500]:

> On Wednesday 23 November 2005 21:06, Frank Sorenson wrote:
> > Andrew Morton wrote:
> > > Marc Koschewski <marc@osknowledge.org> wrote:
> > >>Just booted into 2.6.15-rc2-mm1. The 'mouse problem' (as reported earlier) still
> > >>persists,
> > >
> > > You'l probably need to re-report the mouse problem if the previous report
> > > didn't get any action.
> > 
> > I'm not certain whether this is the same 'mouse problem', but I'll
> > report the mouse problems I've been seeing.  In the past several -mm
> > kernels, my touchpad has initially worked at boot, but 'tapping' has
> > stopped working at some point later (with no obvious kernel messages).
> > 
> > I've experienced this problem at least with 2.6.15-rc1-mm2 and
> > 2.6.15-rc2-mm1, and reverting
> > input-attempt-to-re-synchronize-mouse-every-5-seconds.patch gives a
> > kernel without the touchpad problems.
> >
> 
> What kind of touchpad do you have? Could you post your
> /pros/bus/input/devices please?

Mine is like this:

I: Bus=0011 Vendor=0001 Product=0001 Version=ab41
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
S: Sysfs=/class/input/input0
H: Handlers=kbd event0
B: EV=120013
B: KEY=4 2000000 3802078 f840d001 f2ffffdf ffefffff ffffffff fffffffe
B: MSC=10
B: LED=7

I: Bus=0010 Vendor=001f Product=0001 Version=0100
N: Name="PC Speaker"
P: Phys=isa0061/input0
S: Sysfs=/class/input/input1
H: Handlers=kbd event1
B: EV=40001
B: SND=6

I: Bus=0011 Vendor=0002 Product=0005 Version=0000
N: Name="ImPS/2 Generic Wheel Mouse"
P: Phys=isa0060/serio1/input0
S: Sysfs=/class/input/input2
H: Handlers=event2 mouse0
B: EV=7
B: KEY=70000 0 0 0 0 0 0 0 0
B: REL=103

I don't know why my touchpad is not listed. I have one and it perfectly
works with X (same pointer as the mouse which is a Microsoft USB Wheel Mouse'
attached to PS/2 using an appropriate adapter.

Marc