All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Ornati <ornati@fastwebnet.it>
To: "Arkadiusz Jałowiec" <ajalowiec@interia.pl>
Cc: linux-kernel@vger.kernel.org,
	linux-usb-users@lists.sourceforge.net, stern@rowland.harvard.edu
Subject: Re: [Linux-usb-users] PROBLEM: Kernel 2.6.x freeze
Date: Tue, 3 Oct 2006 21:52:00 +0200	[thread overview]
Message-ID: <20061003215200.0d1047db@localhost> (raw)
In-Reply-To: <452188DA.6090000@interia.pl>

On Mon, 02 Oct 2006 23:47:06 +0200
Arkadiusz Jalowiec <ajalowiec@interia.pl> wrote:

> BUG: unable to handle kernel paging request at virtual address 000f9edf
> printing epip
> *pde=00000000
> Ops: 0002 [#1]
> Modules linked in: ppp_deflate zlib_deflate bsd_comp pppoatm ipv6 
> partport_pc partport snd_pcm_oss snd_mixer_oss via_agp agpgart uagle_atm 
> usbatm uhci_hcd ehci_hcd usbcore i2c_viapro i2c_core snd_via82xx 
> snd_ac97.codec snd_ac97_bus snd_pcm snd_timer snd_page_alloc 
> snd_mpu_401_uart snd_rawmidi ipt_LOG snd_seq_device snd xt_limit 
> soundcore via_rhine mii xt_tcpudp xt_state iptables_filter nls_iso8859-2 
> nls_cp852 ip_contract_irc ip_contract_ftp xt_contract ip_contract 
> iptables x_tables
> CPU: 0
> EIP: 0060: [<d0d18140>] Not tainted VLI
> EFLAGS: 00010083 (2.6.18 #1)
> EIP is at uhci_result_isochronous+0x4f/0x131 [uhci_hcd]
> eax: 000f9edf ebx: cf7b3600 edx:000f9edf edx:ceedfed0
> esi:cf7b3600 edi:cba5c2a0 epb:ceedfed0 esp:c03adef8
> ds:007b es:007b ss:0068
> 
> Process swapper (pid:0,ti=c03ac000 task=c03530a0 task.ti=c03ac000)
> Stack: cf15e3a0 cba5c330 ce2caac0 ceedfed0 cf7b3600 ce2caac0 00000001 
> ceedfed0
> d0d185d1 c03adfa4 ceedfed0 cf7b3600 00000001 c03adfa4 d0d1884b 00000246
> 00000000 00000000 ceedfe00 d0d192ad ceedfed0 c03adfa4 ceedfe00 00000000
> 
> Call Trace:
> [<d0d185d1>] uhci_scan_qh+0x28/0x174 [uhci_hcd]
> [<d0d18846>] uhci_scan_schedule+0x72/0xec [uhci_hcd]
> [<d0d192ad>] uhci_hcd_irq+0x27/0x4e [usbcore]
> [<c012c4c4>] handle_IRQ_event+0x21/0x47
> [<c012c545>]_do_IRQ+0x5b/0xa2
> [<c0104106>] do_IRQ+0x40/04d
> [<c0102c4a>] common_interrupt+0x1a/0x20
> [<c021dfd1>] acpi_processor_idle+0x1c4/0x2c3
> [<c01010c4>] cpu_idle+0x3f/0x5b
> [<c03ae63b>] start_kernel+0x197/0x199
> 
> Code 83 ed 14 39 c2 89 6c 24 04 0f 84 f3 00 00 00 8b 46 3c 8b 54 24 0c 
> 3b 42 70 78 0a b8 8d ff ff ff e9 e0 00 00 00 89 c1 8b 6c 24 0c <00> 20 
> 7b 0f 00 00 00 00 69 7f e0 ff 00 00 00 00 00 20 7b 0f 14
> 
> EIP:[<cd0d18140>] uhci_result_isochronous+0x4f/0x131
> [uhci_hcd] SS:ESP 0068:c03adef8
> <0> Kernel panic - not syncing: Fatal excepition in interrupt
> 
> I run "objdump -d drivers/usb/host/uhci-hcd.o" and post the portion of 
> the output for: uhci_result_isochronous
> 
> 000010f1 <uhci_result_isochronous>:

[CUT]

>     1115:    83 ed 14                 sub    $0x14,%ebp
>     1118:    39 c2                    cmp    %eax,%edx
>     111a:    89 6c 24 04              mov    %ebp,0x4(%esp)
>     111e:    0f 84 f3 00 00 00        je     1217 
> <uhci_result_isochronous+0x126>
>     1124:    8b 46 3c                 mov    0x3c(%esi),%eax
>     1127:    8b 54 24 0c              mov    0xc(%esp),%edx
>     112b:    3b 42 70                 cmp    0x70(%edx),%eax
>     112e:    78 0a                    js     113a 
> <uhci_result_isochronous+0x49>
>     1130:    b8 8d ff ff ff           mov    $0xffffff8d,%eax
>     1135:    e9 e0 00 00 00           jmp    121a 
> <uhci_result_isochronous+0x129>
>     113a:    89 c1                    mov    %eax,%ecx
>     113c:    8b 6c 24 0c              mov    0xc(%esp),%ebp
>     1140:    81 e1 ff 03 00 00        and    $0x3ff,%ecx
               ||
                ----> EIP points here


>     1146:    8b 45 58                 mov    0x58(%ebp),%eax
>     1149:    8b 1c 88                 mov    (%eax,%ecx,4),%ebx
>     114c:    85 db                    test   %ebx,%ebx
>     114e:    74 35                    je     1185 
> <uhci_result_isochronous+0x94>
>     1150:    8b 43 24                 mov    0x24(%ebx),%eax
>     1153:    8b 55 54                 mov    0x54(%ebp),%edx
>     1156:    8b 40 e0                 mov    0xffffffe0(%eax),%eax
>     1159:    89 04 8a                 mov    %eax,(%edx,%ecx,4)



The assembly extracted by the dumped code is:

   0:   83 ed 14                sub    $0x14,%ebp
   3:   39 c2                   cmp    %eax,%edx
   5:   89 6c 24 04             mov    %ebp,0x4(%esp)
   9:   0f 84 f3 00 00 00       je     102 <str+0x102>
   f:   8b 46 3c                mov    0x3c(%esi),%eax
  12:   8b 54 24 0c             mov    0xc(%esp),%edx
  16:   3b 42 70                cmp    0x70(%edx),%eax
  19:   78 0a                   js     25 <str+0x25>
  1b:   b8 8d ff ff ff          mov    $0xffffff8d,%eax
  20:   e9 e0 00 00 00          jmp    105 <str+0x105>
  25:   89 c1                   mov    %eax,%ecx
  27:   8b 6c 24 0c             mov    0xc(%esp),%ebp
  2b:   00 20                   add    %ah,(%eax)
        ||
         ----> EIP points here


  2d:   7b 0f                   jnp    3e <str+0x3e>
  2f:   00 00                   add    %al,(%eax)
  31:   00 00                   add    %al,(%eax)
  33:   69 7f e0 ff 00 00 00    imul   $0xff,0xffffffe0(%edi),%edi
  3a:   00 00                   add    %al,(%eax)
  3c:   20 7b 0f                and    %bh,0xf(%ebx)
  3f:   14



The code dumped from memory matches the original one up to, and not
including, the failing istruction. From that point the code is
different.


The failure is only a natural consequence of:

	add    %ah,(%eax)

with "eax" pointing to 000f9edf, that belongs to the BIOS reserved
memory region...


The real problem is that the code starting from "0xcd0d18140" has been
overwritten by something :(


Another thing: both panics happened in interrupt context and both times
uhci driver is involved.


And this is the data that has overwritten the code:

00 20 7b 0f 00 00 00 00 69 7f e0 ff 00 00 00 00 00 20 7b 0f 14
^^^^^^^^^^^                                     ^^^^^^^^^^^


Maybe someone have an idea of where does this data come from?


To me it looks like a struct with ints / pointers:

{
	0x0f7b2000,
	NULL,
	0xffe07f69,
	NULL,
	0x0f7b2000,
	0x......14
}


Maybe this will ring some bells...

-- 
	Paolo Ornati
	Linux 2.6.18 on x86_64

  reply	other threads:[~2006-10-03 19:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-28  7:33 PROBLEM: Kernel 2.6.x freeze Arkadiusz Jałowiec
2006-09-28  9:41 ` Paolo Ornati
2006-09-29 12:38 ` Paolo Ornati
2006-09-29 21:29   ` [Linux-usb-users] " Alan Stern
2006-09-30  7:56     ` [Linux-usb-users[ " Arkadiusz Jałowiec
2006-09-30 12:14     ` [Linux-usb-users] " Paolo Ornati
2006-09-30 15:49       ` Alan Stern
2006-10-01 14:10         ` Paolo Ornati
2006-10-02 21:47           ` Arkadiusz Jałowiec
2006-10-03 19:52             ` Paolo Ornati [this message]
2006-10-03 20:34               ` Alan Stern
2006-10-04  7:14                 ` Paolo Ornati
2006-10-04  7:16                   ` Paolo Ornati

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061003215200.0d1047db@localhost \
    --to=ornati@fastwebnet.it \
    --cc=ajalowiec@interia.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-users@lists.sourceforge.net \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.