Roland Orre wrote:
>
> I've now installed an USB (/dev/input/mice) mouse in my 2.4.0-test7
> system and my lockup problem now seems to have disappeared. This
> indicates that the problem relates to the PS2 mouse driver (which
> my ksymoops list also earlier did).
> In my case the USB mouse is this not a workaround, however, because
> the systems are connected through a multi terminal switch (OmniCube)
> which uses PS2 but it allows me to continue testing the 2.4.* system
> (and I need to use USB soon...).
>
> I just noticed the following comment about 2.2.17pre12 at
> http://linuxtoday.com/news_story.php3?ltsn=2000-08-24-011-04-NW-K
>
> * Fix PS/2 reconnect lockup on SMP (David Nelson)
>
> This could possibly be the explanation of my problem because the
> reconnect handling was added first in 2.2.16, which I have not
> tried. But now I can try with the 2.2.17pre20 version.
>
> Does anybody have any good hint about the best way to apply these
> pre-patches (http://jhcloos.com/pub/linux-2.2.17-pre/)
> as they seem to be incremental?
>
> skp <skp@mirkwood.net> wrote:
> > This is probably unrelated, but I have an SMP system here as well with an
> > Adaptec card using the aic7xxx driver. Awhile back, I had this driver
> > compiled as a module (primary drives are IDE - right now, the SCSI card is
> > there for a cd burner). ~50% of the time when I loaded the module (the
> > longer I waited after boot the more likely it was to happen), the system
> > would completely lock up.
> > The card was pulled out of a single cpu system - it worked great there.
> > This problem *appears* to have gone away with the driver compiled into the
> > kernel - haven't tried making it a module again recently. I think the
> > last time I tried this was at 2.2.14.
> >
> > As I said, it's probably unrelated, but I thought it interesting that you
> > were experiencing lockups on a SMP box with that driver loaded...
>
> My first SMP system, based on a PL97DS board from ASUS, which has now run
> stable for 2.5 years since I assemblied it uses SCSI only (as my other SMP
> systems too) but from time to time I have connected some IDE drive and
> actually got some lockup at some occasion. I have always had the aic7xxx
> driver compiled into the kernel. If I remember right from earlier discussions
> on the linux-smp list I think this problem is related to this board and the
> mix of IDE/SCSI with the earlier SMP kernels and maybe not to the aic7xxx
> driver as such.
>
> Roland
I have a lengthy chain of Oopses from 2.4.0-test6, mostly from
stext_lock, but also some others. I send this in hope that this could be
useful because the Oops discused here is also in stext_lock. I also have
a ps/2 mouse but I have not observed the coincidence in Oopses and ps/2
moves.
>>EIP; c011770a <__wake_up+8a/8b0> <=====
Trace; c0194b6f <memcpy_fromiovec+3b/6c>
Trace; c011709d <schedule+425/a08>
Trace; c01c9216 <unix_write_space+3e/68>
Trace; c019365c <sock_wfree+18/34>
Trace; c01943be <__kfree_skb+8a/178>
Trace; c01cb386 <unix_stream_recvmsg+2ca/3c0>
Trace; c0190cd1 <sock_recvmsg+41/b0>
Trace; c01cb0bc <unix_stream_recvmsg+0/3c0>
Trace; c0190ddf <sock_read+93/9c>
Trace; c0131556 <sys_read+8e/a4>
Trace; c01094b7 <system_call+37/40>
Code; c011770a <__wake_up+8a/8b0>
00000000 <_EIP>:
Code; c011770a <__wake_up+8a/8b0> <=====
0: 8b 10 movl (%eax),%edx <=====
Code; c011770c <__wake_up+8c/8b0>
2: 89 d0 movl %edx,%eax
Code; c011770e <__wake_up+8e/8b0>
4: 24 df andb $0xdf,%al
Code; c0117710 <__wake_up+90/8b0>
6: 85 45 f8 testl %eax,0xfffffff8(%ebp)
Code; c0117713 <__wake_up+93/8b0>
9: 0f 84 0f 04 00 00 je 41e <_EIP+0x41e> c0117b28
<__wake_up+4a8/8b0>
Code; c0117719 <__wake_up+99/8b0>
f: 83 7d ec 00 cmpl $0x0,0xffffffec(%ebp)
Code; c011771d <__wake_up+9d/8b0>
13: 74 00 je 15 <_EIP+0x15> c011771f
<__wake_up+9f/8b0>
>>EIP; c01d7424 <stext_lock+8d4/8030> <=====
Trace; c0140260 <poll_freewait+30/50>
Trace; c01410b6 <sys_poll+346/360>
Trace; c013fd86 <sys_ioctl+1aa/204>
Trace; c013fdd1 <sys_ioctl+1f5/204>
Trace; c01094b7 <system_call+37/40>
Code; c01d7424 <stext_lock+8d4/8030>
00000000 <_EIP>:
Code; c01d7424 <stext_lock+8d4/8030> <=====
0: f3 90 repz nop <=====
Code; c01d7426 <stext_lock+8d6/8030>
2: 7e f9 jle fffffffd <_EIP+0xfffffffd>
c01d7421 <stext_lock+8d1/8030>
Code; c01d7428 <stext_lock+8d8/8030>
4: e9 3d 1b f4 ff jmp fff41b46 <_EIP+0xfff41b46>
c0118f6a <remove_wait_queue+6/24>
Code; c01d742d <stext_lock+8dd/8030>
9: 80 3d 40 69 21 c0 00 cmpb $0x0,0xc0216940
Code; c01d7434 <stext_lock+8e4/8030>
10: f3 90 repz nop
Code; c01d7436 <stext_lock+8e6/8030>
12: 7e f5 jle 9 <_EIP+0x9> c01d742d
<stext_lock+8dd/8030>
>>EIP; c012bcc7 <free_block+4b/d4> <=====
Trace; c012bf6a <kmem_cache_free+5a/88>
Trace; c012c00a <kfree+72/a0>
Trace; c01942d0 <kfree_skbmem+28/8c>
Trace; c01944a5 <__kfree_skb+171/178>
Trace; c01cb386 <unix_stream_recvmsg+2ca/3c0>
Trace; c0190cd1 <sock_recvmsg+41/b0>
Trace; c01cb0bc <unix_stream_recvmsg+0/3c0>
Trace; c0190ddf <sock_read+93/9c>
Trace; c0131556 <sys_read+8e/a4>
Trace; c01094b7 <system_call+37/40>
Code; c012bcc7 <free_block+4b/d4>
00000000 <_EIP>:
Code; c012bcc7 <free_block+4b/d4> <=====
0: 89 54 81 18 movl %edx,0x18(%ecx,%eax,4) <=====
Code; c012bccb <free_block+4f/d4>
4: 89 41 14 movl %eax,0x14(%ecx)
Code; c012bcce <free_block+52/d4>
7: 8b 46 14 movl 0x14(%esi),%eax
Code; c012bcd1 <free_block+55/d4>
a: 8b 51 10 movl 0x10(%ecx),%edx
Code; c012bcd4 <free_block+58/d4>
d: ff 49 10 decl 0x10(%ecx)
Code; c012bcd7 <free_block+5b/d4>
10: 39 c2 cmpl %eax,%edx
Code; c012bcd9 <free_block+5d/d4>
12: 74 08 je 1c <_EIP+0x1c> c012bce3
<free_block+67/d4>
P.D. As usual more info as requested.
-- Jorge Nerin <jnerin@svalero.es> <comandante@zaralinux.com> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:21 EST