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
Thanks, this patch helped.
I can confirm, the 2nd patch worked and the 1st one didn't. (This is
against 2.6.12-rc2-mm1 with sched-x86-patch-name-is-way-too-long.patch
backed out. ;) )
-Barry K. Nathan <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscrib
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
On Mon, 2005-04-11 at 12:45 +0200, Thomas Graf wrote:
> * Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-04-11 09:22
> > On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf ([EMAIL PROTECTED])
> > wrote:
> > > + size = NLMSG_SPACE(sizeof(*msg) + msg->len);
> > > +
> > > + skb = alloc_skb(
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
* Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-04-11 09:22
> On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf ([EMAIL PROTECTED])
> wrote:
> > + size = NLMSG_SPACE(sizeof(*msg) + msg->len);
> > +
> > + skb = alloc_skb(size, GFP_ATOMIC);
> > + if (!skb) {
> > + pri
Hi,
I am having problems while booting 2.6.12-rc2-mm1 on i386 with command line
maxcpus=1. Without this commandline, system boots fine otherwise it hangs.
Serial output is pasted below.
If maxcpus=1 is given along with acpi=off then system boots fine. I am not sure
where the problem is
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 Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf ([EMAIL PROTECTED]) wrote:
> * jamal <[EMAIL PROTECTED]> 2005-04-10 10:39
> > Please crosspost on netdev - you should know that by now;->
> >
> > I actually disagreee with Herbert on this. Theres definetely good
> > need to have a more usable m
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
* jamal <[EMAIL PROTECTED]> 2005-04-10 10:39
> Please crosspost on netdev - you should know that by now;->
>
> I actually disagreee with Herbert on this. Theres definetely good
> need to have a more usable messaging system that rides on top of
> netlink. It is not that netlink cant be extended (I
On Sun, 2005-04-10 at 10:56, James Morris wrote:
> On 10 Apr 2005, jamal wrote:
>
> > Thats what the original motivation for konnector was. To make it easy
> > for joe dumbass.
>
> Who you really want writing kernel code :-)
Ok, let me take that back then ;->
The value is in allowing people who
On 10 Apr 2005, jamal wrote:
> Thats what the original motivation for konnector was. To make it easy
> for joe dumbass.
Who you really want writing kernel code :-)
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
Evgeniy,
Please crosspost on netdev - you should know that by now;->
I actually disagreee with Herbert on this. Theres definetely good
need to have a more usable messaging system that rides on top of
netlink. It is not that netlink cant be extended (I actually think thats
a separate topic) - its
On Sun, 10 Apr 2005 14:10:05 +0200
Thomas Graf <[EMAIL PROTECTED]> wrote:
> * Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-04-10 15:37
> > --- ./net/netlink/af_netlink.c.orig 2005-04-10 15:46:48.0 +0400
> > +++ ./net/netlink/af_netlink.c 2005-04-10 15:47:04.0 +0400
> > @@ -747,7
* Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-04-10 15:37
> --- ./net/netlink/af_netlink.c.orig 2005-04-10 15:46:48.0 +0400
> +++ ./net/netlink/af_netlink.c 2005-04-10 15:47:04.0 +0400
> @@ -747,7 +747,7 @@
> if (p->exclude_sk == sk)
> goto out;
>
> -
On Sun, 10 Apr 2005 15:37:57 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> The second one is a huge monster that can not be used in embedded
> systems, calling userspace process from inside the kernel is
> now very flexible way.
is NOT very flexible way...
Evgeniy Polyakov
Only
On Sun, 10 Apr 2005 13:08:44 +0200
Kay Sievers <[EMAIL PROTECTED]> wrote:
> On Sun, 2005-04-10 at 14:32 +0400, Evgeniy Polyakov wrote:
> > On Sun, 10 Apr 2005 19:52:54 +1000
> > Herbert Xu <[EMAIL PROTECTED]> wrote:
> > > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > > >
> > > > User should not
On Sun, 2005-04-10 at 14:32 +0400, Evgeniy Polyakov wrote:
> On Sun, 10 Apr 2005 19:52:54 +1000
> Herbert Xu <[EMAIL PROTECTED]> wrote:
> > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > >
> > > User should not know about low-level transport -
> > > it is like socket layer - write only data and
On Sun, 10 Apr 2005 19:52:54 +1000
Herbert Xu <[EMAIL PROTECTED]> wrote:
> Please add netdev to the CC list since this discussion pertains to
> the networking subsystem.
>
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > User should not know about low-level transport -
> > it is like socke
Please add netdev to the CC list since this discussion pertains to
the networking subsystem.
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> User should not know about low-level transport -
> it is like socket layer - write only data and do not care about
> how it will be delivered.
The deline
On Thu, Apr 07, 2005 at 11:02:22PM -0700, David S. Miller wrote:
> On Fri, 08 Apr 2005 09:19:39 +0400
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > > I know, the same thing holds for most architectures, including i386.
> > > However, this is not an issue for uni-processor kernels anywhere el
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 Fri, 2005-04-08 at 01:55 -0400, James Morris wrote:
> On Fri, 8 Apr 2005, Evgeniy Polyakov wrote:
>
> > > > Sure, but seems I need to ask again: What is the exact reason not to
> > > > implement
> > > > the muticast message multiplexing/subscription part of the connector as
> > > > a
> > > >
On Fri, 2005-04-08 at 09:19 +0400, Evgeniy Polyakov wrote:
> On Fri, 2005-04-08 at 15:08 +1000, Herbert Xu wrote:
> > On Fri, Apr 08, 2005 at 09:11:56AM +0400, Evgeniy Polyakov wrote:
> > >
> > > > Yes but what will go wrong on uni-processor MIPS when you don't do the
> > > > sync in atomic_sub_ret
On Fri, 08 Apr 2005 09:19:39 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > I know, the same thing holds for most architectures, including i386.
> > However, this is not an issue for uni-processor kernels anywhere else,
> > so what's so special about MIPS?
>
> Does i386 or ppc has cached a
On Fri, 8 Apr 2005, Evgeniy Polyakov wrote:
> > > Sure, but seems I need to ask again: What is the exact reason not to
> > > implement
> > > the muticast message multiplexing/subscription part of the connector as a
> > > generic part of netlink? That would be nice to have and useful for other
> >
On Fri, 2005-04-08 at 15:08 +1000, Herbert Xu wrote:
> On Fri, Apr 08, 2005 at 09:11:56AM +0400, Evgeniy Polyakov wrote:
> >
> > > Yes but what will go wrong on uni-processor MIPS when you don't do the
> > > sync in atomic_sub_return?
> >
> > Sync synchornizes cached mamory access,
> > without it
On Fri, Apr 08, 2005 at 09:11:56AM +0400, Evgeniy Polyakov wrote:
>
> > Yes but what will go wrong on uni-processor MIPS when you don't do the
> > sync in atomic_sub_return?
>
> Sync synchornizes cached mamory access,
> without it new value may be stored only into cache,
> but not into memory.
I
On Fri, 2005-04-08 at 14:53 +1000, Herbert Xu wrote:
> On Fri, Apr 08, 2005 at 08:55:27AM +0400, Evgeniy Polyakov wrote:
> >
> > > > Unfortunately not, that sync is required exactly for return value store.
> > >
> > > On UP?
> >
> > Yes, some quotes:
>
> Yes but what will go wrong on uni-process
On Fri, 8 Apr 2005 14:53:02 +1000
Herbert Xu <[EMAIL PROTECTED]> wrote:
> Yes but what will go wrong on uni-processor MIPS when you don't do the
> sync in atomic_sub_return?
Indeed. I see nothing in those quotes which indicate that the
SYNC is needed on uniprocessor. It's only saying things suc
On Fri, Apr 08, 2005 at 08:55:27AM +0400, Evgeniy Polyakov wrote:
>
> > > Unfortunately not, that sync is required exactly for return value store.
> >
> > On UP?
>
> Yes, some quotes:
Yes but what will go wrong on uni-processor MIPS when you don't do the
sync in atomic_sub_return?
Cheers,
--
V
On Fri, 2005-04-08 at 14:17 +1000, Herbert Xu wrote:
> On Fri, Apr 08, 2005 at 08:21:28AM +0400, Evgeniy Polyakov wrote:
> >
> > > > On UP do not.
> > >
> > > Shouldn't we should be fixing the MIPS implementation of
> > > atomic_sub_return to not do the sync on UP then?
> >
> > Unfortunately not,
On Fri, 08 Apr 2005 07:52:34 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> sparc64 has 32->64 conversation on exit.
It's extremely cheap, the conversion instruction
pairs with the retl instruction so it's essentially
free.
Talking about an arithmetic instruction over is complete
nonsense w
On Fri, 8 Apr 2005 14:17:24 +1000
Herbert Xu <[EMAIL PROTECTED]> wrote:
> On UP?
I think the barrier can be eliminated on MIPS on UP.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.
On Fri, Apr 08, 2005 at 08:21:28AM +0400, Evgeniy Polyakov wrote:
>
> > > On UP do not.
> >
> > Shouldn't we should be fixing the MIPS implementation of
> > atomic_sub_return to not do the sync on UP then?
>
> Unfortunately not, that sync is required exactly for return value store.
On UP?
--
Vi
On Fri, 2005-04-08 at 14:02 +1000, Herbert Xu wrote:
> On Fri, Apr 08, 2005 at 08:02:49AM +0400, Evgeniy Polyakov wrote:
> >
> > > > mips has additional sync.
> > >
> > > But atomic_dec + 2 barries is going to do the sync as well, no?
> >
> > On UP do not.
>
> Shouldn't we should be fixing the M
On Fri, Apr 08, 2005 at 08:02:49AM +0400, Evgeniy Polyakov wrote:
>
> > > mips has additional sync.
> >
> > But atomic_dec + 2 barries is going to do the sync as well, no?
>
> On UP do not.
Shouldn't we should be fixing the MIPS implementation of
atomic_sub_return to not do the sync on UP then?
On Fri, 2005-04-08 at 13:50 +1000, Herbert Xu wrote:
> On Fri, Apr 08, 2005 at 07:52:34AM +0400, Evgeniy Polyakov wrote:
> > On Fri, 2005-04-08 at 13:32 +1000, Herbert Xu wrote:
> > > On Fri, Apr 08, 2005 at 07:33:58AM +0400, Evgeniy Polyakov wrote:
> > > > On Fri, 2005-04-08 at 12:59 +1000, Herber
On Fri, Apr 08, 2005 at 07:52:34AM +0400, Evgeniy Polyakov wrote:
> On Fri, 2005-04-08 at 13:32 +1000, Herbert Xu wrote:
> > On Fri, Apr 08, 2005 at 07:33:58AM +0400, Evgeniy Polyakov wrote:
> > > On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote:
> > > > Evgeniy Polyakov <[EMAIL PROTECTED]> wrot
On Fri, 2005-04-08 at 13:32 +1000, Herbert Xu wrote:
> On Fri, Apr 08, 2005 at 07:33:58AM +0400, Evgeniy Polyakov wrote:
> > On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote:
> > > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > > >
> > > > atomic_dec_and_test() is more expensive than 2 barriers
On Thu, 2005-04-07 at 11:47 -0400, James Morris wrote:
> On Thu, 7 Apr 2005, Kay Sievers wrote:
>
> > Sure, but seems I need to ask again: What is the exact reason not to
> > implement
> > the muticast message multiplexing/subscription part of the connector as a
> > generic part of netlink? That
On Fri, Apr 08, 2005 at 07:33:58AM +0400, Evgeniy Polyakov wrote:
> On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote:
> > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > >
> > > atomic_dec_and_test() is more expensive than 2 barriers + atomic_dec(),
> > > but in case of connector I think the pri
On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > atomic_dec_and_test() is more expensive than 2 barriers + atomic_dec(),
> > but in case of connector I think the price is not so high.
>
> Can you list the platforms on which this is true?
s
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> atomic_dec_and_test() is more expensive than 2 barriers + atomic_dec(),
> but in case of connector I think the price is not so high.
Can you list the platforms on which this is true?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herb
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
>
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/
> >
> > H
On Thu, 7 Apr 2005, Kay Sievers wrote:
> Sure, but seems I need to ask again: What is the exact reason not to implement
> the muticast message multiplexing/subscription part of the connector as a
> generic part of netlink? That would be nice to have and useful for other
> subsystems too as an opti
On Thu, 2005-04-07 at 16:23 +0200, Kay Sievers wrote:
> Sure, but seems I need to ask again: What is the exact reason not to implement
> the muticast message multiplexing/subscription part of the connector as a
> generic part of netlink? That would be nice to have and useful for other
> subsystems
On Thu, Apr 07, 2005 at 03:24:34PM +0400, Evgeniy Polyakov wrote:
> On Thu, 2005-04-07 at 12:41 +0200, Kay Sievers wrote:
> > On Thu, 2005-04-07 at 13:52 +0400, Evgeniy Polyakov wrote:
> > > On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote:
> > > > On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Po
On Thu, 2005-04-07 at 12:41 +0200, Kay Sievers wrote:
> On Thu, 2005-04-07 at 13:52 +0400, Evgeniy Polyakov wrote:
> > On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote:
> > > On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote:
> > > > The main idea was to simplify userspace control and
On Thu, 2005-04-07 at 13:52 +0400, Evgeniy Polyakov wrote:
> On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote:
> > On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote:
> > > The main idea was to simplify userspace control and notification
> > > system - so people did not waste it's time
On Thu, 2005-04-07 at 01:32 -0700, Andrew Morton wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > Plus, I'm still quite unsettled about the whole object lifecycle
> > > management, refcounting and locking in there. The fact that the code is
> > > littered with peculiar barrier
On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote:
> On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote:
> > The main idea was to simplify userspace control and notification
> > system - so people did not waste it's time learning how skb's are
> > allocated
> > and processed, how socket
On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote:
> The main idea was to simplify userspace control and notification
> system - so people did not waste it's time learning how skb's are
> allocated
> and processed, how socket layer is designed and what all those
> netlink_* and NLMSG* mean
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 m
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 ohci1394 ieee1394), the
rmmod command hung. Alt-Sysr
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> >
> > Plus, I'm still quite unsettled about the whole object lifecycle
> > management, refcounting and locking in there. The fact that the code is
> > littered with peculiar barriers says "something weird is happening here",
> > and it remains unobv
t; > Hello,
> > > >
> > > > I don't see the connector directory in the 2.6.12-rc2-mm1 tree. So it
> > > > seems that you removed the connector?
> > >
> > > Greg dropped it for some reason. I think that's best because it needed a
&g
On Thu, 2005-04-07 at 01:17 -0700, Greg KH wrote:
> On Wed, Apr 06, 2005 at 11:42:57PM -0700, Andrew Morton wrote:
> > Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> > >
> > > Hello,
> > >
> > > I don't see the connector directory in the
On Wed, Apr 06, 2005 at 11:42:57PM -0700, Andrew Morton wrote:
> Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> >
> > Hello,
> >
> > I don't see the connector directory in the 2.6.12-rc2-mm1 tree. So it
> > seems that you removed the connector?
&g
On Thu, 2005-04-07 at 00:58 -0700, Andrew Morton wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > > > > I don't see the connector directory in the 2.6.12-rc2-mm1 tree. So it
> > > > > seems that you removed the connector?
> >
On Thu, 2005-04-07 at 11:53 +0400, Evgeniy Polyakov wrote:
> > > Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hello,
> > > >
> > > > I don't see the connector directory in the 2.6.12-rc2-mm1 tree. So it
> &
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > > > I don't see the connector directory in the 2.6.12-rc2-mm1 tree. So it
> > > > seems that you removed the connector?
> > >
> > > Greg dropped it for some reason. I think that's best
Forwarded message - Re: connector is
> missing in 2.6.12-rc2-mm1"
> On Thu, 2005-04-07 at 09:36 +0200, Guillaume Thouvenin wrote:
> > Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> > >
> > > Hello,
> > >
> > > I don't see
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
mentioned patch). 2.6.11-rc2 does not
> > > have that problem.
> >
> > Does reverting swsusp-enable-resume-from-initrd.patch fix this also?
>
> No. Reverting it from 2.6.12-rc2-mm1 (oops, I got the version number
> wrong in my previous mail -- and that should also be
Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I don't see the connector directory in the 2.6.12-rc2-mm1 tree. So it
> seems that you removed the connector?
Greg dropped it for some reason. I think that's best because it needed a
significant amount
Hello,
I don't see the connector directory in the 2.6.12-rc2-mm1 tree. So it
seems that you removed the connector? Will you include it again in futur
release? At the same time, will you include the fork connector?
Thanks for your help,
Best regards,
Guillaume
-
To unsubscribe from this
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
> > have that problem.
>
> Does reverting swsusp-enable-resume-from-initrd.patch fix
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
#x27;t).
I don't know whether the PCMCIA problem is due to PCMCIA changes or not.
The only thing I see having changed between 2.6.12-rc1-mm3 and
2.6.12-rc2-mm1 is the addition of pcmcia-resource-handling-fixes.patch.
Would you have time to revert that, retest?
There have been a few 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
troduced 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
> have that problem.
Does reverting swsusp-enable-resume-from-initrd.patch fix this also?
> Also, with 2.6.12-rc2-
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'
Using your glib sample thingy from
http://www.kernel.org/pub/linux/kernel/people/rml/inotify/glib/
$ mkdir snozzberries
Event on wd=0: snozzberries, a directory, was created
$ rmdir snozzberries
Event on wd=0: snozzberries, a directory, was deleted
$ mkdir snozzberries
Event on wd=0:
This patch removes #include .
Because it includes two times.
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -urN -X dontdiff rc2-mm1-orig/arch/mips/kernel/ptrace.c
rc2-mm1/arch/mips/kernel/ptrace.c
--- rc2-mm1-orig/arch/mips/kernel/ptrace.c Tue Apr 5 23:19:16 2005
+++ rc2-mm1
tly-guilty patch. With the patch, resume
takes almost half an hour.)
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
hav
On Die, 05 Apr 2005, Andrew Morton wrote:
> > 2.6.12-rc2 suspends and resumes with the very same config file (well,
> > after running make oldconfig) without any problem.
> >
> > So there is a change in -mm1 which triggers this. Should I start with
> > backing out bk-acpi? or anything else?
>
> b
ally print
something in tsc_init(), which is always called during the boot
process.)
Hi Ingo,
The result is exactly the same, except the following lines at the
begining of dmesg. Note that only these lines have a valid timestamp.
All remaining lines show 0.000.
[4294667.296000] Linux version 2.6.
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]:
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
Norbert Preining <[EMAIL PROTECTED]> wrote:
>
> On Die, 05 Apr 2005, Pavel Machek wrote:
> > Well, I do not have working suspend-to-RAM setup close to me... Could
> > you try 2.6.12-rc1 to see if reboot problem is -mm specific or not?
>
> 2.6.12-rc2 suspends and resumes with the very same config f
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] Error 1
CONFIG_X86_PC=y
CONFIG_MK7=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGA
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] Error 1
make: *** [arch/i386/lib] Error 2
I ho
1 - 100 of 157 matches
Mail list logo
