LinuxLists.cc - 2.6.22-rc1-mm1

2007-05-16 12:52:17

by Trond Myklebust

[permalink] [raw]

Subject: Re: (NFS) BUG: at page-writeback.c:829 [Was: 2.6.22-rc1-mm1]

On Wed, 2007-05-16 at 14:10 +0200, Jiri Slaby wrote:
> Andrew Morton napsal(a):
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc1/2.6.22-rc1-mm1/
>
> I've got this in dmesg:
>
> BUG: at /local/xslaby/xxx/mm/page-writeback.c:829 __set_page_dirty_nobuffers()
> [<c010531e>] dump_trace+0x1ce/0x200
> [<c010536a>] show_trace_log_lvl+0x1a/0x30
> [<c0106012>] show_trace+0x12/0x20
> [<c0106086>] dump_stack+0x16/0x20
> [<c015566d>] __set_page_dirty_nobuffers+0x11d/0x130
> [<c0155690>] redirty_page_for_writepage+0x10/0x20
> [<c01938fc>] __block_write_full_page+0x20c/0x330
> [<c0193b0a>] block_write_full_page+0xea/0x100
> [<c0196c82>] blkdev_writepage+0x12/0x20
> [<c015539e>] __writepage+0xe/0x30
> [<c01558c2>] write_cache_pages+0x222/0x340
> [<c0155a03>] generic_writepages+0x23/0x30
> [<c0155a3e>] do_writepages+0x2e/0x50
> [<c018decb>] __writeback_single_inode+0x8b/0x470
> [<c018e75b>] generic_sync_sb_inodes+0x24b/0x470
> [<c018e9a7>] sync_sb_inodes+0x27/0x30
> [<c018ec33>] writeback_inodes+0xb3/0xe0
> [<c01560f2>] wb_kupdate+0x82/0xf0
> [<c015660b>] pdflush+0xeb/0x1b0
> [<c0132e72>] kthread+0x42/0x70
> [<c0104d4b>] kernel_thread_helper+0x7/0x1c
> =======================
> BUG: at /local/xslaby/xxx/mm/page-writeback.c:829 __set_page_dirty_nobuffers()
> [<c010531e>] dump_trace+0x1ce/0x200
> [<c010536a>] show_trace_log_lvl+0x1a/0x30
> [<c0106012>] show_trace+0x12/0x20
> [<c0106086>] dump_stack+0x16/0x20
> [<c015566d>] __set_page_dirty_nobuffers+0x11d/0x130
> [<f8b1fc5b>] nfs_updatepage+0x7b/0x200 [nfs]
> [<f8b156df>] nfs_commit_write+0x2f/0x50 [nfs]
> [<c0150911>] generic_file_buffered_write+0x2a1/0x660
> [<c0150f52>] __generic_file_aio_write_nolock+0x282/0x520
> [<c0151252>] generic_file_aio_write+0x62/0xd0
> [<f8b15def>] nfs_file_write+0xef/0x1c0 [nfs]
> [<c01715e0>] do_sync_write+0xd0/0x110
> [<c0171e04>] vfs_write+0x94/0x130
> [<c017248d>] sys_write+0x3d/0x70
> [<c01040e8>] syscall_call+0x7/0xb
> [<b7eb7b3e>] 0xb7eb7b3e
> =======================
>
> regards,

The first Oops is not NFS: it is some block file system, however the
problem is the same. The crux of the matter would appear to be that some
task is changing the page_mapping() of random pages while the page lock
is held by another task.

Do you see the same thing in mainline?

Trond

2007-05-16 13:01:22

by Trond Myklebust

[permalink] [raw]

Subject: Re: (NFS) BUG: at page-writeback.c:829 [Was: 2.6.22-rc1-mm1]

On Wed, 2007-05-16 at 22:39 +1000, Nick Piggin wrote:
> > =======================
> > BUG: at /local/xslaby/xxx/mm/page-writeback.c:829 __set_page_dirty_nobuffers()
> > [<c010531e>] dump_trace+0x1ce/0x200
> > [<c010536a>] show_trace_log_lvl+0x1a/0x30
> > [<c0106012>] show_trace+0x12/0x20
> > [<c0106086>] dump_stack+0x16/0x20
> > [<c015566d>] __set_page_dirty_nobuffers+0x11d/0x130
> > [<f8b1fc5b>] nfs_updatepage+0x7b/0x200 [nfs]
> > [<f8b156df>] nfs_commit_write+0x2f/0x50 [nfs]
> > [<c0150911>] generic_file_buffered_write+0x2a1/0x660
> > [<c0150f52>] __generic_file_aio_write_nolock+0x282/0x520
> > [<c0151252>] generic_file_aio_write+0x62/0xd0
> > [<f8b15def>] nfs_file_write+0xef/0x1c0 [nfs]
> > [<c01715e0>] do_sync_write+0xd0/0x110
> > [<c0171e04>] vfs_write+0x94/0x130
> > [<c017248d>] sys_write+0x3d/0x70
> > [<c01040e8>] syscall_call+0x7/0xb
> > [<b7eb7b3e>] 0xb7eb7b3e
> > =======================
>
> This one is NFS, setting the page dirty while it is not uptodate. Trond,
> is this because NFS keeps track of dirty regions of the page with private
> data? It might make sense to avoid this warning if PagePrivate is set...
> would that fix the NFS case?

Ah... You put an extra WARN_ON(!PageUptodate(page)). err=-ENOCOFFEE, I
missed that...

So yes, in order to avoid having to read the page in when we just want
to write data, NFS does this kind of tracking. I dunno if your fix to
change it to !PagePrivate(page) && !PageUptodate(page) is right though.
It will indeed fix the NFS case, but the block system uses PagePrivate()
pretty extensively for its own nefarious ends (tracking page buffers).

Trond

2007-05-16 13:07:18

by Nick Piggin

[permalink] [raw]

Subject: Re: (NFS) BUG: at page-writeback.c:829 [Was: 2.6.22-rc1-mm1]

Trond Myklebust wrote:
> On Wed, 2007-05-16 at 22:39 +1000, Nick Piggin wrote:
>
>>> =======================
>>>BUG: at /local/xslaby/xxx/mm/page-writeback.c:829 __set_page_dirty_nobuffers()
>>> [<c010531e>] dump_trace+0x1ce/0x200
>>> [<c010536a>] show_trace_log_lvl+0x1a/0x30
>>> [<c0106012>] show_trace+0x12/0x20
>>> [<c0106086>] dump_stack+0x16/0x20
>>> [<c015566d>] __set_page_dirty_nobuffers+0x11d/0x130
>>> [<f8b1fc5b>] nfs_updatepage+0x7b/0x200 [nfs]
>>> [<f8b156df>] nfs_commit_write+0x2f/0x50 [nfs]
>>> [<c0150911>] generic_file_buffered_write+0x2a1/0x660
>>> [<c0150f52>] __generic_file_aio_write_nolock+0x282/0x520
>>> [<c0151252>] generic_file_aio_write+0x62/0xd0
>>> [<f8b15def>] nfs_file_write+0xef/0x1c0 [nfs]
>>> [<c01715e0>] do_sync_write+0xd0/0x110
>>> [<c0171e04>] vfs_write+0x94/0x130
>>> [<c017248d>] sys_write+0x3d/0x70
>>> [<c01040e8>] syscall_call+0x7/0xb
>>> [<b7eb7b3e>] 0xb7eb7b3e
>>> =======================
>>
>>This one is NFS, setting the page dirty while it is not uptodate. Trond,
>>is this because NFS keeps track of dirty regions of the page with private
>>data? It might make sense to avoid this warning if PagePrivate is set...
>>would that fix the NFS case?
>
>
> Ah... You put an extra WARN_ON(!PageUptodate(page)). err=-ENOCOFFEE, I
> missed that...
>
>
> So yes, in order to avoid having to read the page in when we just want
> to write data, NFS does this kind of tracking. I dunno if your fix to
> change it to !PagePrivate(page) && !PageUptodate(page) is right though.
> It will indeed fix the NFS case, but the block system uses PagePrivate()
> pretty extensively for its own nefarious ends (tracking page buffers).

I think that's OK: the block layer is similarly happy to mark a !uptodate
page dirty if it has buffers, for similar reasons... Anyway, it won't use
this particular path when buffers are attached, and I've put similar
debugging stuff in the set_page_dirty_buffers part.

--
SUSE Labs, Novell Inc.

2007-05-16 14:31:19

by Michal Piotrowski

[permalink] [raw]

Subject: Re: 2.6.22-rc1-mm1

Andrew Morton napisał(a):
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc1/2.6.22-rc1-mm1/
>
>
> - I found some time to look into some writeback problems in
> fs/fs-writeback.c.

This might be related

[ 97.740021] BUG: at /home/devel/linux-mm/mm/page-writeback.c:829 __set_page_dirty_nobuffers()
[ 97.748632] [<c0105276>] dump_trace+0x63/0x1eb
[ 97.753275] [<c0105418>] show_trace_log_lvl+0x1a/0x30
[ 97.758521] [<c010605a>] show_trace+0x12/0x14
[ 97.763042] [<c01060f7>] dump_stack+0x16/0x18
[ 97.767590] [<c01677b3>] __set_page_dirty_nobuffers+0xfe/0x16e
[ 97.773598] [<c0167833>] redirty_page_for_writepage+0x10/0x12
[ 97.779491] [<c01a473a>] __block_write_full_page+0x1dc/0x335
[ 97.785328] [<c01a495c>] block_write_full_page+0xc9/0xd1
[ 97.790799] [<c01a781a>] blkdev_writepage+0x12/0x14
[ 97.795829] [<c01674ea>] __writepage+0xe/0x29
[ 97.800350] [<c01679b8>] write_cache_pages+0x183/0x29a
[ 97.805683] [<c0167af1>] generic_writepages+0x22/0x2a
[ 97.810929] [<c0167b1c>] do_writepages+0x23/0x34
[ 97.815702] [<c019f0a3>] __writeback_single_inode+0x245/0x472
[ 97.821632] [<c019f7e6>] generic_sync_sb_inodes+0x347/0x4cc
[ 97.827379] [<c019f98b>] sync_sb_inodes+0x20/0x24
[ 97.832247] [<c019fb93>] writeback_inodes+0x79/0xc2
[ 97.837296] [<c0168173>] wb_kupdate+0x7a/0xdb
[ 97.841833] [<c01686a0>] pdflush+0xf1/0x189
[ 97.846173] [<c0137d41>] kthread+0x3b/0x62
[ 97.850461] [<c0104e3f>] kernel_thread_helper+0x7/0x10

http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc1-mm1/mm-dmesg
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc1-mm1/mm-config

Regards,
Michal

--
Michal K. K. Piotrowski
Kernel Monkeys
(http://kernel.wikidot.com/start)

2007-05-16 14:37:27

by Nick Piggin

[permalink] [raw]

Subject: Re: 2.6.22-rc1-mm1

Attachments:

nfs-invariant-fix.patch (581.00 B)

2007-05-16 15:19:34

[permalink] [raw]

Subject: Re: 2.6.22-rc1-mm1

On Wed, May 16, 2007 at 01:04:59AM -0700, Andrew Morton wrote:

> > Looks like SAS needs to require CONFIG_ATA...
> >
>
> Yes, but it seems wrong to disable all of libsas if !ATA. Only sas_ata.o
> should depend on that.
>
> Darrick, is there any point in me carrying this tree? It doesn't appear to
> be a hotbed of activity...

Nope. I haven't worked on those bits of code in quite a while, since a
number of scsi/libata reorganizations were discussed at the storage
summit that would make a fair amount of the sas_ata code unnecessary (or
candidates for reworking).

--D

Attachments:

(No filename) (579.00 B)
signature.asc (189.00 B)
Digital signature Download all attachments

2007-05-16 23:34:24

by H. Peter Anvin

[permalink] [raw]

Subject: Re: 2.6.22-rc1-mm1

diff --git a/arch/i386/boot/setup.ld b/arch/i386/boot/setup.ld
index e9ca0c2..c9c5530 100644
--- a/arch/i386/boot/setup.ld
+++ b/arch/i386/boot/setup.ld
@@ -44,5 +44,5 @@ SECTIONS

/DISCARD/ : { *(.note*) }

- ASSERT(_end <= 0x8000, "Setup too big!")
+ . = ASSERT(_end <= 0x8000, "Setup too big!")
}

Attachments:

diff (305.00 B)

Pavel Machek pisze:

> What was the rationale? Can we get this one reverted?
>
> Some machines (HP omnibook xe3) have broken trip points -- too high --
> so machine will overheat and trigger hw shutdown before starting
> passive cooling.
>
> That's really broken, and write to trip points is reasonable way to
> 'fix' that. (I'd understand if you only ever let trip points to
> decrease... but otoh root should be able to shoot himself....)
>
> Pavel

Many people need change trippoints, for example I have:

cat /proc/acpi/thermal_zone/TZ0/trip_points | grep critical
critical (S5): 256 C

I _must_ change it to below 105 C, or edit DSDT table (too difficult to
me). I cannot use this kernel, when trip points are read only.

--
Maciej Rutecki
http://www.unixy.pl
Kernel Monkeys
(http://kernel.wikidot.com/)

Attachments:

smime.p7s (3.19 kB)
S/MIME Cryptographic Signature

2007-05-17 19:11:32

by Len Brown

[permalink] [raw]

Subject: Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]

On Thursday 17 May 2007 09:36, Maciej Rutecki wrote:

> Many people need change trippoints, for example I have:
>
> cat /proc/acpi/thermal_zone/TZ0/trip_points | grep critical
> critical (S5): 256 C
>
> I _must_ change it to below 105 C, or edit DSDT table (too difficult to
> me). I cannot use this kernel, when trip points are read only.

What bad things happen if you leave the critical trip point at 256?
Do you find that you can drive the temperature over 105 and
the system fails to shut down?

-Len

2007-05-17 19:20:15

by Len Brown

[permalink] [raw]

Subject: Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]

On Thursday 17 May 2007 05:23, Pavel Machek wrote:

> > ACPI: thermal trip points are read-only
>
> What was the rationale? Can we get this one reverted?
>
> Some machines (HP omnibook xe3) have broken trip points -- too high --
> so machine will overheat and trigger hw shutdown before starting
> passive cooling.
>
> That's really broken, and write to trip points is reasonable way to
> 'fix' that. (I'd understand if you only ever let trip points to
> decrease... but otoh root should be able to shoot himself....)

No, writing trip-points is neither a fix, nor it is reasonable.
It is a workaround at best, and it is a dangerous and mis-leading hack.

The OS has no capability to actually change the ACPI trip points
that are used by the BIOS. Changing the OS copy of them
to make the user think that trip events will actually
happen when the temperature crosses the OS copy is crazy.

If there are systems with broken thermals and the
ACPI thermal control needs and over-ride to turn
on the fan, then that is fine -- but using
fake trip-points and giving the user the impression
that they are real is not viable.

-Len

2007-05-17 20:05:30

by Michal Piotrowski

[permalink] [raw]

Subject: Re: [xfs-masters] Re: 2.6.22-rc1-mm1

Hi Christoph,

Christoph Hellwig napisał(a):
> On Thu, May 17, 2007 at 12:06:00PM +1000, David Chinner wrote:
>>> static inline int put_page_testzero(struct page *page)
>>> {
>>> VM_BUG_ON(atomic_read(&page->_count) == 0);
>>> return atomic_dec_and_test(&page->_count);
>>> }
>> I haven't seen that one. I expect that it will be the noaddr buffer allocation
>> changes that have triggered this...
>
> Yes. xfs_buf_get_noaddr calls xfs_buf_free to free a buffer when
> something fails. But this is wrong - we want to call xfs_buf_deallocate
> before we setup the page list, and if a page allocation fails we want to
> do out own freeing of just the pages we allocated and call
> _xfs_buf_free_pages. Currently we do our own freeing _and_ call
> xfs_buf_free which leads to this double free.
>
>
> Signed-off-by: Christoph Hellwig <[email protected]>
>
>
> Index: linux-2.6/fs/xfs/linux-2.6/xfs_buf.c
> ===================================================================
> --- linux-2.6.orig/fs/xfs/linux-2.6/xfs_buf.c 2007-05-17 09:34:44.000000000 +0200
> +++ linux-2.6/fs/xfs/linux-2.6/xfs_buf.c 2007-05-17 09:36:53.000000000 +0200
> @@ -792,8 +792,9 @@ xfs_buf_get_noaddr(
> fail_free_mem:
> while (--i >= 0)
> __free_page(bp->b_pages[i]);
> + _xfs_buf_free_pages(bp);
> fail_free_buf:
> - xfs_buf_free(bp);
> + xfs_buf_deallocate(bp);
> fail:
> return NULL;
> }

I applied your patch and I get another oops

[ 261.491499] XFS mounting filesystem loop0
[ 261.501641] Ending clean XFS mount for filesystem: loop0
[ 261.507698] SELinux: initialized (dev loop0, type xfs), uses xattr
[ 261.567441] XFS mounting filesystem loop0
[ 261.573931] allocation failed: out of vmalloc space - use vmalloc=<size> to increase size.
[ 261.582935] xfs_buf_get_noaddr: failed to map pages
[ 261.592478] Ending clean XFS mount for filesystem: loop0
[ 261.618543] SELinux: initialized (dev loop0, type xfs), uses xattr
[ 261.691563] XFS mounting filesystem loop0
[ 261.698927] allocation failed: out of vmalloc space - use vmalloc=<size> to increase size.
^^^^^^^^^^^^^^^^^^^^
interesting

[ 261.724829] xfs_buf_get_noaddr: failed to map pages
[ 261.734049] Ending clean XFS mount for filesystem: loop0
[ 261.741069] SELinux: initialized (dev loop0, type xfs), uses xattr
[ 261.978728] XFS mounting filesystem loop0
[ 262.205863] xfs_buf_get_noaddr: failed to map pages
[ 262.212523] Ending clean XFS mount for filesystem: loop0
[ 262.218084] SELinux: initialized (dev loop0, type xfs), uses xattr
[..]
[ 265.842566] xfs_buf_get_noaddr: failed to map pages
[ 265.848267] xfs_buf_get_noaddr: failed to map pages
[ 265.856480] Ending clean XFS mount for filesystem: loop0
[ 265.862260] SELinux: initialized (dev loop0, type xfs), uses xattr
[ 265.921288] XFS mounting filesystem loop0
[ 265.927123] xfs_buf_get_noaddr: failed to map pages
[ 265.932575] BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 265.942886] printing eip:
[ 265.945665] fdc8e82a
[ 265.948818] *pde = 00000000
[ 265.952378] Oops: 0002 [#1]
[ 265.955241] PREEMPT SMP
[ 265.957868] Modules linked in: xfs loop ipt_MASQUERADE iptable_nat nf_nat autofs4 af_packet nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink iptable_filter ip_tables ip6t_REJECT xt_tcpudp ip6table_filter ip6_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm evdev intel_agp agpgart snd_timer snd soundcore snd_page_alloc i2c_i801 ide_cd cdrom rtc unix
[ 266.007064] CPU: 0
[ 266.007065] EIP: 0060:[<fdc8e82a>] Not tainted VLI
[ 266.007066] EFLAGS: 00010246 (2.6.22-rc1-mm1 #5)
[ 266.019641] EIP is at xfs_buf_cond_lock+0x8/0x1f [xfs]
[ 266.024853] eax: 00000000 ebx: ce3e9100 ecx: 00000000 edx: 00000001
[ 266.031768] esi: ccf8b628 edi: ccf8b5d8 ebp: d04beb20 esp: d04beb20
[ 266.038692] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
[ 266.044615] Process mount (pid: 7206, ti=d04be000 task=cdcb74f0 task.ti=d04be000)
[ 266.052090] Stack: d04beb60 fdc75a12 00000005 fdc99174 00080020 00000000 ccf72c70 c992e5b0
[ 266.060680] ccf8b6f0 00000007 c0875244 00000000 d04beb70 00080020 00000000 c992e5b0
[ 266.069247] d04beb90 fdc75cd1 00080020 00000000 00002580 fdc8ccda c992e5f0 c992e5b0
[ 266.077866] Call Trace:
[ 266.080611] [<fdc75a12>] xlog_alloc_log+0x1b9/0x2cd [xfs]
[ 266.086286] [<fdc75cd1>] xfs_log_mount+0x6b/0xf1 [xfs]
[ 266.091688] [<fdc7ec47>] xfs_mountfs+0x959/0xc4a [xfs]
[ 266.097097] [<fdc714f6>] xfs_ioinit+0x26/0x2c [xfs]
[ 266.102240] [<fdc85692>] xfs_mount+0x2e5/0x358 [xfs]
[ 266.107474] [<fdc95b72>] vfs_mount+0x1a/0x1e [xfs]
[ 266.112563] [<fdc95a2c>] xfs_fs_fill_super+0x76/0x1a2 [xfs]
[ 266.118433] [<c0185987>] get_sb_bdev+0x105/0x143
[ 266.123260] [<fdc94d63>] xfs_fs_get_sb+0x21/0x27 [xfs]
[ 266.128709] [<c0185509>] vfs_kern_mount+0x81/0xf1
[ 266.133589] [<c0199b59>] do_mount+0x716/0x80d
[ 266.138145] [<c0199cd0>] sys_mount+0x80/0xb5
[ 266.142595] [<c01041d0>] syscall_call+0x7/0xb
[ 266.147170] [<b7fe6410>] 0xb7fe6410
[ 266.150822] =======================
[ 266.154445] INFO: lockdep is turned off.
[ 266.158411] Code: be 20 00 00 00 89 f2 29 c2 83 c8 ff 88 d1 d3 e0 29 de 89 f1 d3 e8 5b 5e 5d c3 55 89 e5 90 ff 40 7c 5d c3 55 89 e5 89 c1 31 c0 90 <ff> 09 79 07 8d 01 e8 d7 17 6c c2 83 f8 01 19 c0 f7 d0 83 e0 f0
[ 266.178534] EIP: [<fdc8e82a>] xfs_buf_cond_lock+0x8/0x1f [xfs] SS:ESP 0068:d04beb20
[ 266.347522] XFS: Filesystem loop1 has duplicate UUID - can't mount
[ 266.415823] XFS: Filesystem loop1 has duplicate UUID - can't mount
[ 266.477997] XFS: Filesystem loop1 has duplicate UUID - can't mount
[ 266.541940] XFS: Filesystem loop1 has duplicate UUID - can't mount

http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc1-mm1/mm-dmesg3
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc1-mm1/mm-config

Regards,
Michal

--
Michal K. K. Piotrowski
Kernel Monkeys
(http://kernel.wikidot.com/start)

2007-05-17 20:09:36

by Maciej Rutecki

[permalink] [raw]

Subject: Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]

Len Brown pisze:

> What bad things happen if you leave the critical trip point at 256?
> Do you find that you can drive the temperature over 105 and
> the system fails to shut down?
>
> -Len
>
>

It isn't problem in this case (nx6310). But on hp nc nc6220 first trip
point is at 30 *C, so fan is usually on (noise, power consumption).

--
Maciej Rutecki
http://www.unixy.pl
Kernel Monkeys
(http://kernel.wikidot.com/)

Attachments:

smime.p7s (3.19 kB)
S/MIME Cryptographic Signature

2007-05-17 20:42:24

On Thu, 2007-05-17 at 15:17 -0400, Len Brown wrote:
> On Thursday 17 May 2007 05:23, Pavel Machek wrote:
>
> > > ACPI: thermal trip points are read-only
> >
> > What was the rationale? Can we get this one reverted?
> >
> > Some machines (HP omnibook xe3) have broken trip points -- too high --
> > so machine will overheat and trigger hw shutdown before starting
> > passive cooling.
> >
> > That's really broken, and write to trip points is reasonable way to
> > 'fix' that. (I'd understand if you only ever let trip points to
> > decrease... but otoh root should be able to shoot himself....)
>
> No, writing trip-points is neither a fix, nor it is reasonable.
> It is a workaround at best, and it is a dangerous and mis-leading hack.
Yes it is a workaround for critical ACPI bugs like that or similar:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/22336

It's also convenient to e.g. lower passive trip point to avoid fan
noise.

Some people are used to it, I already wanted to write a little userspace
prog to use them as it is really easy to fake cooling_mode (trip points
are modified by BIOS) and eliminate fan noise and other things by e.g.
reducing passsive or whatever trip point.

This is at least a major sysfs interface change, has this been discussed
somewhere before or declared deprecated?

It's there for a long time, why is this "a dangerous and mis-leading
hack." now?

I'd suggest to revert this and I can come with something like "only
allow lower values
than BIOS provides" patch if the current implementation is considered
dangerous.

Thomas

> The OS has no capability to actually change the ACPI trip points
> that are used by the BIOS. Changing the OS copy of them
> to make the user think that trip events will actually
> happen when the temperature crosses the OS copy is crazy.
>
> If there are systems with broken thermals and the
> ACPI thermal control needs and over-ride to turn
> on the fan, then that is fine -- but using
> fake trip-points and giving the user the impression
> that they are real is not viable.

2007-05-20 10:13:13

2007-05-22 09:29:53

by Goulven Guillard

[permalink] [raw]

Subject: Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]

Le 05/22/2007 11:16 AM, Matthew Garrett a d?clar? :
> On Tue, May 22, 2007 at 11:06:36AM +0200, Pavel Machek wrote:
>
>> We need to ignore trip point updates from BIOS, and we need to poll
>> thermals when use overrides trip points. That's expected. Plus I've
>> yet to see platform actually updating the trip points.
>
> Try any recent HP bios.
>

man cron... ;-)

--
~~
|Oo| La banquise fond !!! Adoptez un pingouin...
/|\/|\
|__| => http://doc.ubuntu-fr.org/
^__^
~~~| |~~~

2007-05-22 10:05:58

Andy Whitcroft wrote:
> H. Peter Anvin wrote:
>> Andy Whitcroft wrote:
>>>> It definitely sounds like a memory clobber of some sort.
>>>>
>>>> Usual suspects, in addition to the input/output buffers you already
>>>> looked at, would be the heap and the stack. Finding where the stack
>>>> pointer lives would be my first, instinctive guess.
>>> The stack seems to be where it should be and seems to stay pretty much
>>> in the same place as it should. Adding checks for the heap also seem to
>>> stay within bounds. I've tried making the stack and the heap 64k to no
>>> effect.
>>>
>>> Moving the kernel to other places in memory seems to kill the decode
>>> completely during gunzip() which may be a hint I am not sure.
>>>
>>> This thing is trying to ruin my mind.
>>>
>> Yours and mine both. Seems like *something* is clobbering memory, but
>> what and why is a mystery. The fact that putting the kernel in a higher
>> point in memory is a good indication that this clobber is at a
>> relatively high address.
>>
>> How much RAM does this machine have?
>
> This is as 12GB machine. 3 numa nodes.
>
> I checked out the location of the IDT and GDT and both seem sane, in the
> 9xxxx range below the kernel destination.
>
> I also note that on another machine of this type, one Node only in that
> case some of the "did work" cases do not work. Also when I applied some
> of my patches on the top "working" cases stopped working. So whatever
> it is is definatly related to the shape of the kernel to be loaded.
> Very confusing.

Ok, in fact when the kernel is moved elsewhere in the address space it
will decode properly. There was a check in there for not loading at the
right address which was catching me out ... as errors do not show up as
we have no serial support. Doh.

Once I had gotten this decoding at other addresses I simply tried moving
the base address for the kernel elsewhere. I am able to successfully
boot the kernel at 16MB and 256MB. This seems like something outside
the decoder scribbling.

I would not normally recommend moving the base address of the kernel.
However, this problem at least so far has only shown up on the NUMA-Q
platform which is at best described as a very small volume
sub-architecture. There are areas in which it differers from mainstream
BIOS and we are no longer able to get details of these differences.

We actually have no proof as yet this is or is not a NUMA-Q specific
problem. For instance these machines tend to run less modules and more
builtin stuff than the average due to an owner dislike of modules. So
we could have a lurking kernel size issue or similar.

I am therefore proposing change the base address for NUMA-Q only (patch
to follow this email). And that we remain aware of the issue and on the
lookout for similar breakage on mainstream x86 platforms. At least with
this patch we can get wider testing on the rest of the kernel.

-apw