[sorry, I sent the previous message with a wrong address by mistake]
On Wednesday 26 April 2006 18:12, Steinar H. Gunderson wrote:
> On Wed, Apr 26, 2006 at 05:40:46PM +0200, R. J. Wysocki wrote:
> >> I reproduced this with 2.6.17-rc2 on the same machine:
> >>
> >> [261604.531829] Unable to handle kernel paging request at ffff8000020369d8 RIP:
> >> [261604.536538] <ffffffff802509e6>{isolate_lru_pages+74}
> > If your kernel is compiled with the debug info, could you please do
> > "gdb vmlinux" in the kernel sorces directory and then (in gdb)
> > "l *(isolate_lru_pages+74)" to see which source line it corresponds to?
>
> It isn't, but I hadn't changed the sources, .config or build environment
> since I built it, so I did a straight recompile with CONFIG_DEBUG_INFO set,
> and got:
>
> (gdb) l *(isolate_lru_pages+74)
> 0xffffffff80250c2a is in isolate_lru_pages (list.h:154).
>
> (I had to run gdb on a machine with 64-bit userspace, but I guess just
> copying the vmlinux file should suffice.)
This kind of agrees with my result ie. list_del() in isolate_lru_pages():
0xffffffff80265b7a is in isolate_lru_pages (list.h:160).
155 * Note: list_empty on entry does not return true after this, the entry is
156 * in an undefined state.
157 */
158 static inline void list_del(struct list_head *entry)
159 {
160 BUG_ON(entry->prev->next != entry);
161 BUG_ON(entry->next->prev != entry);
162 __list_del(entry->prev, entry->next);
163 entry->next = LIST_POISON1;
164 entry->prev = LIST_POISON2;
It looks like we have passed an empty list or a NULL to list_del(). Strange.
Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
