2.4.17rc2aa1

All of lore.kernel.org
 help / color / mirror / Atom feed

* 2.4.17rc2aa1
@ 2001-12-19 15:16 ` Andrea Arcangeli
  2001-12-19 20:32   ` 2.4.17rc2aa1 Gergely Nagy
  2001-12-25 20:22   ` 2.4.17rc2aa1 - blocking(?) in /proc Adam Schrotenboer
  0 siblings, 2 replies; 11+ messages in thread
From: Andrea Arcangeli @ 2001-12-19 15:16 UTC (permalink / raw)
  To: linux-kernel

This should fix the last loop deadlocks under VM pressure, if not please
let me know.

I didn't fixed the ia64 compilation troubles, but it should be very easy
to fix if anybody needs.

URL:

	ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.17rc2aa1.bz2
	ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.17rc2aa1/

Only in 2.4.17rc1aa1: 00_loop-deadlock-1

	Merged in mainline.

Only in 2.4.17rc2aa1: 00_pgt-cache-leak-1

	Avoid potentially leaking pagetables into the per-cpu queues.

Only in 2.4.17rc2aa1: 00_x86-fast-pte-1

	Reenable the pagetable per-cpu queues on x86 that I found to be
	disabled during 2.4.17pre.

Only in 2.4.17rc1aa1: 10_vm-20
Only in 2.4.17rc2aa1: 10_vm-21

	Drop some leftover and rediffed.

Only in 2.4.17rc1aa1: 60_tux-2.4.16-final-D5.bz2
Only in 2.4.17rc2aa1: 60_tux-2.4.16-final-D6.bz2

	Latest update from Ingo at www.redhat.com/~mingo/ .

Only in 2.4.17rc2aa1: 70_loop-deadlock-2

	Previous fix cured balance_dirty(), this one will cure
	the memory balancing, to avoid reentrant I/O in the loop
	thread.

Andrea

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: 2.4.17rc2aa1
  2001-12-19 15:16 ` 2.4.17rc2aa1 Andrea Arcangeli
@ 2001-12-19 20:32   ` Gergely Nagy
  2001-12-19 20:52     ` 2.4.17rc2aa1 Andrea Arcangeli
  2001-12-25 20:22   ` 2.4.17rc2aa1 - blocking(?) in /proc Adam Schrotenboer
  1 sibling, 1 reply; 11+ messages in thread
From: Gergely Nagy @ 2001-12-19 20:32 UTC (permalink / raw)
  To: Andrea Arcangeli; +Cc: linux-kernel

> This should fix the last loop deadlocks under VM pressure, if not please
> let me know.
> 

Unfortunately, it doesn't. I'll do a SysRq+T and kysmoops combo as
soon as I boot into that kernel again (probably later tonight).

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: 2.4.17rc2aa1
  2001-12-19 20:32   ` 2.4.17rc2aa1 Gergely Nagy
@ 2001-12-19 20:52     ` Andrea Arcangeli
  2001-12-20 18:17       ` 2.4.17rc2aa1 Gergely Nagy
  2001-12-20 18:22       ` 2.4.17rc2aa1 Andrea Arcangeli
  0 siblings, 2 replies; 11+ messages in thread
From: Andrea Arcangeli @ 2001-12-19 20:52 UTC (permalink / raw)
  To: Gergely Nagy; +Cc: linux-kernel

On Wed, Dec 19, 2001 at 09:32:12PM +0100, Gergely Nagy wrote:
> > This should fix the last loop deadlocks under VM pressure, if not please
> > let me know.
> > 
> 
> Unfortunately, it doesn't. I'll do a SysRq+T and kysmoops combo as
> soon as I boot into that kernel again (probably later tonight).

perfect, thanks.

Andrea

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: 2.4.17rc2aa1
  2001-12-19 20:52     ` 2.4.17rc2aa1 Andrea Arcangeli
@ 2001-12-20 18:17       ` Gergely Nagy
  2001-12-21 19:34         ` 2.4.17rc2aa1 Gergely Nagy
  2001-12-20 18:22       ` 2.4.17rc2aa1 Andrea Arcangeli
  1 sibling, 1 reply; 11+ messages in thread
From: Gergely Nagy @ 2001-12-20 18:17 UTC (permalink / raw)
  To: Andrea Arcangeli; +Cc: linux-kernel


[-- Attachment #1.1: Type: text/plain, Size: 1546 bytes --]

The output of ksymoops, and some other miscellaneous information is
attached, as I promised.

The box is an AMD K6-300, with 64Mb memory, and around 130Mb swap
(from which ~110Mb was free, there was no VM pressure). It is running
Debian unstable.

What I did was to boot into my system as usual, then stop all
processes I didn't need. After that, I did a `touch /tmp/foo', then a
`sync'. /tmp is /var/cache/ext3test, despite the filename, it is ext2,
mounted from an ext3 partition (/) (see the output of mount below).

`sync' hung, and the load started to slowly increase, shortly before I
rebooted, it was almost at 3:

 12:02:26 up 6 min,  2 users,  load average: 2.97, 1.81, 0.78

(btw, before doing the `sync', the load was 0.99; with 2.4.14, my
usual load is between 0.20-0.50)

,----[ mount ]
| /dev/hda3 on / type ext3 (rw)
| proc on /proc type proc (rw)
| /dev/hda1 on /boot type ext2 (rw)
| /dev/hdd2 on /gnu type ext2 (rw)
| /dev/hdd1 on /gnu/mnt type ext2 (rw)
| /dev/hda6 on /gnu/work type ext3 (rw)
| /usr/bin/emacs on /bin/emacs type none (rw,bind)
| /gnu/work/cache-apt/archives on /var/cache/apt/archives type none (rw,bind)
| /gnu/work/lib-apt/lists on /var/lib/apt/lists type none (rw,bind)
| /gnu/work/cache-apt/archives on /chroot/base/var/cache/apt/archives type none (rw,bind)
| /gnu/work/lib-apt/lists on /chroot/base/var/lib/apt/lists type none (rw,bind)
| /var/cache/ext3test on /chroot/base/tmp type ext2 (rw,loop=/dev/loop0)
| devfs on /chroot/base/dev type devfs (rw)
| proc on /chroot/base/proc type proc (rw)
`----

[-- Attachment #1.2: ksymoops.log --]
[-- Type: text/plain, Size: 16920 bytes --]

ksymoops 2.4.3 on i586 2.4.17-rc2-aa1.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.17-rc2-aa1/ (default)
     -m /home/local/algernon/src/linux/System.map (specified)

Dec 20 11:59:23 iluvatar kernel: init          S C11E3F24  4836     1      0   503       3       (NOTLB)
Using defaults from ksymoops -t elf32-i386 -a i386
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fcda>] [<c010fc1c>] [<c0138664>] [<c01389fc>] [<c0132326>] 
Dec 20 11:59:23 iluvatar kernel:    [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: keventd       S 00010000  6000     2      1             7       (L-TLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c011ca05>] [<c0105470>] 
Dec 20 11:59:23 iluvatar kernel: ksoftirqd_CPU S C11C2000  6396     3      0             4     1 (L-TLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c011611e>] [<c0105470>] 
Dec 20 11:59:23 iluvatar kernel: kswapd        S C11C0000  6636     4      0             5     3 (L-TLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c012665d>] [<c0105470>] 
Dec 20 11:59:23 iluvatar kernel: bdflush       S 00000286  6548     5      0             6     4 (L-TLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c011029d>] [<c012fb13>] [<c0105470>] 
Dec 20 11:59:23 iluvatar kernel: kupdated      D C11BDF6C  6016     6      0                   5 (L-TLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c012d08c>] [<c012dfa3>] [<c015e5d1>] [<c015e845>] [<c013cb85>] 
Dec 20 11:59:23 iluvatar kernel:    [<c012f971>] [<c012fbf5>] [<c0105470>] 
Dec 20 11:59:23 iluvatar kernel: kjournald     S 00000282  5568     7      1            22     2 (L-TLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c011029d>] [<c015918a>] [<c0158fe0>] [<c0105470>] 
Dec 20 11:59:23 iluvatar kernel: devfsd        S C22CE000  5880    22      1            98     7 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c0162e4d>] [<c01624b2>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: kjournald     S 00000282  2488    97      1           189    98 (L-TLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c011029d>] [<c015918a>] [<c0158fe0>] [<c0105470>] 
Dec 20 11:59:23 iluvatar kernel: loop0         D C25CA868     0    98      1            97    22 (L-TLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010595d>] [<c0105aa8>] [<c01efe73>] [<c0181ac8>] [<c0181fe9>] 
Dec 20 11:59:23 iluvatar kernel:    [<c0105467>] [<c0105470>] 
Dec 20 11:59:23 iluvatar kernel: syslog-ng     S C2AC9F28  5756   189      1           192    97 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c01b095d>] [<c010fcda>] [<c010fc1c>] [<c0138c7c>] [<c0138e7d>] 
Dec 20 11:59:23 iluvatar kernel:    [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: klogd         R C2AA4000  5756   192      1           481   189 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c0112194>] [<c01471b3>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: zsh           S 7FFFFFFF  4920   481      1           482   192 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: zsh           S C2177FB0   884   482      1   657     483   481 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c0105ce7>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF   884   483      1           484   482 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF   396   484      1           485   483 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF     0   485      1           486   484 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF     8   486      1           487   485 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF    12   487      1           488   486 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF     0   488      1           489   487 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF     0   489      1           490   488 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF     0   490      1           491   489 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF     0   491      1           492   490 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF  5488   492      1           493   491 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF  5488   493      1           494   492 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF  5488   494      1           495   493 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF  5488   495      1           496   494 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF  5488   496      1           497   495 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF  5488   497      1           498   496 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF  5488   498      1           499   497 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF  5488   499      1           500   498 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF  5488   500      1           501   499 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF  5488   501      1           502   500 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF  5488   502      1           503   501 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: getty         S 7FFFFFFF  5488   503      1                 502 (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c010fc7f>] [<c016c9ad>] [<c0168b56>] [<c012c3e5>] [<c0106b33>] 
Dec 20 11:59:23 iluvatar kernel: sync          D C3EE8000   596   657    482                     (NOTLB)
Dec 20 11:59:23 iluvatar kernel: Call Trace: [<c013c8db>] [<c013ca9b>] [<c013ccb9>] [<c012d433>] [<c012d46b>] 
Dec 20 11:59:23 iluvatar kernel:    [<c0106b33>] 
Warning (Oops_read): Code line not seen, dumping what data is available

Proc;  init
>>EIP; c11e3f24 <_end+f40070/259c14c>   <=====
Trace; c010fcda <schedule_timeout+72/90>
Trace; c010fc1c <process_timeout+0/4c>
Trace; c0138664 <do_select+1a0/1dc>
Trace; c01389fc <sys_select+334/474>
Trace; c0132326 <sys_stat64+62/70>
Trace; c0106b32 <system_call+32/40>
Proc;  keventd
>>EIP; 00010000 Before first symbol   <=====
Trace; c011ca04 <context_thread+f8/1a0>
Trace; c0105470 <kernel_thread+28/38>
Proc;  ksoftirqd_CPU
>>EIP; c11c2000 <_end+f1e14c/259c14c>   <=====
Trace; c011611e <ksoftirqd+76/b0>
Trace; c0105470 <kernel_thread+28/38>
Proc;  kswapd
>>EIP; c11c0000 <_end+f1c14c/259c14c>   <=====
Trace; c012665c <kswapd+80/c4>
Trace; c0105470 <kernel_thread+28/38>
Proc;  bdflush
>>EIP; 00000286 Before first symbol   <=====
Trace; c011029c <interruptible_sleep_on+3c/50>
Trace; c012fb12 <bdflush+a2/a8>
Trace; c0105470 <kernel_thread+28/38>
Proc;  kupdated
>>EIP; c11bdf6c <_end+f1a0b8/259c14c>   <=====
Trace; c012d08c <__wait_on_buffer+68/88>
Trace; c012dfa2 <bread+42/60>
Trace; c015e5d0 <ext2_update_inode+10c/374>
Trace; c015e844 <ext2_write_inode+c/14>
Trace; c013cb84 <sync_unlocked_inodes+b4/150>
Trace; c012f970 <sync_old_buffers+4/40>
Trace; c012fbf4 <kupdate+dc/100>
Trace; c0105470 <kernel_thread+28/38>
Proc;  kjournald
>>EIP; 00000282 Before first symbol   <=====
Trace; c011029c <interruptible_sleep_on+3c/50>
Trace; c015918a <kjournald+19a/2b8>
Trace; c0158fe0 <commit_timeout+0/c>
Trace; c0105470 <kernel_thread+28/38>
Proc;  devfsd
>>EIP; c22ce000 <_end+202a14c/259c14c>   <=====
Trace; c0162e4c <devfsd_read+f4/3a4>
Trace; c01624b2 <devfs_d_delete+3a/c4>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  kjournald
>>EIP; 00000282 Before first symbol   <=====
Trace; c011029c <interruptible_sleep_on+3c/50>
Trace; c015918a <kjournald+19a/2b8>
Trace; c0158fe0 <commit_timeout+0/c>
Trace; c0105470 <kernel_thread+28/38>
Proc;  loop0
>>EIP; c25ca868 <_end+23269b4/259c14c>   <=====
Trace; c010595c <__down+54/9c>
Trace; c0105aa8 <__down_failed+8/c>
Trace; c01efe72 <stext_lock+ee2/273a>
Trace; c0181ac8 <do_bh_filebacked+58/98>
Trace; c0181fe8 <loop_thread+d0/1d4>
Trace; c0105466 <kernel_thread+1e/38>
Trace; c0105470 <kernel_thread+28/38>
Proc;  syslog-ng
>>EIP; c2ac9f28 <[cdrom].bss.end+26362a/2d4702>   <=====
Trace; c01b095c <sock_poll+20/28>
Trace; c010fcda <schedule_timeout+72/90>
Trace; c010fc1c <process_timeout+0/4c>
Trace; c0138c7c <do_poll+b8/d8>
Trace; c0138e7c <sys_poll+1e0/2e4>
Trace; c0106b32 <system_call+32/40>
Proc;  klogd
>>EIP; c2aa4000 <[cdrom].bss.end+23d702/2d4702>   <=====
Trace; c0112194 <do_syslog+c4/2c8>
Trace; c01471b2 <kmsg_read+e/14>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  zsh
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  zsh
>>EIP; c2177fb0 <_end+1ed40fc/259c14c>   <=====
Trace; c0105ce6 <sys_rt_sigsuspend+e2/100>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  getty
>>EIP; 7ffffffe Before first symbol   <=====
Trace; c010fc7e <schedule_timeout+16/90>
Trace; c016c9ac <read_chan+37c/6d4>
Trace; c0168b56 <tty_read+aa/cc>
Trace; c012c3e4 <sys_read+94/cc>
Trace; c0106b32 <system_call+32/40>
Proc;  sync
>>EIP; c3ee8000 <END_OF_CODE+ce8dc2/????>   <=====
Trace; c013c8da <__wait_on_inode+7e/a0>
Trace; c013ca9a <sync_inodes_sb+19e/1d4>
Trace; c013ccb8 <sync_inodes+34/4c>
Trace; c012d432 <fsync_dev+16/38>
Trace; c012d46a <sys_sync+6/10>
Trace; c0106b32 <system_call+32/40>


1 warning issued.  Results may not be reliable.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: 2.4.17rc2aa1
  2001-12-20 18:17       ` 2.4.17rc2aa1 Gergely Nagy
@ 2001-12-21 19:34         ` Gergely Nagy
  0 siblings, 0 replies; 11+ messages in thread
From: Gergely Nagy @ 2001-12-21 19:34 UTC (permalink / raw)
  To: Andrea Arcangeli; +Cc: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 739 bytes --]

> Not sure what's going on with the i_sem, are you playing with the loopfile
> somehow during the sync?

No. It's sitting in /var/cache/ext3test, and nothing else touches it.

> Can you also try to find more info about c01efe72
> <stext_lock+ee2/273a> with an objdump -j .text.lock? (should be the
> slow path of down() corresponding to the i_sem down in lo_send)

I guess I'm a bit uneducated, but objdump -j .text.lock vmlinux
doesn't work here, I'm obviously doing something wrong.
 
> are you sure it's really related to the loop device? (and not a
> ""genuine"" IDE lockup or something like that)

Yes, I'm sure. Without using the loop device, the system works fine,
as far as I can tell, and even with the loop device, 2.4.14 is OK.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: 2.4.17rc2aa1
  2001-12-19 20:52     ` 2.4.17rc2aa1 Andrea Arcangeli
  2001-12-20 18:17       ` 2.4.17rc2aa1 Gergely Nagy
@ 2001-12-20 18:22       ` Andrea Arcangeli
  2001-12-20 18:27         ` 2.4.17rc2aa1 Linus Torvalds
  1 sibling, 1 reply; 11+ messages in thread
From: Andrea Arcangeli @ 2001-12-20 18:22 UTC (permalink / raw)
  To: Gergely Nagy; +Cc: linux-kernel, Linus Torvalds, Marcelo Tosatti, Andrew Morton

On Wed, Dec 19, 2001 at 09:52:08PM +0100, Andrea Arcangeli wrote:
> On Wed, Dec 19, 2001 at 09:32:12PM +0100, Gergely Nagy wrote:
> > > This should fix the last loop deadlocks under VM pressure, if not please
> > > let me know.
> > > 
> > 
> > Unfortunately, it doesn't. I'll do a SysRq+T and kysmoops combo as
> > soon as I boot into that kernel again (probably later tonight).
> 
> perfect, thanks.

My desktop running rc2aa1 crashed in lo_send a few minutes ago while
testing oom conditions with simultaneous heavy I/O to the loop device,
so I had a chance to fix another bug. Maybe this is what you
experienced, but I also got an oops (maybe you didn't seen the oops
because the machine hanged up?). Just guessing.

Anyways here the fix (untested as usual :)

--- 2.4.17rc2aa1/fs/buffer.c.~1~	Wed Dec 19 03:43:24 2001
+++ 2.4.17rc2aa1/fs/buffer.c	Thu Dec 20 19:02:02 2001
@@ -2337,7 +2337,7 @@
 	struct buffer_head *bh;
 
 	page = find_or_create_page(bdev->bd_inode->i_mapping, index, GFP_NOFS);
-	if (IS_ERR(page))
+	if (!page)
 		return NULL;
 
 	if (!PageLocked(page))
--- 2.4.17rc2aa1/mm/filemap.c.~1~	Wed Dec 19 03:43:23 2001
+++ 2.4.17rc2aa1/mm/filemap.c	Thu Dec 20 19:01:53 2001
@@ -942,7 +942,7 @@
 	spin_unlock(&pagecache_lock);
 	if (!page) {
 		struct page *newpage = alloc_page(gfp_mask);
-		page = ERR_PTR(-ENOMEM);
+		page = NULL;
 		if (newpage) {
 			spin_lock(&pagecache_lock);
 			page = __find_lock_page_helper(mapping, index, *hash);



explanation: grab_cache_page must definitely return NULL in case of oom,
that's the API used by the callers. find_or_create_page can use the same
API as well (there's no point for the ERR_PTR(-ENOMEM) complication).

Andrea

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: 2.4.17rc2aa1
  2001-12-20 18:22       ` 2.4.17rc2aa1 Andrea Arcangeli
@ 2001-12-20 18:27         ` Linus Torvalds
  2001-12-20 18:32           ` 2.4.17rc2aa1 Andrea Arcangeli
  0 siblings, 1 reply; 11+ messages in thread
From: Linus Torvalds @ 2001-12-20 18:27 UTC (permalink / raw)
  To: Andrea Arcangeli
  Cc: Gergely Nagy, linux-kernel, Marcelo Tosatti, Andrew Morton


On Thu, 20 Dec 2001, Andrea Arcangeli wrote:
> Anyways here the fix (untested as usual :)
>
> --- 2.4.17rc2aa1/fs/buffer.c.~1~	Wed Dec 19 03:43:24 2001
> +++ 2.4.17rc2aa1/fs/buffer.c	Thu Dec 20 19:02:02 2001
> @@ -2337,7 +2337,7 @@
>  	struct buffer_head *bh;
>
>  	page = find_or_create_page(bdev->bd_inode->i_mapping, index, GFP_NOFS);
> -	if (IS_ERR(page))
> +	if (!page)

Isn't this in 2.4.17 already? Marcelo, please check.

> +++ 2.4.17rc2aa1/mm/filemap.c	Thu Dec 20 19:01:53 2001
> @@ -942,7 +942,7 @@
>  	spin_unlock(&pagecache_lock);
>  	if (!page) {
>  		struct page *newpage = alloc_page(gfp_mask);
> -		page = ERR_PTR(-ENOMEM);
> +		page = NULL;

Don't be silly, just remove the line (page _is_ NULL already, we just
checked).

		Linus


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: 2.4.17rc2aa1
  2001-12-20 18:27         ` 2.4.17rc2aa1 Linus Torvalds
@ 2001-12-20 18:32           ` Andrea Arcangeli
  2001-12-20 18:35             ` 2.4.17rc2aa1 Linus Torvalds
  0 siblings, 1 reply; 11+ messages in thread
From: Andrea Arcangeli @ 2001-12-20 18:32 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Gergely Nagy, linux-kernel, Marcelo Tosatti, Andrew Morton

On Thu, Dec 20, 2001 at 10:27:37AM -0800, Linus Torvalds wrote:
> 
> On Thu, 20 Dec 2001, Andrea Arcangeli wrote:
> > Anyways here the fix (untested as usual :)
> >
> > --- 2.4.17rc2aa1/fs/buffer.c.~1~	Wed Dec 19 03:43:24 2001
> > +++ 2.4.17rc2aa1/fs/buffer.c	Thu Dec 20 19:02:02 2001
> > @@ -2337,7 +2337,7 @@
> >  	struct buffer_head *bh;
> >
> >  	page = find_or_create_page(bdev->bd_inode->i_mapping, index, GFP_NOFS);
> > -	if (IS_ERR(page))
> > +	if (!page)
> 
> Isn't this in 2.4.17 already? Marcelo, please check.

it isn't in 2.4.17-rc2.

> 
> > +++ 2.4.17rc2aa1/mm/filemap.c	Thu Dec 20 19:01:53 2001
> > @@ -942,7 +942,7 @@
> >  	spin_unlock(&pagecache_lock);
> >  	if (!page) {
> >  		struct page *newpage = alloc_page(gfp_mask);
> > -		page = ERR_PTR(-ENOMEM);
> > +		page = NULL;
> 
> Don't be silly, just remove the line (page _is_ NULL already, we just
> checked).

indeed (compiler could optimize it away but nicer code to delete it).

Andrea

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: 2.4.17rc2aa1
  2001-12-20 18:32           ` 2.4.17rc2aa1 Andrea Arcangeli
@ 2001-12-20 18:35             ` Linus Torvalds
  2001-12-20 19:28               ` 2.4.17rc2aa1 Christoph Hellwig
  0 siblings, 1 reply; 11+ messages in thread
From: Linus Torvalds @ 2001-12-20 18:35 UTC (permalink / raw)
  To: Andrea Arcangeli
  Cc: Gergely Nagy, linux-kernel, Marcelo Tosatti, Andrew Morton


On Thu, 20 Dec 2001, Andrea Arcangeli wrote:
> >
> > Isn't this in 2.4.17 already? Marcelo, please check.
>
> it isn't in 2.4.17-rc2.

Ok, it _is_ in 2.5.x, so I guess this was a fix that I didn't point
Marcelo to well enough..

		Linus


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: 2.4.17rc2aa1
  2001-12-20 18:35             ` 2.4.17rc2aa1 Linus Torvalds
@ 2001-12-20 19:28               ` Christoph Hellwig
  0 siblings, 0 replies; 11+ messages in thread
From: Christoph Hellwig @ 2001-12-20 19:28 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Gergely Nagy, linux-kernel, Marcelo Tosatti, Andrew Morton,
	Andrea Arcangeli

Hi Linus,

In article <Pine.LNX.4.33.0112201034390.1138-100000@penguin.transmeta.com> you wrote:
> Ok, it _is_ in 2.5.x, so I guess this was a fix that I didn't point
> Marcelo to well enough..

I was a bad interaction between Marcelo and me - I send him the incomplete
patch first and then the old one.  It seems like he apllied the first one
and I didn't check which one went in :P


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: 2.4.17rc2aa1 - blocking(?) in /proc
  2001-12-19 15:16 ` 2.4.17rc2aa1 Andrea Arcangeli
  2001-12-19 20:32   ` 2.4.17rc2aa1 Gergely Nagy
@ 2001-12-25 20:22   ` Adam Schrotenboer
  1 sibling, 0 replies; 11+ messages in thread
From: Adam Schrotenboer @ 2001-12-25 20:22 UTC (permalink / raw)
  To: Andrea Arcangeli, linux-kernel

I booted into 2.4.17-rc2aa1(compiled w/ gcc-3.0.3), and after an hour of 
uptime or so, was unable to read anything in /proc (top locked, procinfo, and 
I couldn't kill them b/c killall and pidof would lock as well)

I made only one mod. I changed HZ to 1024, but I don't think that should have 
done it.

I figure either a problem in gcc 3.0.3, or a kernel bug.

Ideas?

---
tabris

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2001-12-25 20:22 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20011221025857.M1477@athlon.random>
2001-12-19 15:16 ` 2.4.17rc2aa1 Andrea Arcangeli
2001-12-19 20:32   ` 2.4.17rc2aa1 Gergely Nagy
2001-12-19 20:52     ` 2.4.17rc2aa1 Andrea Arcangeli
2001-12-20 18:17       ` 2.4.17rc2aa1 Gergely Nagy
2001-12-21 19:34         ` 2.4.17rc2aa1 Gergely Nagy
2001-12-20 18:22       ` 2.4.17rc2aa1 Andrea Arcangeli
2001-12-20 18:27         ` 2.4.17rc2aa1 Linus Torvalds
2001-12-20 18:32           ` 2.4.17rc2aa1 Andrea Arcangeli
2001-12-20 18:35             ` 2.4.17rc2aa1 Linus Torvalds
2001-12-20 19:28               ` 2.4.17rc2aa1 Christoph Hellwig
2001-12-25 20:22   ` 2.4.17rc2aa1 - blocking(?) in /proc Adam Schrotenboer

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.