Hi!
> > I should take some sleep now, so I can't test the patch, but I don't
> > think it will help. If someone has PF_FREEZE set, he should be in
> > refrigerator.
>
> OK, so if that doesn't help, here's an alternate approach - this
> lets xfsbufd track when its entering the refrigerator(), so t
Hi,
On Tuesday, 12 of April 2005 01:51, Pavel Machek wrote:
]--snip--[
> > Since the refrigerator() call is in place in the main xfsbufd loop,
> > I suspect we're hitting that second case here, where a low memory
> > situation is resulting in someone attempting to wakeup xfsbufd --
> > I'm not su
On Tue, Apr 12, 2005 at 01:04:25PM +0200, Pavel Machek wrote:
> > OK, so if that doesn't help, here's an alternate approach - this
> > lets xfsbufd track when its entering the refrigerator(), so that
> > other callers know that attempts to wake it are futile.
>
> Thanks, this patch helped.
I can
On Tue, Apr 12, 2005 at 01:51:10AM +0200, Pavel Machek wrote:
> I should take some sleep now, so I can't test the patch, but I don't
> think it will help. If someone has PF_FREEZE set, he should be in
> refrigerator.
OK, so if that doesn't help, here's an alternate approach - this
lets xfsbufd tra
Hi!
> > > > > No, XFS is my root filesystem. :( (Now that I think about it, would
> > > > > modularizing XFS and using an initrd be OK?)
> > > >
> > > > Yes, loading xfs from initrd should help. [At least it did during
> > > > suse9.3 testing.]
> > >
> > > Once I modularized xfs and switched to
On Mon, Apr 11, 2005 at 12:57:59PM +0200, Pavel Machek wrote:
> Hi!
>
> > > > No, XFS is my root filesystem. :( (Now that I think about it, would
> > > > modularizing XFS and using an initrd be OK?)
> > >
> > > Yes, loading xfs from initrd should help. [At least it did during
> > > suse9.3 testin
Hi!
> > > No, XFS is my root filesystem. :( (Now that I think about it, would
> > > modularizing XFS and using an initrd be OK?)
> >
> > Yes, loading xfs from initrd should help. [At least it did during
> > suse9.3 testing.]
>
> Once I modularized xfs and switched to using an initrd, the problem
Barry K. Nathan wrote:
> On Sun, Apr 10, 2005 at 11:27:47PM +0200, Pavel Machek wrote:
>> Can you try without XFS?
>
> No, XFS is my root filesystem. :( (Now that I think about it, would
> modularizing XFS and using an initrd be OK?)
Yes, although it is not totally trivial.
> I'll see if I can r
On Mon, Apr 11, 2005 at 01:00:53AM +0200, Pavel Machek wrote:
> > No, XFS is my root filesystem. :( (Now that I think about it, would
> > modularizing XFS and using an initrd be OK?)
>
> Yes, loading xfs from initrd should help. [At least it did during
> suse9.3 testing.]
Once I modularized xfs a
Hi!
> > Can you try without XFS?
>
> No, XFS is my root filesystem. :( (Now that I think about it, would
> modularizing XFS and using an initrd be OK?)
Yes, loading xfs from initrd should help. [At least it did during
suse9.3 testing.]
> I'll see if I can reproduce this on one of my test boxes.
On Sun, Apr 10, 2005 at 11:27:47PM +0200, Pavel Machek wrote:
> Can you try without XFS?
No, XFS is my root filesystem. :( (Now that I think about it, would
modularizing XFS and using an initrd be OK?)
I'll see if I can reproduce this on one of my test boxes. I'll *try* to
get to it later today,
Hi!
> (Sorry I took so long to respond. I was busy with tons of stuff
> offline...)
>
> On Fri, Apr 08, 2005 at 12:33:27PM +0200, Pavel Machek wrote:
> > Do you have XFS compiled in, by chance?
>
> Yes.
Can you try without XFS?
I do not why it interferes, but I've seen that before on suse
kern
(Sorry I took so long to respond. I was busy with tons of stuff
offline...)
On Fri, Apr 08, 2005 at 12:33:27PM +0200, Pavel Machek wrote:
> Do you have XFS compiled in, by chance?
Yes.
> You are not actually resuming from initrd, right?
That is correct.
-Barry K. Nathan <[EMAIL PROTECTED]>
-
T
Hi!
> > > Ok, I've narrowed the problem down to one patch. In 2.6.11-mm3, the
> > > problem goes away if I remove this patch:
> > > swsusp-enable-resume-from-initrd.patch
> >
> > That really helps, thanks.
>
> You're welcome.
>
> > The patch looks fairly innocent. I'll give up on this and cc t
On Thu, 2005-04-07 at 18:08 -0700, Siddha, Suresh B wrote:
> On Thu, Apr 07, 2005 at 03:11:12AM +1000, Nick Piggin wrote:
> > Using the attached patch, a puny dual PIII-650 with ~400MB RAM swapped
> > itself to death after 2 infinite loop tasks had been pinned to one
> > of the CPUs. See how yo
On Thu, Apr 07, 2005 at 03:11:12AM +1000, Nick Piggin wrote:
> Using the attached patch, a puny dual PIII-650 with ~400MB RAM swapped
> itself to death after 2 infinite loop tasks had been pinned to one
> of the CPUs. See how you go.
Its goes well beyond the initial 7000 number I mentioned. Th
On Thu, Apr 07, 2005 at 01:58:45AM -0700, Andrew Morton wrote:
> > I'm having problems with 1394 in 2.6.12-rc2-mm1. When I connect my
> > Apple iSight camera, it is not detected; repeated
> > connections/disconnections don't help. When I tried to rmmod all the
> > appropriate modules (rmmod v
Hi Andrew,
Le Tuesday 05 April 2005 09:45, Andrew Morton a écrit :
> Brice Goglin <[EMAIL PROTECTED]> wrote:
> > Andrew Morton a écrit :
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.
> > >12-rc2/2.6.12-rc2-mm1/
> >
> > Hi Andrew,
> >
> > printk timing seems broken.
>
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
> I'm having problems with 1394 in 2.6.12-rc2-mm1. When I connect my
> Apple iSight camera, it is not detected; repeated
> connections/disconnections don't help. When I tried to rmmod all the
> appropriate modules (rmmod video1394 raw1394 ohci13
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/
>
> - x86 NMI handling seems to be bust in 2.6.12-rc2. Try using
> `nmi_watchdog=0' if you experience weird crashes.
>
> - The possible kernel-timer related hangs might possibly be f
On Wed, Apr 06, 2005 at 08:06:14PM -0700, Barry K. Nathan wrote:
> > > BTW, there's another strange thing that's introduced by 2.6.11-rc2-mm1:
> > > With that kernel, suspend is also ridiculously slow (speed is comparable
> > > to the slow resume with the aforementioned patch). 2.6.11-rc2 does not
On Wed, Apr 06, 2005 at 02:27:49PM -0700, Andrew Morton wrote:
> "Barry K. Nathan" <[EMAIL PROTECTED]> wrote:
> >
> > Ok, I've narrowed the problem down to one patch. In 2.6.11-mm3, the
> > problem goes away if I remove this patch:
> > swsusp-enable-resume-from-initrd.patch
>
> That really helps,
On Tuesday 05 April 2005 03:05, Andrew Morton wrote:
> - x86 NMI handling seems to be bust in 2.6.12-rc2. Try using
> `nmi_watchdog=0' if you experience weird crashes.
>
> - The possible kernel-timer related hangs might possibly be fixed. We
> haven't heard yet.
>
> - Nobody said anything a
Neil Brown <[EMAIL PROTECTED]> wrote:
>
> On Tuesday April 5, [EMAIL PROTECTED] wrote:
> >
> > - Nobody said anything about the PM resume and DRI behaviour in
> > 2.6.12-rc1-mm4. So it's all perfect now?
>
> Well, Seeing you asked...
>
> PM resume certainly seems to be improving.
> My main pr
Jindrich Makovicka <[EMAIL PROTECTED]> wrote:
>
> oes not compile on AthlonXP. For mmx_clear_page, only the prototype was
> changed, but the implementation is still the same. I guess that part of
> the patch slipped out somehow.
>
> -extern void mmx_clear_page(void *page);
>
> +extern void mmx_cl
"Barry K. Nathan" <[EMAIL PROTECTED]> wrote:
>
> Ok, I've narrowed the problem down to one patch. In 2.6.11-mm3, the
> problem goes away if I remove this patch:
> swsusp-enable-resume-from-initrd.patch
That really helps, thanks.
The patch looks fairly innocent. I'll give up on this and cc the
de
Steven Cole <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
> > Steven Cole <[EMAIL PROTECTED]> wrote:
> >
> >>arch/i386/kernel/setup.c: In function 'setup_arch':
> >> arch/i386/kernel/setup.c:1571: warning: implicit declaration of function
> >> 'acpi_boot_table_init'
> >> arch/i386/kernel/se
On Wed, 2005-04-06 at 14:21 +0100, Sean Neakums wrote:
> Using your glib sample thingy from
> http://www.kernel.org/pub/linux/kernel/people/rml/inotify/glib/
Thanks. It was a bug in the glib utility, not inotify itself.
I fixed it in inotify-glib-0.0.2, which should appear at the above URL
as s
Siddha, Suresh B wrote:
On Tue, Apr 05, 2005 at 05:33:49PM +1000, Nick Piggin wrote:
Lastly, I'd like to be a bit less intrusive with pinned task
handling improvements. I think we can do this while still being
effective in preventing livelocks.
We want to see this fixed. Please post your patch an
Andrew Morton wrote:
Steven Cole <[EMAIL PROTECTED]> wrote:
arch/i386/kernel/setup.c: In function 'setup_arch':
arch/i386/kernel/setup.c:1571: warning: implicit declaration of function
'acpi_boot_table_init'
arch/i386/kernel/setup.c:1572: warning: implicit declaration of function
'acpi_boot_init'
On Tue, Apr 05, 2005 at 05:56:00PM -0700, Andrew Morton wrote:
> > I'll see if I can isolate it any further.
>
> Please, that would help.
[Right now I'm in a race against my lack of sleep. I'm trying to send
this e-mail before I involuntarily fall asleep, so the contents
and/or recipient list may
Ingo Molnar a écrit :
weird - none of the WARN_ON(1)'s show up. In particular, the
sched_clock() ones should have triggered at least once! I've attached a
new version of the patch below (please unapply the previous patch),
could you try it and send me the log? (It will unconditionally print
so
On Tue, Apr 05, 2005 at 05:56:00PM -0700, Andrew Morton wrote:
> Odd.
Yes, it is odd...
> > 2.6.11-bk9 works (actually it takes under 2 seconds, not 5-10).
> > 2.6.11-bk10 has the weird slowdown.
>
> Unfortunately that's a pretty bug diff (2 megs).
Yeah, I know. *sigh*
[snip]
> but you'd be ge
>@Len:
>ACPI=y and ACPI_BOOT=n seems to be a legal configuration (with
>X86_HT=y), but it breaks into pieces if you try the compilation.
yeah, don't do that:-)
I'm sorry I didn't push the patch to delete CONFIG_ACPI_BOOT earlier.
For now, just enable them both.
thanks,
-Len
-
To unsubscribe from
On April 5, 2005 09:22 pm, Berck E. Nash wrote:
> 2.6.12-rc2-mm1 fails to build for me with the following error:
>
> arch/i386/lib/mmx.c:374: error: conflicting types for `mmx_clear_page'
> include/asm/mmx.h:11: error: previous declaration of `mmx_clear_page'
> make[1]: *** [arch/i386/lib/mmx.o] E
On Tuesday April 5, [EMAIL PROTECTED] wrote:
>
> - Nobody said anything about the PM resume and DRI behaviour in
> 2.6.12-rc1-mm4. So it's all perfect now?
Well, Seeing you asked...
PM resume certainly seems to be improving.
My main problem in rc1-mm3 is with PCMCIA.
If I stop cardmgr before
Steven Cole <[EMAIL PROTECTED]> wrote:
>
> arch/i386/kernel/setup.c: In function 'setup_arch':
> arch/i386/kernel/setup.c:1571: warning: implicit declaration of function
> 'acpi_boot_table_init'
> arch/i386/kernel/setup.c:1572: warning: implicit declaration of function
> 'acpi_boot_init'
diff
"Barry K. Nathan" <[EMAIL PROTECTED]> wrote:
>
> On Tue, Apr 05, 2005 at 06:44:08AM -0700, Barry K. Nathan wrote:
> > swsusp: reading slkf;jalksfsadflkjas;dlfasdfkl (12345 pages): 34%
> > [sorry, I just got up so my short-term memory isn't working that well
> > yet]
> >
> > takes 10-30 minutes (de
Siddha, Suresh B wrote:
On Tue, Apr 05, 2005 at 05:33:49PM +1000, Nick Piggin wrote:
Suresh's underlying problem with the unnecessary sched domains
is a failing of sched-balance-exec and sched-balance-fork, which
That wasn't the only motivation. For example, on non-HT cpu's we shouldn't
be settin
On Tue, Apr 05, 2005 at 07:14:45AM -0700, Barry K. Nathan wrote:
> 2.6.11-bk9 works (actually it takes under 2 seconds, not 5-10).
> 2.6.11-bk10 has the weird slowdown.
>
> I'll see if I can isolate it any further.
2.6.11-mm2 works, but 2.6.11-mm3 has the ridiculously slow resumes.
Later today I
On Tue, Apr 05, 2005 at 05:45:58PM +0200, Jan Dittmer wrote:
> Something has broken make O= :
>
> HOSTCC scripts/kallsyms
> HOSTCC scripts/conmakehash
> make[1]: *** No rule to make target `include/asm', needed by
> `arch/alpha/kernel/asm-offsets.s'. Stop.
> make: *** [_all] Error 2
>
> H
Adrian Bunk wrote:
On Wed, Apr 06, 2005 at 12:32:52AM +1200, Reuben Farrelly wrote:
Hi again
At 12:14 a.m. 6/04/2005, Adrian Bunk wrote:
On Tue, Apr 05, 2005 at 08:34:11PM +1200, Reuben Farrelly wrote:
Hi,
Hi Reuben,
...
Hrm. Something changed between the last -mm release which compiled
through,
On Tue, Apr 05, 2005 at 05:33:49PM +1000, Nick Piggin wrote:
> Andrew Morton wrote:
>
> > +sched-remove-unnecessary-sched-domains.patch
> > +sched-improve-pinned-task-handling-again.patch
> [snip]
> >
> > CPU scheduler updates
> >
>
> It is no problem that you picked these up for testing. But
* Brice Goglin <[EMAIL PROTECTED]> wrote:
> >could you send the full bootlog (starting at the 'gcc...' line)? I'm not
> >sure whether TSC calibration was done on your CPU. If cyc2ns_scale is
> >not set up then sched_clock() will return 0, and this could result in
> >that printk symptom.
>
> H
Hi Andrew,
> - Nobody said anything about the PM resume and DRI behaviour in
> 2.6.12-rc1-mm4. So it's all perfect now?
Yes, works for me. DRI (i915) is working again and USB is now happy
after a PM resume too.
signature.asc
Description: This is a digitally signed message part
On Tue, 2005-04-05 at 08:45 +0100, Christoph Hellwig wrote:
> This introduces various AUDIT_ARCH numerical constants, which is a blatantly
> stupid idea. We already have a way to uniquely identify architectures, and
> that's the ELF headers, no need for another parallel namespace.
We do use the E
> bk-kbuild.patch
Something has broken make O= :
$ make mrproper
$ mkdir /tmp/42
$ make ARCH=alpha CROSS_COMPILE=alpha-linux- O=/tmp/42 defconfig
$ make ARCH=alpha CROSS_COMPILE=alpha-linux- O=/tmp/42
Using /home/jdittmer/src/lk/linus as source for kernel
GEN/tmp/42/Makefile
CHK inc
On Tue, Apr 05, 2005 at 06:44:08AM -0700, Barry K. Nathan wrote:
> swsusp: reading slkf;jalksfsadflkjas;dlfasdfkl (12345 pages): 34%
> [sorry, I just got up so my short-term memory isn't working that well
> yet]
>
> takes 10-30 minutes (depending on whether it's closer to 11000 pages or
> 2) r
On Tue, Apr 05, 2005 at 12:05:24AM -0700, Andrew Morton wrote:
> - Nobody said anything about the PM resume and DRI behaviour in
> 2.6.12-rc1-mm4. So it's all perfect now?
No, I just didn't get a chance to send mail yet.
Compared to 2.6.11-ac5, I'm seeing one regression: the part of the
resume
a missing include:
...
drivers/usb/storage/debug.c: In function `usb_stor_show_sense':
drivers/usb/storage/debug.c:166: warning: implicit declaration of function
`scsi_sense_key_string'
drivers/usb/storage/debug.c:167: warning: implicit declaration of function
`scsi_extd_sense_format'
...
--
Hi again
At 12:14 a.m. 6/04/2005, Adrian Bunk wrote:
On Tue, Apr 05, 2005 at 08:34:11PM +1200, Reuben Farrelly wrote:
> Hi,
Hi Reuben,
>...
> Hrm. Something changed between the last -mm release which compiled
> through, and this one..
>...
> LD .tmp_vmlinux1
> arch/i386/kernel/built-in.o(.in
On Tue, Apr 05, 2005 at 08:34:11PM +1200, Reuben Farrelly wrote:
> Hi,
Hi Reuben,
>...
> Hrm. Something changed between the last -mm release which compiled
> through, and this one..
>...
> LD .tmp_vmlinux1
> arch/i386/kernel/built-in.o(.init.text+0x1823): In function `setup_arch':
> : un
On Tue, Apr 05, 2005 at 07:35:46PM +1000, Paul Mackerras wrote:
> Christoph Hellwig writes:
>
> > It's documented where the other filesystem entry points are documented.
>
> Which is?
>
> $ grep -r compat_ioctl Documentation
> Documentation/filesystems/Locking: long (*compat_ioctl) (struct
On Tue, Apr 05, 2005 at 07:51:57PM +1000, Paul Mackerras wrote:
> Christoph Hellwig writes:
>
> > Please make it a module option so it doesn't regress everyone for your
> > specific needs.
>
> Sorry, I don't follow you.
E.g. on my ia64 box CONFIG_COMPAT is set because I have support compiled
in
Christoph Hellwig writes:
> - the magic CONFIG_COMPAT changes for SHM handles should only be done when
>a module is set. CONFIG_COMPAT is set for mostly 64bit systems that can
>run 32bit code and drm shouldn't behave differently just because we can
>run 32bit code.
Yes it should - w
On 095, 04 05, 2005 at 12:05:24AM -0700, Andrew Morton wrote:
what useful this part of the patch is supposed to do ?
Looks like the result of whitespace damage.
--- linux-2.6.12-rc2/drivers/acpi/sleep/main.c 2005-03-02 01:09:19.0
-0800
+++ 25/drivers/acpi/sleep/main.c2005-04-04
On Tue, Apr 05, 2005 at 07:58:19PM +1000, Dave Airlie wrote:
> >
> > E.g. on my ia64 box CONFIG_COMPAT is set because I have support compiled
> > in for running i386 apps. But I don't want dri to hand out 32bit handles
> > everywhere just because of that, because I most certainly won't be running
Andrew Morton wrote:
[...]
Does not compile on AthlonXP. For mmx_clear_page, only the prototype was
changed, but the implementation is still the same. I guess that part of
the patch slipped out somehow.
-extern void mmx_clear_page(void *page);
+extern void mmx_clear_page(void *page, int order);
>
> E.g. on my ia64 box CONFIG_COMPAT is set because I have support compiled
> in for running i386 apps. But I don't want dri to hand out 32bit handles
> everywhere just because of that, because I most certainly won't be running
> i386 OpenGL apps.
>
It doesn't actually matter what size the han
Christoph Hellwig writes:
> E.g. on my ia64 box CONFIG_COMPAT is set because I have support compiled
> in for running i386 apps. But I don't want dri to hand out 32bit handles
> everywhere just because of that, because I most certainly won't be running
> i386 OpenGL apps.
The handle for a _DRM_S
Christoph Hellwig writes:
> It's documented where the other filesystem entry points are documented.
Which is?
$ grep -r compat_ioctl Documentation
Documentation/filesystems/Locking: long (*compat_ioctl) (struct file *,
unsigned int, unsigned long);
Documentation/filesystems/Locking:compat_
Christoph Hellwig writes:
> Please make it a module option so it doesn't regress everyone for your
> specific needs.
Sorry, I don't follow you.
-
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://vg
On Tue, Apr 05, 2005 at 07:44:38PM +1000, Paul Mackerras wrote:
> Christoph Hellwig writes:
>
> > - the magic CONFIG_COMPAT changes for SHM handles should only be done when
> >a module is set. CONFIG_COMPAT is set for mostly 64bit systems that can
> >run 32bit code and drm shouldn't beha
On Tue, 2005-04-05 at 19:20 +1000, Paul Mackerras wrote:
> Dave Airlie writes:
>
> > Paulus these look like your patches care to update them with the "new"
> > method of doing stuff..
>
> What are we going to do about the DRM CVS? Change it to the new way
> and break everyone running 2.6.10 or e
Btw, some more comments on the 32bit compat code in drm:
- instead of set_fs & co and passing kernel addresses to drm_ioctl
please use compat_alloc_user_space()
- this:
+ifeq ($(CONFIG_COMPAT),y)
+drm-objs+= drm_ioc32.o
+radeon-objs += radeon_ioc32.o
+endif
should be written as
drm
>
> > Paulus these look like your patches care to update them with the "new"
> > method of doing stuff..
>
> What are we going to do about the DRM CVS? Change it to the new way
> and break everyone running 2.6.10 or earlier, or leave it at the old
> way that will work for people with distro kern
Dave Airlie writes:
> Paulus these look like your patches care to update them with the "new"
> method of doing stuff..
What are we going to do about the DRM CVS? Change it to the new way
and break everyone running 2.6.10 or earlier, or leave it at the old
way that will work for people with distr
On Tue, Apr 05, 2005 at 07:11:26PM +1000, Paul Mackerras wrote:
> Christoph Hellwig writes:
>
> > Those DRI callers aren't in mainline but introduced in bk-drm.patch,
> > looks like the DRI folks need beating with a big stick..
>
> Settle down Christoph, the compat_ioctl method is less than 3 mon
Christoph Hellwig writes:
> Those DRI callers aren't in mainline but introduced in bk-drm.patch,
> looks like the DRI folks need beating with a big stick..
Settle down Christoph, the compat_ioctl method is less than 3 months
old, has only been in one official 2.6.x release, and isn't documented
a
On Apr 5, 2005 5:44 PM, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 05, 2005 at 12:05:24AM -0700, Andrew Morton wrote:
> > +officially-deprecate-register_ioctl32_conversion.patch
> >
> > deprecate a compat function (mainly affects DRI)
>
> Those DRI callers aren't in mainline but i
Hi,
On Tuesday, 5 of April 2005 09:05, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/
>
> - x86 NMI handling seems to be bust in 2.6.12-rc2. Try using
> `nmi_watchdog=0' if you experience weird crashes.
>
> - The possible ker
Ingo Molnar a écrit :
* Brice Goglin <[EMAIL PROTECTED]> wrote:
Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/
Hi Andrew,
printk timing seems broken.
It always shows [ 0.00] on my Compaq Evo N600c.
could you send the full bootl
Hi,
Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/
- x86 NMI handling seems to be bust in 2.6.12-rc2. Try using
`nmi_watchdog=0' if you experience weird crashes.
- The possible kernel-timer related hangs might possibly be fixed. We
* Brice Goglin <[EMAIL PROTECTED]> wrote:
> Andrew Morton a écrit :
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/
>
> Hi Andrew,
>
> printk timing seems broken.
> It always shows [ 0.00] on my Compaq Evo N600c.
could you send the full bootlog (
Brice Goglin <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton a écrit :
> >
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/
>
> Hi Andrew,
>
> printk timing seems broken.
> It always shows [ 0.00] on my Compaq Evo N600c.
What sort of CPU does that
> bk-audit.patch
This introduces various AUDIT_ARCH numerical constants, which is a blatantly
stupid idea. We already have a way to uniquely identify architectures, and
that's the ELF headers, no need for another parallel namespace.
(btw, could you please add to all patches who's responsible fo
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> (btw, could you please add to all patches who's responsible for them,
> bk-audit.patch doesn't tell)
It's supposed to, but if I have to fix rejects and refresh the patch, I
lose that info. Right now, bk-audit stomps on bk-ia64, so we lost the info
Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/
- Nobody said anything about the PM resume and DRI behaviour in
2.6.12-rc1-mm4. So it's all perfect now?
I'm sorry, I did not follow this "PM resume broken" thread.
But, suspend to di
Brice Goglin <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton a écrit :
> > Brice Goglin <[EMAIL PROTECTED]> wrote:
> >
> >>Andrew Morton a écrit :
> >> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/
> >>
> >> Hi Andrew,
> >>
> >> printk timing seems broken.
Andrew Morton a écrit :
Brice Goglin <[EMAIL PROTECTED]> wrote:
Andrew Morton a écrit :
>
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/
Hi Andrew,
printk timing seems broken.
It always shows [ 0.00] on my Compaq Evo N600c.
What sort of CPU does that
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
>
> >+sched-remove-unnecessary-sched-domains.patch
> >+sched-improve-pinned-task-handling-again.patch
> [snip]
> >
> > CPU scheduler updates
> >
>
> It is no problem that you picked these up for testing. But
> don't merge them yet,
Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/
Hi Andrew,
printk timing seems broken.
It always shows [ 0.00] on my Compaq Evo N600c.
dmesg and config attached.
- Nobody said anything about the PM resume and DRI behaviour in
2.
On Tue, Apr 05, 2005 at 12:05:24AM -0700, Andrew Morton wrote:
> +officially-deprecate-register_ioctl32_conversion.patch
>
> deprecate a compat function (mainly affects DRI)
Those DRI callers aren't in mainline but introduced in bk-drm.patch,
looks like the DRI folks need beating with a big stic
Andrew Morton wrote:
+sched-remove-unnecessary-sched-domains.patch
+sched-improve-pinned-task-handling-again.patch
[snip]
CPU scheduler updates
It is no problem that you picked these up for testing. But
don't merge them yet, please.
Suresh's underlying problem with the unnecessary sched domains
is
>
> - Nobody said anything about the PM resume and DRI behaviour in
> 2.6.12-rc1-mm4. So it's all perfect now?
Well the DRI is, both reports of bugs have been fixed :-), the bug
should be closed on bugs.kernel.org I think, and it looks rock solid
on my box both FC3 and Debian sarge..
Dave.
-
85 matches
Mail list logo
