Messages in this thread |  | | Date | Sun, 27 Aug 2000 22:49:19 +0200 | From | Jorge Nerin <> | Subject | Re: Lockup in 2.4.0-test7 |
| |
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/
|  |