; > system slowly stops running. One interesting thing is the "ps"
> > > > > command,
> > > > > it gets stuck like this:
> > > >
> > > > Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
> > >
> > > D'oh! I mean 2.
ying with huge pages and libhugetlbfs. Small programs like
> > > > "ls" work fine. I tried running Evolution through libhugetlbfs and the
> > > > system slowly stops running. One interesting thing is the "ps" command,
> > > > it gets stuck like
ot; work fine. I tried running Evolution through libhugetlbfs and the
> > > system slowly stops running. One interesting thing is the "ps" command,
> > > it gets stuck like this:
> >
> > Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
>
> D'oh! I mea
ot; work fine. I tried running Evolution through libhugetlbfs and the
> > > system slowly stops running. One interesting thing is the "ps" command,
> > > it gets stuck like this:
> >
> > Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
>
> D'oh! I mea
Small programs like
> >>> "ls" work fine. I tried running Evolution through libhugetlbfs and the
> >>> system slowly stops running. One interesting thing is the "ps" command,
> >>> it gets stuck like this:
> >> Do you m
tem slowly stops running. One interesting thing is the "ps" command,
it gets stuck like this:
Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
There was a hugepage problem fixed very recently, in 2.6.23-rc1 IIRC.
Actually fixed just after 2.6.23-rc1:
git describe 5ab3ee7b1cd5c91eb2272764f9d7d
ot; work fine. I tried running Evolution through libhugetlbfs and the
> > > system slowly stops running. One interesting thing is the "ps" command,
> > > it gets stuck like this:
> >
> > Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
>
> D'oh! I mea
; > system slowly stops running. One interesting thing is the "ps" command,
> > it gets stuck like this:
>
> Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
>
> There was a hugepage problem fixed very recently, in 2.6.23-rc1 IIRC.
Actually fixed just after 2.6.23-rc1:
system slowly stops running. One interesting thing is the "ps" command,
> > it gets stuck like this:
>
> Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
D'oh! I mean 2.6.23-rc1-mm1, the 22 was a typo. Cut & paste to be
sure:
Linux zephyr 2.6.23-rc1-mm1 #1 SMP PREEMP
nd,
> it gets stuck like this:
Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
There was a hugepage problem fixed very recently, in 2.6.23-rc1 IIRC.
> psD 81001e57ed40 0 103558 103483
> 81001f061dc8 0096 81003d8586e8 81001cbadc00
> 0
I was playing with huge pages and libhugetlbfs. Small programs like
"ls" work fine. I tried running Evolution through libhugetlbfs and the
system slowly stops running. One interesting thing is the "ps" command,
it gets stuck like this:
psD 81001e57ed40 0 103558 103483
8
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 l
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, instin
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 sta
H. Peter Anvin wrote:
> Andy Whitcroft wrote:
>> I think that my debugging says that newsetup got the compressed kernel
>> and decompressor into memory ok and execution passed to it normally.
>> But I cannot figure out where the corruption is coming from. I tried
>> annotating the gzip decompresso
On Thu 2007-05-31 22:46:11, Len Brown wrote:
> On Monday 21 May 2007 08:11, Pavel Machek wrote:
> > On Thu 2007-05-17 18:42:43, Len Brown wrote:
> > > > Something similar happened to me on XE3, yes.
> > > >
> > > > (Actual values were different; BIOS specified critical temperature at
> > > > cca 9
On Mon 2007-06-04 11:02:01, Stefan Seyfried wrote:
> On Thu, May 17, 2007 at 06:35:48PM -0400, Len Brown wrote:
>
> > Yes, SuSE enables polling mode by default, but that is just
> > distro specific "value add" that should eventually be fixed.
>
> I will do that for openSUSE FACTORY.
Well, I sti
On Thu, May 17, 2007 at 06:35:48PM -0400, Len Brown wrote:
> Yes, SuSE enables polling mode by default, but that is just
> distro specific "value add" that should eventually be fixed.
I will do that for openSUSE FACTORY.
--
Stefan Seyfried
QA / R&D Team Mobile Devices| "Any
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.
Thinkpad 600, whenever a trip point i
Andy Whitcroft wrote:
>
> I think that my debugging says that newsetup got the compressed kernel
> and decompressor into memory ok and execution passed to it normally.
> But I cannot figure out where the corruption is coming from. I tried
> annotating the gzip decompressor to see if the input and
Andy Whitcroft wrote:
> Mel Gorman wrote:
>> On Wed, 16 May 2007, H. Peter Anvin wrote:
>>
>>> Correction, does *this patch* do it for you?
>>>
>> With these two patches in combination, previously failing machines
>> elm3b6 (x86_64 on test.kernel.org) and a modern x86 built a kernel and
>> booted c
On Monday 21 May 2007 08:11, Pavel Machek wrote:
> On Thu 2007-05-17 18:42:43, Len Brown wrote:
> > > Something similar happened to me on XE3, yes.
> > >
> > > (Actual values were different; BIOS specified critical temperature at
> > > cca 95C, but hw killed the power at cca 83C. Setting critical
Mel Gorman wrote:
> On Wed, 16 May 2007, H. Peter Anvin wrote:
>
>> Correction, does *this patch* do it for you?
>>
>
> With these two patches in combination, previously failing machines
> elm3b6 (x86_64 on test.kernel.org) and a modern x86 built a kernel and
> booted correctly.
>
> elm3b132 and
rnal source after we've gone and
reset the device?
>
> -Original Message-
> From: Andrew Morton [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 25, 2007 5:00 PM
> To: Greg KH
> Cc: Mattia Dongili; Linux Kernel Mailing List; Hayes, Stuart; David
> Brownell; [EMA
Brownell; [EMAIL PROTECTED]
Subject: Re: [2.6.22-rc1-mm1] ehci-hcd - BUG: scheduling while atomic:
rmmod/0x0001/4568
On Fri, 25 May 2007 14:40:05 -0700 Greg KH <[EMAIL PROTECTED]> wrote:
> On Mon, May 21, 2007 at 11:44:37AM +0900, Mattia Dongili wrote:
> > Hello,
> >
> &g
[EMAIL PROTECTED] (Joseph Fannin) wrote on 05/26/2007 02:29:07 AM:
> On Fri, May 25, 2007 at 10:28:22PM -0400, Reiner Sailer wrote:
> > On Tue, 22 May 2007 03:25:48 -0400
> > [EMAIL PROTECTED] (Joseph Fannin) wrote:
> >
>
> > > I've been getting this since 2.6.21-rc7-mm1:
>
> >
> > Joseph,
On Mon 2007-05-28 13:50:36, Matthew Garrett wrote:
> On Mon, May 28, 2007 at 12:58:51PM +0200, Pavel Machek wrote:
>
> > It would happily occur under Windows. You just needed to load machine
> > in a way that cpu stayed ~80C.
>
> So replace the DSDT. All the problems get solved that way.
We are
On Mon, May 28, 2007 at 12:58:51PM +0200, Pavel Machek wrote:
> It would happily occur under Windows. You just needed to load machine
> in a way that cpu stayed ~80C.
So replace the DSDT. All the problems get solved that way.
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list
Hi!
> > > Because, as Len has pointed out, you end up with two different ideas
> > > about what the trip points are - the kernel's and the hardware's. That
> > > works fine until some event in the firmware either forcibly
> > > resynchronises the two or makes assumptions about the spec-complian
On Fri, May 25, 2007 at 06:38:15AM +, Pavel Machek wrote:
> Hi!
> > Because, as Len has pointed out, you end up with two different ideas
> > about what the trip points are - the kernel's and the hardware's. That
> > works fine until some event in the firmware either forcibly
> > resynchronis
Hi!
>
> > I doubt it is impossible, would you mind sharing your knowledge why you
> > think it is impossible or point to some related discussion, pls.
>
> Because, as Len has pointed out, you end up with two different ideas
> about what the trip points are - the kernel's and the hardware's. Tha
] Modules linked in: thermal processor dm_mod
> > [2.380288] CPU:0
> > [ 2.380289] EIP:0060:[]Not tainted VLI
> > [2.380291] EFLAGS: 00010297 (2.6.22-rc1-mm1 #2)
> > [2.380547] EIP is at vsnprintf+0x448/0x5d0
> > [2.380633] eax: 4400d34
ainted VLI
> [ 2.380291] EFLAGS: 00010297 (2.6.22-rc1-mm1 #2)
> [2.380547] EIP is at vsnprintf+0x448/0x5d0
> [2.380633] eax: 4400d340 ebx: c348f034 ecx: 4400d340 edx:
fffe
> [2.380721] esi: c03e0100 edi: 4400d340 ebp: c357ecc0 esp:
c357ec68
> [2
On Fri, 25 May 2007 14:40:05 -0700 Greg KH <[EMAIL PROTECTED]> wrote:
> On Mon, May 21, 2007 at 11:44:37AM +0900, Mattia Dongili wrote:
> > Hello,
> >
> > with gregkh-usb-usb-ehci-cpufreq-fix.patch removing ehci-hcd causes the
> > following BUG:
>
> Thanks for letting me know.
>
> Stuart, any h
On Mon, May 21, 2007 at 11:44:37AM +0900, Mattia Dongili wrote:
> Hello,
>
> with gregkh-usb-usb-ehci-cpufreq-fix.patch removing ehci-hcd causes the
> following BUG:
Thanks for letting me know.
Stuart, any help here?
thanks,
greg k-h
> [ 459.800033] BUG: scheduling while atomic: rmmod/0x00
Andrew Morton <[EMAIL PROTECTED]> wrote on 05/22/2007 05:23:05 PM:
> On Tue, 22 May 2007 03:25:48 -0400
> [EMAIL PROTECTED] (Joseph Fannin) wrote:
>
> > This comes a bit after IMA bails out successfully, if that's
relevant:
...
> >
> > [1.708761] ima (ima_init): No TPM chip found(rc = -
> > To set it up the user will have to know the parameters and have typed
> > them into the BIOS (if it even has an option for it). I see no problem
>
> Sorry, see no problem which way?
Forcing the user to provide the geometry. Historically that driver dealt
with the main disks the user had. To
On Thu, 24 May 2007 15:11:08 -0700,
"Williams, Dan J" <[EMAIL PROTECTED]> wrote:
> --- a/async_tx/async_memcpy.c
> +++ b/async_tx/async_memcpy.c
> @@ -56,6 +56,7 @@ async_memcpy(struct page *dest, struct page *src,
> unsigned int dest_offset,
> int_en) : NULL;
>
> if (tx) {
Alan Cox wrote:
>> The question I'm asking is: do you think it's better to remove this from
>> hd.c, or do you think it's better to add it back boot code BIOS
>> detection (and take the risk of poking an ST-506 disk with legacy data
>> with parameters which may belong to another disk -- keep in min
> The question I'm asking is: do you think it's better to remove this from
> hd.c, or do you think it's better to add it back boot code BIOS
> detection (and take the risk of poking an ST-506 disk with legacy data
> with parameters which may belong to another disk -- keep in mind this
> can permane
Alan Cox wrote:
> I believe the technical description for the comment is "bullshit" 8)
>
> Almost all MFM controllers and RLL controllers will only run at the
> standard primary and secondary ATA address.
Yes, but that doesn't (necessarily) apply to the controller that is
likely to be the primary
> > It thus needs fixing not removing.
> >
>
> Opinions, anyone (especially Alan):
>
> http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=commitdiff;h=369f16fdd423d79640c4390915e6ab71189cb497
I believe the technical description for the comment is "bullshit" 8)
Almost all MF
Alan Cox wrote:
>
> hd.c can drive MFM and RLL disks and drivers/ide cannot. Although it
> really wants burying further down the config tree the ability to read MFM
> and RLL disks when recovering ancient data is useful and people do
> actually use this driver now and then rescuing stuff like twen
> From: Cornelia Huck [mailto:[EMAIL PROTECTED]
> On Wed, 23 May 2007 10:05:39 +0200,
> Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
>
> > We are trying to get rid of dma-mapping.h, see the last change to
the
> > file with commit 411f0f3edc141a582190d3605cadd1d993abb6df. I don't
think
> > we shou
Alan Cox wrote:
>>> hd.c:(.init.text+0x44a7d): undefined reference to `drive_info'
>>> hd.c:(.init.text+0x44a89): undefined reference to `drive_info'
>>> hd.c:(.init.text+0x44a95): undefined reference to `drive_info'
>>> hd.c:(.init.text+0x44aa1): undefined reference to `drive_info'
>>> hd.c:(.init
On Thu, 2007-05-24 at 15:36 +0100, Matthew Garrett wrote:
> On Thu, May 24, 2007 at 04:16:53PM +0200, Thomas Renninger wrote:
>
> > I doubt it is impossible, would you mind sharing your knowledge why you
> > think it is impossible or point to some related discussion, pls.
>
> Because, as Len has
On Thu, May 24, 2007 at 04:16:53PM +0200, Thomas Renninger wrote:
> I doubt it is impossible, would you mind sharing your knowledge why you
> think it is impossible or point to some related discussion, pls.
Because, as Len has pointed out, you end up with two different ideas
about what the trip
Stripping some CCs, acpi and kernel list should be enough this one goes
to...
On Tue, 2007-05-22 at 01:31 +0100, Matthew Garrett wrote:
> On Tue, May 22, 2007 at 12:42:00AM +0200, Pavel Machek wrote:
> > On Mon 2007-05-21 14:45:53, Matthew Garrett wrote:
> > > So don't do it badly. The advantage o
> > hd.c:(.init.text+0x44a7d): undefined reference to `drive_info'
> > hd.c:(.init.text+0x44a89): undefined reference to `drive_info'
> > hd.c:(.init.text+0x44a95): undefined reference to `drive_info'
> > hd.c:(.init.text+0x44aa1): undefined reference to `drive_info'
> > hd.c:(.init.text+0x44aad):
rench/Austin/[EMAIL PROTECTED]
cc
"Andrew Morton" <[EMAIL PROTECTED]>, David
Kleikamp/Austin/[EMAIL PROTECTED], "Linux Kernel Mailing List"
, Shirish S Pargaonkar/Austin/[EMAIL PROTECTED]
Subject
Re: 2.6.22-rc1-mm1 cifs_mount oops
Hi,
I have one problem about this: af
Hi,
On Wednesday 16 May 2007, Adrian Bunk wrote:
> On Tue, May 15, 2007 at 08:19:14PM -0700, Andrew Morton wrote:
> >...
> > - Added an i386 early-startup development tree, as git-newsetup.patch ("H.
> > Peter Anvin" <[EMAIL PROTECTED]>)
> >...
> > Changes since 2.6.21-mm2:
> >...
> > git-new
Hi,
I have one problem about this: after the srvTcp->tsk is set to NULL
(maybe the thread is still there, isn't it?), is the kthread still
needed to be stopped by calling kthread_stop()? If it is true, then
the task_struct should be saved before send_sig like my patch:
i
> This can end up running kthread_stop() against an already-exited task.
I don't think so since cifs_demultiplex_thread waits sufficiently long
before
exit but after setting srvTcp->tsk to zero (the wait is immediately after
waking up any processes that may be blocked on requests on this socket
On Wed, 23 May 2007 08:28:47 -0500 Steven French <[EMAIL PROTECTED]> wrote:
> Yes - this patch looks better.
>
> I also am not sure whether the send_sig is still necessary to wake up a
> thread blocked in tcp recv_msg (only do a wake_up_process vs. doing a
> send_sig(SIGKILL) )
>
> Unless some
This is what I now have in the cifs git tree. (only minor change is
that I now have since fixed the missing space after the if)
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 216fb62..f6963d1 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2069,8 +2069,15 @@ cifs_mount(struc
t;[EMAIL PROTECTED]>
cc
"Linux Kernel Mailing List" , Steven
French/Austin/[EMAIL PROTECTED]
Subject
Re: 2.6.22-rc1-mm1 cifs_mount oops
On Wed, 23 May 2007 00:50:13 + "young dave"
<[EMAIL PROTECTED]> wrote:
> Hi,
> when I use mount -t cifs , the kernel
Yes - this patch looks better.
I also am not sure whether the send_sig is still necessary to wake up a
thread blocked in tcp recv_msg (only do a wake_up_process vs. doing a
send_sig(SIGKILL) )
Unless someone knows for sure whether the send_sig is redundant, I would
like to merge Shaggy's versi
On Wed, 2007-05-23 at 10:46 +0200, Cornelia Huck wrote:
> Taking a quick look at the async_*.c stuff, the functions in question
> basically seem to be of the form
>
> check_if_we_can_do_it_async();
> if (async_ok) {
> /* do async stuff */
> /* that's where the dma mapping creeps in
On Wed, 23 May 2007 10:05:39 +0200,
Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
> We are trying to get rid of dma-mapping.h, see the last change to the
> file with commit 411f0f3edc141a582190d3605cadd1d993abb6df. I don't think
> we should reintroduce dma related definition but split the async_tx
Hi,
Sorry for the wrong patch in my last post.
How about save the tsk then call kthread_stop like this:
diff -udr linux/fs/cifs/connect.c linux.new/fs/cifs/connect.c
--- linux/fs/cifs/connect.c 2007-05-23 10:59:13.0 +
+++ linux.new/fs/cifs/connect.c 2007-05-23 16:33:54.0
On Tue, 2007-05-22 at 17:25 -0700, Williams, Dan J wrote:
> The approach I have taken is to add the missing definitions to
> include/asm-s390/dma-mapping.h [ a non-outlook-mangled version of the
> patch is pushed out in my rebased git tree ]. I was not able to fully
> compile-test this change as t
Hi,
Yeah, that's racy: once we've sent the signal, the kernel thread can write
NULL to srvTcp->tsk at any time.
Yes, here is another patch :
diff -ur linux/fs/cifs/connect.c linux.new/fs/cifs/connect.c
--- linux/fs/cifs/connect.c 2007-05-23 10:59:13.0 +
+++ linux.new/fs/cifs/c
On Wed, 23 May 2007 02:59:07 + "young dave" <[EMAIL PROTECTED]> wrote:
> Hi,
> maybe we can add if sentence before kthread_stop.
>
> diff -ur linux/fs/cifs/connect.c linux.new/fs/cifs/connect.c
> --- linux/fs/cifs/connect.c 2007-05-23 10:59:13.0 +
> +++ linux.new/fs/cifs/conne
Hi,
maybe we can add if sentence before kthread_stop.
diff -ur linux/fs/cifs/connect.c linux.new/fs/cifs/connect.c
--- linux/fs/cifs/connect.c 2007-05-23 10:59:13.0 +
+++ linux.new/fs/cifs/connect.c 2007-05-23 10:58:39.0 +
@@ -2070,7 +2070,8 @@
s
v6 snd_seq_dummy
> snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
> snd_mixer_oss capability commoncap e100 mii psmouse sg evdev serio_raw
> snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc intel_agp
> agpgart i2c_i801 pcspkr
> CPU:0
> EIP:0060:[]N
Hi,
I have tried the patch, it works.
could you explain it for me? thanks very much.
Regards
dave
2007/5/22, H. Peter Anvin <[EMAIL PROTECTED]>:
Could you try the attached patch for me?
-hpa
diff --git a/arch/i386/boot/edd.c b/arch/i386/boot/edd.c
index 84a0302..9697a56 100644
--- a/a
r snd soundcore snd_page_alloc intel_agp
agpgart i2c_i801 pcspkr
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00210246 (2.6.22-rc1-mm1 #3)
EIP is at kthread_stop+0x10/0x90
eax: c051bde0 ebx: ecx: c1fba000 edx: c1fef040
esi: edi: 0064 ebp: c2a36c80 esp: c1f
> From: Cornelia Huck [mailto:[EMAIL PROTECTED]
> On Fri, 18 May 2007 09:30:09 -0700,
> "Williams, Dan J" <[EMAIL PROTECTED]> wrote:
>
> > When CONFIG_DMA_ENGINE=n async_tx_find_channel takes the form:
> > ... async_tx_find_channel( ... )
> > {
> > return NULL;
> > }
> >
> > So in the S390 cas
On Tue, 2007-05-22 at 20:44 +1000, David Chinner wrote:
>
> > xfs_buf_associate_memory is a mess. My original plan was to get rid
> of
> > it, but I kept that out to keep that patchset small and easily
> reviable,
> > but it seems like that was a mistake. My plan is the following:
> >
> > - xl
On Tue, 2007-05-22 at 17:38 -0500, Matt Mackall wrote:
> [0.120007] EIP is at resync_sc_freq+0x4b/0x56
Hi Matt,
Thanks for the report! Andrew should have these two patches queued,
but here they are again:
If you set tsc_disable (eg "notsc" on cmdline), sched-clock.c gives a
divide b
$ lguest 1024m vmlinux --tunnet=192.168.19.1 --block=rootfs root=/dev/lgba
[0.00] Reserving virtual address space above 0xffc0
[0.00] Linux version 2.6.22-rc1-mm1 ([EMAIL PROTECTED]) (gcc
version 4.1.3 20070429 (prerelease) (Debian 4.1.2-6)) #125 PREEMPT Tue
May 22 16:50:02 CDT
On Tue, 22 May 2007 03:25:48 -0400
[EMAIL PROTECTED] (Joseph Fannin) wrote:
> On Tue, May 15, 2007 at 08:19:14PM -0700, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc1/2.6.22-rc1-mm1/
>
> I've been getting
On Tue, May 15, 2007 at 08:19:14PM -0700, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc1/2.6.22-rc1-mm1/
I've been getting this since 2.6.21-rc7-mm1:
[2.379310] BUG: unable to handle kernel paging request at virtual addres
Hi David,
On 21/05/07, David Chinner <[EMAIL PROTECTED]> wrote:
On Fri, May 18, 2007 at 12:11:14PM +1000, David Chinner wrote:
> On Thu, May 17, 2007 at 10:05:11PM +0200, Michal Piotrowski wrote:
> > I applied your patch and I get another oops
> >
> > [ 261.491499] XFS mounting filesystem loop0
On Tue, May 22, 2007 at 08:44:30PM +1000, David Chinner wrote:
> Perhaps a new field in the xfs_buf structure - that way call paths
> don't need to grow extra parameters and potentially increase
> stack usage. The read path tends to be at the top of the stack
> when it gets blown in the writeback p
On Mon, May 21, 2007 at 12:23:21PM +0200, Christoph Hellwig wrote:
> On Mon, May 21, 2007 at 08:11:42PM +1000, David Chinner wrote:
> > Christoph - this is an interaction with xfs_buf_associate_memory();
> > I'm not sure what it is doing is at all safe now that it never gets
> > passed kmem_alloc()
Matthew Garrett pisze:
.
>
> Try any recent HP bios.
>
Yes...
hp nx 6310, bios version:
F.06. cpufreq works, MFCG Bios Error in dmesg (PCI: BIOS Bug: MCFG area
at f800 is not E820-reserved)
F.08. like above + cpufreq broken
F.09 Remove this errors, but problem with reboot (too long time - r
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 updati
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.
--
Matthew G
Hi!
> > > So don't do it badly. The advantage of doing so is that you can make it
> > > work properly, which you can't by putting it in the kernel.
> >
> > You want stuff like critical shutdowns to work even if userspace is
> > dead.
>
> I don't think anyone suggested putting the critical shutd
Hi,
This implies a miscompile somewhere, *or* that your bios stomps on
registers that gcc expect preserved, and adding printf's disturbs the
register allocation sufficiently.
I think maybe it's caused by gcc optimize, so I add volatile to
read_sector inline assemblly, then kernel can boot succe
On Tue, May 22, 2007 at 12:42:00AM +0200, Pavel Machek wrote:
> On Mon 2007-05-21 14:45:53, Matthew Garrett wrote:
> > So don't do it badly. The advantage of doing so is that you can make it
> > work properly, which you can't by putting it in the kernel.
>
> You want stuff like critical shutdowns
On Mon 2007-05-21 14:45:53, Matthew Garrett wrote:
> On Mon, May 21, 2007 at 03:40:46PM +0200, Pavel Machek wrote:
> > On Mon 2007-05-21 14:36:08, Matthew Garrett wrote:
> > > On Mon, May 21, 2007 at 03:29:48PM +0200, Pavel Machek wrote:
> > > > Significantly more correct? It forces you to do all t
young dave wrote:
> Hi,
>
> kernel booting and stopped in edd.c:read_sector.
>
> I add debug messages around the two inline assemblly sentence, recompile
> kernel,
> now strange thing happend, the kernel booting directly, but the printf
> messages can't be seen because it's too rapid.
>
> can we
On Mon, May 21, 2007 at 03:40:46PM +0200, Pavel Machek wrote:
> On Mon 2007-05-21 14:36:08, Matthew Garrett wrote:
> > On Mon, May 21, 2007 at 03:29:48PM +0200, Pavel Machek wrote:
> > > Significantly more correct? It forces you to do all the thermal
> > > management in userspace!
> >
> > Why's th
On Mon 2007-05-21 14:36:08, Matthew Garrett wrote:
> On Mon, May 21, 2007 at 03:29:48PM +0200, Pavel Machek wrote:
> > > > No. Manually turning off fans is even worse hack.
> > >
> > > It's significantly more correct.
> >
> > Significantly more correct? It forces you to do all the thermal
> > man
On Mon, May 21, 2007 at 03:29:48PM +0200, Pavel Machek wrote:
> > > No. Manually turning off fans is even worse hack.
> >
> > It's significantly more correct.
>
> Significantly more correct? It forces you to do all the thermal
> management in userspace!
Why's that a problem? Overriding the hardw
On Mon, May 21, 2007 at 02:10:48PM +0200, Pavel Machek wrote:
> > nope, the OS can't reliably override the processor passive trip point.
> > That is what _SCP and cooling_mode are for.
>
> Yes, it is reliable if you turn on thermal polling.
As Len says, the system can force a reevaluation of the
Hi!
> > > For folks with the reverse problem -- active cooling where the
> > > fans kick in early than they'd like, they should just turn off
> > > the fans via /proc/acpi/fan and not mess with the trip points at
> > > all.
> >
> > No. Manually turning off fans is even worse hack.
>
> It's signi
On Thu 2007-05-17 18:42:43, Len Brown wrote:
> > Something similar happened to me on XE3, yes.
> >
> > (Actual values were different; BIOS specified critical temperature at
> > cca 95C, but hw killed the power at cca 83C. Setting critical trip
> > point at 80C made the problem go away.)
>
> Great
Hi!
> > > 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/223
On Sun, 2007-05-20 at 23:50 -0400, Len Brown wrote:
> On Saturday 19 May 2007 15:56, Thomas Renninger wrote:
> > 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
> > > >
> > > >
On Mon, May 21, 2007 at 08:11:42PM +1000, David Chinner wrote:
> Christoph - this is an interaction with xfs_buf_associate_memory();
> I'm not sure what it is doing is at all safe now that it never gets
> passed kmem_alloc()d memory - it works for the log recovery case
> because we use it in pairs
On Fri, May 18, 2007 at 12:11:14PM +1000, David Chinner wrote:
> On Thu, May 17, 2007 at 10:05:11PM +0200, Michal Piotrowski wrote:
> > I applied your patch and I get another oops
> >
> > [ 261.491499] XFS mounting filesystem loop0
> > [ 261.501641] Ending clean XFS mount for filesystem: loop0
>
> From: Cornelia Huck [mailto:[EMAIL PROTECTED]
> On Fri, 18 May 2007 09:30:09 -0700,
> "Williams, Dan J" <[EMAIL PROTECTED]> wrote:
>
> > When CONFIG_DMA_ENGINE=n async_tx_find_channel takes the form:
> > ... async_tx_find_channel( ... )
> > {
> > return NULL;
> > }
> >
> > So in the S390 cas
Hi,
kernel booting and stopped in edd.c:read_sector.
I add debug messages around the two inline assemblly sentence, recompile kernel,
now strange thing happend, the kernel booting directly, but the printf
messages can't be seen because it's too rapid.
can we use printk in boot code?
the change
On Fri, 18 May 2007 09:30:09 -0700,
"Williams, Dan J" <[EMAIL PROTECTED]> wrote:
> When CONFIG_DMA_ENGINE=n async_tx_find_channel takes the form:
> ... async_tx_find_channel( ... )
> {
> return NULL;
> }
>
> So in the S390 case the entire asynchronous path will be compiled away.
Unfortunat
Hi,
Could you put printf's in the setup code (especially
arch/i386/boot/main.c) to see how far it runs before it dies?
-hpa
I add some debug info to main.c, the result is that the kernel stopped
in query_edd();
Then I use kernel argument edd=off, the kernel booted happilly.
I will re
young dave wrote:
> Hi,
>
> I tried the vga option , and the selection menu appeared, then I
> select 0(80x25) and nothing happened.
>
OK.
Could you put printf's in the setup code (especially
arch/i386/boot/main.c) to see how far it runs before it dies?
-hpa
-
To unsubscribe from this
Hi,
I tried the vga option , and the selection menu appeared, then I
select 0(80x25) and nothing happened.
2007/5/21, H. Peter Anvin <[EMAIL PROTECTED]>:
young dave wrote:
> Hi,
> My cpu is Intel(R) Pentium(R) D CPU 2.80GHz, below are the lspci
> output and kernel
Could you please try booting
1 - 100 of 202 matches
Mail list logo
