Re: 2.6.18-rc4-mm1

Dave Jones
2006-08-14T21:21:11Z

On Mon, Aug 14, 2006 at 11:13:14PM +0200, Michal Piotrowski wrote:
> On 14/08/06, Dave Jones <davej@redhat.com> wrote:
> > > Aug 14 22:30:09 ltg01-fedora kernel: general protection fault: 0000 [#1]
> > > Aug 14 22:30:09 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> > > Aug 14 22:30:09 ltg01-fedora kernel: last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
> > > Aug 14 22:30:09 ltg01-fedora kernel: CPU: 0
> > > Aug 14 22:30:09 ltg01-fedora kernel: EIP: 0060:[<c0205249>] Not tainted VLI
> > > Aug 14 22:30:09 ltg01-fedora kernel: EFLAGS: 00010246 (2.6.18-rc4-mm1 #101)
> > > Aug 14 22:30:09 ltg01-fedora kernel: EIP is at __list_add+0x3d/0x7a
> > > Aug 14 22:30:09 ltg01-fedora kernel: eax: 00000000 ebx: c0670a80 ecx: c038d4dc edx: 00000000
> > > Aug 14 22:30:09 ltg01-fedora kernel: esi: ffffffff edi: f50ebee8 ebp: f50ebed0 esp: f50ebec4
> >
> > __list_add will still be dereferencing prev->next, so you should see exactly
> > the same gpf. Note that you're not triggering the BUG()'s here, you're hitting
> > some other fault just walking the list.
>
> How can I debug this?

Not sure. I'm somewhat puzzled.
Disassembling the Code: of your oops shows that we were trying to dereference esi,
which was -1 for some bizarre reason. (my objdump really hated disassembling that
function, but I think thats my tools rather than breakage in the oops).

Question is how did that list member get to be -1 ?
One pie-in-the-sky possibility is that we've corrupted memory recently, and
this link-list manipulation just stumbled across it. Note that the last file
opened before we blew up was reading i2c. Can you try and reproduce this
(if you can reproduce it at all) without the sensors stuff loaded ?

It's a long-shot, but without further clues, I'm stabbing in the dark.

Dave

--