From: Jonathan Sambrook (jonathan.sambrook_at_dsvr.co.uk)
Date: Tue 11 Mar 2003 - 22:20:49 GMT
At 16:42 on Tue 11/03/03, jonathan.sambrook_at_dsvr.co.uk masquerading as 'Jonathan Sambrook' wrote:
> At 12:53 on Sun 09/03/03, Macahan_at_fament.com masquerading as 'Eje Gustafsson' wrote:
> > Ok. Here we go. Crashed again. Got me another 48 hours of run time.
>
> Just had our first this morning. 2.4.20-ctx16 + odds and sods (some of
> which I really should get around to sending to the list).
>
>
> > Just curious is ctx-14 or ctx-13 more stable then 16 and 15 ?
>
> Hmmn... xxdiff patch-2.4.19ctx-13 patch-2.4.20ctx-16, ruminate and then
> examine your marvelous ksymoops output (haven't got round to installing
> it hereabouts yet <slaps own wrist> and no, the crash didn't happen on
> either of the boxes with serial lines in action). Notice:
>
> > >>ebx; c02a0f1c <uts_sem+0/24>
>
> and wonder about the validity and possible side effects of the changes
> in sys.c's sys_release_ip_info() and sys_assign_ip_info() between ctx14
> and ctx15
>
>
> where:
>
> void sys_release_ip_info (struct task_struct *p)
> {
> down_write (&uts_sem);
> if (p->ip_info != NULL){
> p->ip_info->refcount--;
> if (p->ip_info->refcount == 0){
> // printk ("vfree s_info %d\n",p->pid);
> vfree (p->ip_info);
> p->ip_info = NULL;
> }
> }
> up_write (&uts_sem);
> }
>
> void sys_assign_ip_info (struct task_struct *p)
> {
> down_write (&uts_sem);
> if (p->ip_info != NULL) p->ip_info->refcount++;
> up_write (&uts_sem);
> }
>
>
> turns into:
>
> void sys_release_ip_info (struct iproot_info *ip_info)
> {
> if (ip_info != NULL){
> down_write (&uts_sem);
> ip_info->refcount--;
> if (ip_info->refcount == 0){
> // printk ("vfree s_info %d\n",p->pid);
> vfree (ip_info);
> }
> up_write (&uts_sem);
> }
> }
>
> void sys_assign_ip_info (struct iproot_info *ip_info)
> {
> if (ip_info != NULL){
> down_write (&uts_sem);
> ip_info->refcount++;
> up_write (&uts_sem);
> }
> }
>
> What happens when ip_info changes between the first and second lines of
> each of these functions (which, without having genned up enough on
> ip_info's usage, I presume is possible else why bother with co-opting
> uts_sem?)?
>
If you've got a setup/operating environment whichtriggers the oops, you
might like to test my hypothesis by applying the attached patch after
applying ctx16.
Regards,
Jonathan
>
> Regards,
> Jonathan
>
>
> > >>ecx; c4af6000 <_end+47d483c/304f68bc>
> > >>edx; ee7cff7c <_end+2e4ae7b8/304f68bc>
> > >>esi; c4af60000 <END_OF_CODE+b5a63d695/????>
> > >>edi; c4af7a8c <_end+47d62c8/304f68bc>
> > >>ebp; c4af7a64 <_end+47d62a0/304f68bc>
> > >>esp; c4af7a34 <_end+47d6270/304f68bc>
> >
> > Trace; c020be5f <qdisc_restart+1f/f0>
> > Trace; c0257e0c <rwsem_down_failed_common+4c/30f4>
> > Trace; c0203151 <dev_queue_xmit+1a1/270>
> > Trace; c0231308 <tcp_create_openreq_child+58/450>
> > Trace; c022e507 <tcp_v4_syn_recv_sock+47/180>
> > Trace; c02318cf <tcp_check_req+1cf/420>
> > Trace; c0203151 <dev_queue_xmit+1a1/270>
> > Trace; c021a990 <ip_finish_output2+80/f0>
> > Trace; c0219594 <ip_output+54/a0>
> > Trace; c021a8f0 <output_maybe_reroute+0/20>
> > Trace; c021a900 <output_maybe_reroute+10/20>
> > Trace; c022c206 <tcp_reset_keepalive_timer+26/40>
> > Trace; c02315ad <tcp_create_openreq_child+2fd/450>
> > Trace; c022e5c4 <tcp_v4_syn_recv_sock+104/180>
> > Trace; c022c1cb <tcp_delete_keepalive_timer+2b/40>
> > Trace; c0231962 <tcp_check_req+262/420>
> > Trace; c0203151 <dev_queue_xmit+1a1/270>
> > Trace; f091d18a <[ip_tables]ipt_do_table+da/2a0>
> > Trace; c020be5f <qdisc_restart+1f/f0>
> > Trace; c0203151 <dev_queue_xmit+1a1/270>
> > Trace; c021a990 <ip_finish_output2+80/f0>
> > Trace; c022e69c <tcp_v4_hnd_req+5c/170>
> > Trace; c022ea23 <tcp_v4_do_rcv+133/190>
> > Trace; c022eeda <tcp_v4_rcv+45a/510>
> > Trace; c0216a30 <ip_local_deliver_finish+0/170>
> > Trace; c0216b7b <ip_local_deliver_finish+14b/170>
> > Trace; c0209d03 <nf_hook_slow+b3/180>
> > Trace; c0216a30 <ip_local_deliver_finish+0/170>
> > Trace; c02167cd <ip_local_deliver+4d/70>
> > Trace; c0216a30 <ip_local_deliver_finish+0/170>
> > Trace; c0216d80 <ip_rcv_finish+1e0/260>
> > Trace; c0203671 <netif_receive_skb+111/1d0>
> > Trace; c020379d <process_backlog+6d/110>
> > Trace; c02038aa <net_rx_action+6a/100>
> > Trace; c011d494 <do_softirq+94/a0>
> > Trace; c010a53e <do_IRQ+9e/a0>
> > Trace; c010ca98 <call_do_IRQ+5/d>
> > Trace; c0124be8 <sys_release_ip_info+28/60>
> > Trace; c023ab38 <inet_sock_destruct+f8/1c0>
> > Trace; c01fdfd3 <sk_free+83/90>
> > Trace; c0220780 <tcp_close+240/640>
> > Trace; c023b1f4 <inet_release+54/70>
> > Trace; c01fb6ec <sock_release+5c/60>
> > Trace; c01fbcb9 <sock_close+39/60>
> > Trace; c0139582 <fput+102/130>
> > Trace; c0137c2d <filp_close+4d/80>
> > Trace; c0137cae <sys_close+4e/60>
> > Trace; c0108e7f <system_call+33/38>
> >
> > Code; c0115c99 <schedule+3b9/3e0>
> > 00000000 <_EIP>:
> > Code; c0115c99 <schedule+3b9/3e0> <=====
> > 0: 0f 0b ud2a <=====
> > Code; c0115c9b <schedule+3bb/3e0>
> > 2: 3a 02 cmp (%edx),%al
> > Code; c0115c9d <schedule+3bd/3e0>
> > 4: 82 (bad)
> > Code; c0115c9e <schedule+3be/3e0>
> > 5: 65 gs
> > Code; c0115c9f <schedule+3bf/3e0>
> > 6: 26 es
> > Code; c0115ca0 <schedule+3c0/3e0>
> > 7: c0 e9 89 shr $0x89,%cl
> > Code; c0115ca3 <schedule+3c3/3e0>
> > a: fc cld
> > Code; c0115ca4 <schedule+3c4/3e0>
> > b: ff (bad)
> > Code; c0115ca5 <schedule+3c5/3e0>
> > c: ff 0f decl (%edi)
> > Code; c0115ca7 <schedule+3c7/3e0>
> > e: 0b 33 or (%ebx),%esi
> > Code; c0115ca9 <schedule+3c9/3e0>
> > 10: 02 82 64 26 00 00 add 0x2664(%edx),%al
> >
> > <0>Kernel Panic: Aiee, killing interrupt handler!
> >
> >
> >
> > Best regards,
> > Eje Gustafsson mailto:MacAhan_at_fament.com
> > ---
> > The Family Entertainment Network http://www.fament.com
> > Phone : 620-231-7777 Fax : 620-231-4066
> > eBay UserID : macahan
> > - Your Full Time Professionals -
> >
> > ---
> > [This E-mail scanned for viruses by Declude Virus]
> >
>
> --
>
> Jonathan Sambrook
> Software Developer
> Designer Servers
--
Jonathan Sambrook
Software Developer
Designer Servers