On 4 Jul 2007, DervishD stated:
> Anyway, if you don't like mobs or you just don't want to try it,
> that's fine, but please don't use autotools, it doesn't make much sense
> for a linux only project, since you will be using only the "directory
> choosing" part of autotools. Maybe a hand made s
On Wed, 04 Jul 2007 12:51:16 -0700 "H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Sébastien Dugué wrote:
> >
> > One last thing, is there a git server as well for eu?
> >
>
> FWIW, I've set up git.eu.kernel.org; right now it's an alias to
> git.kernel.org, but that might change in the futu
On Wed, Jul 04, 2007 at 05:55:15PM +0530, Satyam Sharma wrote:
> On Wed, 4 Jul 2007, Keiichi KII wrote:
> > By the way, how can I add Signed-off-by:'s to your patches?
> > Should I add it to each patch and submit them to this list again?
> >
> > Anybody could give me an advice?
>
> I think you co
Hello,
Miles Lane wrote:
> XXX sysfs_deactivate: sd=c36ba6c0 s_sibling=6b6b6b6b s_flags=0x6b6b6b6b
> [ cut here ]
> kernel BUG at fs/sysfs/dir.c:274!
OIC, ref counter is too low by one. The sysfs_dirent is probably
getting freed on sysfs_drop_dentry(). Hmmm... Where did
This patch introduces a capability flag that is used by the DLPAR userspace
tool to check which DLPAR features are supported by the eHEA driver.
Missing goto has been included.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h |8 +++-
drivers/net/ehea
This patch enables the receive side processing to aggregate TCP packets within
the HEA device driver. It analyses the packets already received after an
interrupt arrived and forwards these as chains of SKBs for the same TCP
connection with modified header field. We have seen a lower CPU load and
im
Hi folks,
I can temporarily only read your answers in archives.
Thank you for your reaction.
It would be nice, to send responses directly to me too:
"linux-kernel-news at e-dict".
Hopefully this answer doesn't break the thread.
If it does:
sorry for it, there were some mail mail problems
which sto
> Why not. I boot back and forth randomly between old and new IDE kernels
> without problems. The root fs loaded is set in kernel or grub (or on most
> distros nowdays by label scanning from initrd) so just works. Then mount
> label or uuid based mounting does the rest.
You say that, but I remembe
Am Donnerstag, 5. Juli 2007 schrieb Miklos Szeredi:
> > > > I have discussed the benefits elsewhere. As for the deadlocks -- do
> > > > you still observe them if you use the version of the freezer which
> > > > doesn't freeze kernel threads?
> > >
> > > In general the only way to guarantee ther
> > > I have discussed the benefits elsewhere. As for the deadlocks -- do
> > > you still observe them if you use the version of the freezer which
> > > doesn't freeze kernel threads?
> >
> > In general the only way to guarantee there are no deadlocks is to
> > construct the graph of dependenci
> > Pro-freezers say:
> >
> > - don't remove the freezer, otherwise we'll have to deal with
> > numerous problems in drivers
>
> And these problems will generally be difficult to reproduce reliably
> and debug.
I see exactly the opposite.
With the freezer I can have very rarely occuring f
> > > > > I have discussed the benefits elsewhere. As for the deadlocks -- do
> > > > > you still observe them if you use the version of the freezer which
> > > > > doesn't freeze kernel threads?
> > > >
> > > > In general the only way to guarantee there are no deadlocks is to
> > > > construct
* Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> > > Isn't it better to call lock_release() with nested == 1 ?
> >
> > Not sure, Ingo?
>
> Ingo, could you also explain the meaning of "nested" parameter? Looks
> like it is just unneeded, lock_release_nested() does a quick check and
> use lock_rele
* Johannes Berg <[EMAIL PROTECTED]> wrote:
> +#ifdef CONFIG_LOCKDEP
> + /*
> + * It is permissible to free the struct work_struct
> + * from inside the function that is called from it,
> + * this we need to take into account for lockdep too.
> +
Am Donnerstag, 5. Juli 2007 schrieb Miklos Szeredi:
> > > > > > I have discussed the benefits elsewhere. As for the deadlocks --
> > > > > > do
> > > > > > you still observe them if you use the version of the freezer which
> > > > > > doesn't freeze kernel threads?
> > > > >
> > > > > In gener
On Thu, 2007-07-05 at 10:45 +0200, Ingo Molnar wrote:
> > +#ifdef CONFIG_LOCKDEP
> > + /*
> > +* It is permissible to free the struct work_struct
> > +* from inside the function that is called from it,
> > +* this we need to take into account for lockd
On Thu, 2007-07-05 at 10:48 +0200, Ingo Molnar wrote:
> btw., small patch format comment: it would be useful (in the future) to
> send such combined patches as:
>
> [patch 0/2] general description
> [patch 1/2] first patch
> [patch 2/2] second patch
Sure, no problem. I usually do that automa
> Thanks for your reply. Please, just call me Nigel :).
Haha. Okay. Nigel.
(Though, San is useful for even friendly/frank situation in Japanese :) )
> I saw a patch that Dave
> Hansen had posted, back around the time of 2.6.11 iirc. It was for x86, and
> (so far as I understand) allowed a perso
* Johannes Berg <[EMAIL PROTECTED]> wrote:
> This adds a lockdep_map for each work struct in order to debug
> deadlocks like
> my_function -> lock(); ...; cancel_work_sync(my_work)
> vs.
> run_workqueue() -> my_work.f() -> ...; lock(); ...
>
> which will deadlock if my_work.f() is invoked al
Balbir Singh wrote:
> Resending with the patch numbering fixed and linux-mm copied
>
> This patchset implements another version of the memory controller. These
> patches have been through a big churn, the first set of patches were posted
> last year and earlier this year at
> http://lkml.org
* Johannes Berg <[EMAIL PROTECTED]> wrote:
> Btw, do you have a tree you'll submit this through, or Oleg, or should
> I send it to akpm after we sort out any further issues?
yep, would be nice if akpm could pick it up. (unless Peter wants to set
up a lockdep git tree?) This should be merged in
KAMEZAWA Hiroyuki wrote:
On Wed, 04 Jul 2007 16:24:38 +0200
Zoltan Menyhart <[EMAIL PROTECTED]> wrote:
Machines star up whit bit 5 = 0, reading instruction pages via
NFS has to flush them from L2I.
In our test, we confirmed that this can be fixed by flushing L2I just before
SetPageUptodate(
On Thu, 2007-07-05 at 10:53 +0200, Ingo Molnar wrote:
> > +#ifdef CONFIG_LOCKDEP
> > +/*
> > + * HACK! This really should call lockdep_init_map() but can't
> > + * because there's no requirement to initialise work structs
> > + * at runtime. This works because subclass == 0.
> > + *
> > + * NB: be
This adds a lockdep_map for each work struct in order to debug
deadlocks like
my_function -> lock(); ...; cancel_work_sync(my_work)
vs.
run_workqueue() -> my_work.f() -> ...; lock(); ...
which will deadlock if my_work.f() is invoked already but my_function()
has acquired the lock already.
Sig
This patch adds a fake lock to each workqueue in order to debug things
where you have something like
my_function() -> lock(); ...; flush_workqueue(); ...
vs
run_workqueue() -> my_work() -> ...; lock(); ...
which can obviously deadlock if my_work is scheduled when my_function()
is invoked (but
On Thu, 2007-07-05 at 10:58 +0200, Johannes Berg wrote:
> On Thu, 2007-07-05 at 10:53 +0200, Ingo Molnar wrote:
>
> > > +#ifdef CONFIG_LOCKDEP
> > > +/*
> > > + * HACK! This really should call lockdep_init_map() but can't
> > > + * because there's no requirement to initialise work structs
> > > +
On Thu, 2007-07-05 at 11:01 +0200, Peter Zijlstra wrote:
> You could of course make this STATIC_LOCKDEP_MAP_INIT() and place it
> near lockdep_init_map() :-)
>
> That way it would be clear that changes to either ought to be reflected
> in the other.
Sure. I have to repost anyway :)
How about
+
On Wed, 4 Jul 2007, Joel Becker wrote:
> On Wed, Jul 04, 2007 at 04:38:04PM +0530, Satyam Sharma wrote:
> > - if (!(event == NETDEV_CHANGEADDR || event == NETDEV_CHANGENAME))
> > - goto done;
> > + if (!(event == NETDEV_UP || event == NETDEV_DOWN ||
> > + event == NETDEV_CHANG
Hi!
> > The fact remains that lots of drivers would still need to be changed.
> > In the read and write methods someone would have to add code amounting
> > to this:
> >
> > if (suspend_is_under_way()) {
> > mutex_unlock(...);
> > block_until_resume();
> >
Hi folks,
I could temporarily only read your answers in archives.
Thank you for your reaction.
Hopefully this answer doesn't break the thread.
If it does:
sorry for it, there were some mail mail problems
which stopped our server receiving mails from this list
and the list auto-unsubscribed me and
On Wed, 4 Jul 2007, Joel Becker wrote:
> On Wed, Jul 04, 2007 at 04:38:19PM +0530, Satyam Sharma wrote:
> > +Some examples follow (configfs is mounted at the /config mountpoint, say).
>
> configfs is generally expected to be mounted at
> /sys/kernel/config, and it even creates that mountpoin
Hi All,
> I think mmc driver is layered modules, only top block driver
> registers driver under "mmc_bus_type" bus, see
> drivers/mmc/mmc_sysfs.c and mmc_block.c. I think they are creating a
> tree of devices of same characteristics under that bus.
> I think your driver is linux/drivers/mm
On Thu, 2007-07-05 at 11:10 +0200, Peter Zijlstra wrote:
> > +/* both _name and _key must not be NULL */
Heh actually I got confused. The requirement that _key is not NULL comes
from the fact that I need to copy it for the workqueue stuff, not from
lockdep. Hence, only _name must be non-NULL, I'l
On Wed, 2007-07-04 at 21:34 +0200, Johannes Berg wrote:
> This patch adds a fake lock to each workqueue in order to debug things
> where you have something like
>
> my_function() -> lock(); ...; flush_workqueue(); ...
> vs
> run_workqueue() -> my_work() -> ...; lock(); ...
>
> which can obvio
On Wed, 2007-07-04 at 23:12 +0200, Johannes Berg wrote:
> This adds a lockdep_map for each work struct in order to debug
> deadlocks like
> my_function -> lock(); ...; cancel_work_sync(my_work)
> vs.
> run_workqueue() -> my_work.f() -> ...; lock(); ...
>
> which will deadlock if my_work.f() is
Hi Joel,
On Wed, 4 Jul 2007, Joel Becker wrote:
> On Wed, Jul 04, 2007 at 04:37:01PM +0530, Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [0/3] configfs: Miscellaneous cleanups
> >
> > Simple cleanups for configfs (plus DLM and OCFS2, wherever applicable).
> > This is
On Thu, 2007-07-05 at 11:08 +0200, Johannes Berg wrote:
> On Thu, 2007-07-05 at 11:01 +0200, Peter Zijlstra wrote:
>
> > You could of course make this STATIC_LOCKDEP_MAP_INIT() and place it
> > near lockdep_init_map() :-)
> >
> > That way it would be clear that changes to either ought to be refle
On Thu 2007-07-05 10:17:17, Miklos Szeredi wrote:
> > > > I have discussed the benefits elsewhere. As for the deadlocks -- do
> > > > you still observe them if you use the version of the freezer which
> > > > doesn't freeze kernel threads?
> > >
> > > In general the only way to guarantee there
> > > > > I have discussed the benefits elsewhere. As for the deadlocks -- do
> > > > > you still observe them if you use the version of the freezer which
> > > > > doesn't freeze kernel threads?
> > > >
> > > > In general the only way to guarantee there are no deadlocks is to
> > > > construct
On Thu 2007-07-05 10:53:37, Paul Mackerras wrote:
> Pavel Machek writes:
>
> > 0. Get someone to sign up as a maintainer for suspend, so we have
> > someone to blame for the mess? :-)
>
> I thought that was Rafael?
Rafael is good job trying to fix suspend when he can, but we do not
actually have
We have a fun problem and for a change it's not sparse fault.
It's gcc folks' one. Basically, __attribute__((...)) behaves in
an idiotic way and it's an intentional (and documented) behaviour.
In declaration of form
T __attribute__((foo)) **v;
the attribute applies to v, not to **v
kmem_cache_open is static so shouldn't be exported.
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
---
mm/slub.c |1 -
1 file changed, 1 deletion(-)
--- wireless-dev.orig/mm/slub.c 2007-07-05 11:35:51.555640003 +0200
+++ wireless-dev/mm/slub.c 2007-07-05 11:36:03.895640003 +0200
@@ -
Hi,
On Thu, Jul 05, 2007 at 12:39:22AM +0200, Pavel Machek wrote:
> Hi!
>
> > Yes, but I'm not sure if netconsole is the only one that we will want to
> > have
>
> Well, netconsole is the only one we know of.
AFAIR it is plain luck that serial console sometimes works.
I repeat: "no bugreport"
Hi.
On Thursday 05 July 2007 18:52:13 Yasunori Goto wrote:
> > Thanks for your reply. Please, just call me Nigel :).
>
> Haha. Okay. Nigel.
> (Though, San is useful for even friendly/frank situation in Japanese :) )
Ah, ok. Sort of like the Aussies among whom I'm living say "Mate", I guess -
in
Hi!
> > > - For STR, don't do the freezer thing.
> >
> > In the long run, I agree.
> >
> > Still, can you please read this post from Alan Stern:
> >
> > https://lists.linux-foundation.org/pipermail/linux-pm/2007-June/012847.html
> >
> > ? I don't think I'm able to repeat the arguments given
On Thursday 05 July 2007 01:50, Jesper Juhl wrote:
> > Removes conditional branch from schedule(). Code savings on my
> >usual config:
> >
> >textdata bss dec hex filename
> > 2921871 179895 180224 3281990 321446 vmlinux before
> > 2920141
On Thu, 5 Jul 2007, Denis Vlasenko wrote:
> On Thursday 05 July 2007 01:50, Jesper Juhl wrote:
> > > Removes conditional branch from schedule(). Code savings on my
> > >usual config:
> > >
> > >textdata bss dec hex filename
> > > 2921871 179895 180224 3281
> > > > And teach VFS to block suspension, while waiting on a mutex held by
> > > > another process performing a fuse operation.
> > > >
> > > > I can already hear the beautiful praise from Al Viro at the sight of
> > > > that ;)
> > >
> > > There is that.
> > >
> > > OK, bite the bullet. Tasks
Am Donnerstag, 5. Juli 2007 schrieb Miklos Szeredi:
> > > And teach VFS to block suspension, while waiting on a mutex held by
> > > another process performing a fuse operation.
> > >
> > > I can already hear the beautiful praise from Al Viro at the sight of
> > > that ;)
> >
> > There is that.
>
Hi!
> [ Shamelessly off-topic, but SCNR myself ]
>
> On 7/2/07, Nigel Cunningham <[EMAIL PROTECTED]>
> wrote:
> >Hi all.
> >
> >Suspend2's name is changing to "TuxOnIce".
>
> Hmm, FunkyMixedCase name ...
>
>
> ... hope this'll make it work on my laptop too :-)
>
> [ Is there a prize for post
Pavel Machek wrote:
On Thu 2007-07-05 10:53:37, Paul Mackerras wrote:
Pavel Machek writes:
0. Get someone to sign up as a maintainer for suspend, so we have
someone to blame for the mess? :-)
I thought that was Rafael?
Rafael is good job trying to fix suspend when he can
it's always nice when a subsystem has an official maintainer but
this does seem a bit excessive, no?
BLACKFIN ARCHITECTURE
P: Aubrey Li
M: [EMAIL PROTECTED]
P: Bernd Schmidt
M: [EMAIL PROTECTED]
P: Bryan Wu
M: [EMAIL PROTECTED]
P: Grace Pan
M: [EMAIL PROT
Hi.
On 7/5/07, Gabriel C <[EMAIL PROTECTED]> wrote:
Pavel Machek wrote:
> On Thu 2007-07-05 10:53:37, Paul Mackerras wrote:
>
>> Pavel Machek writes:
>>
>>
>>> 0. Get someone to sign up as a maintainer for suspend, so we have
>>> someone to blame for the mess? :-)
>>>
>> I thought that was Rafae
while the architecture directory is "h8300", the MAINTAINERS file
entry lists the architecture as "H8/300", so a simple grep for "h8300"
through MAINTAINERS would fail to find that entry.
rday
--
Robert P. J. Day
Linux Co
On Thursday, 5 July 2007 00:52, Nigel Cunningham wrote:
> Hi.
>
> On Thursday 05 July 2007 08:49:42 Pavel Machek wrote:
> > On Thu 2007-07-05 08:48:15, Nigel Cunningham wrote:
> > > Hi.
> > >
> > > On Thursday 05 July 2007 00:58:58 Rafael J. Wysocki wrote:
> > > > From: Rafael J. Wysocki <[EMAIL
* Dan Aloni <[EMAIL PROTECTED]> wrote:
> Signed-off-by: Dan Aloni <[EMAIL PROTECTED]>
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
Ingo
-
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://vge
Hi.
On Thursday 05 July 2007 20:15:14 Pavel Machek wrote:
> Hi!
>
> > I have recently begun to try and use suspend to ram more, and have an
> > intermittent problem. Actually, it's a couple of (possibly related)
problems,
> > but I'll start with the one that's easiest.
> >
> > Sometimes, when
Hi!
> I have recently begun to try and use suspend to ram more, and have an
> intermittent problem. Actually, it's a couple of (possibly related) problems,
> but I'll start with the one that's easiest.
>
> Sometimes, when I resume, the keyboard stops responding. I then need to hold
> down the
since it's not clear who a single contact person would be for
i386-related stuff like this, here's what my script turned up for
tests on non-existent CONFIG variables under arch/i386:
== BALANCED_IRQ_DEBUG ==
arch/i386/kernel/io_apic.c:356:#ifdef CONFIG_BALANCED_IRQ_DEBUG
==
From: David Howells <[EMAIL PROTECTED]>
Be (self-)consistent and use CONFIG_GDB_CONSOLE everywhere rather than using
CONFIG_GDBSTUB_CONSOLE in some places and not others. This is also then
consistent with other archs.
Also remove the gdbstub condole device() op which doesn't seem to be necessary
Hi!
> > > > In which way can user space tasks depend on each other in a way that
> > > > allows a them members of that cycle to be in uninterruptible sleep?
> > >
> > > - process A calls rename() on a fuse fs
> > > - process B, the fuse server, starts to process the rename request
> > > - proc
From: David Howells <[EMAIL PROTECTED]>
Remove some dead chunks of code that are bounded by preprocessor conditionals
controlled by apparently no-longer available config options.
These are:
CONFIG_BLK_DEV_BLKMEM
CONFIG_CHR_DEV_FLASH
CONFIG_BLK_DEV_FLASH
CONFIG_CON
On Thursday, 5 July 2007 02:15, Paul Mackerras wrote:
> Rafael J. Wysocki writes:
>
> > This is incompatible with the code in kernel/power/main.c, since we only
> > disable the nonboot CPUs after devices have been suspended. Do you think
> > that
> > your framework can be modified to work withou
Hi.
On Thursday 05 July 2007 21:28:49 Rafael J. Wysocki wrote:
> On Thursday, 5 July 2007 00:52, Nigel Cunningham wrote:
> > On Thursday 05 July 2007 08:49:42 Pavel Machek wrote:
> > > On Thu 2007-07-05 08:48:15, Nigel Cunningham wrote:
> > > > On Thursday 05 July 2007 00:58:58 Rafael J. Wysocki w
On Thursday, 5 July 2007 12:14, Miklos Szeredi wrote:
> > > > > And teach VFS to block suspension, while waiting on a mutex held by
> > > > > another process performing a fuse operation.
> > > > >
> > > > > I can already hear the beautiful praise from Al Viro at the sight of
> > > > > that ;)
> >
On Thursday, 5 July 2007 01:45, Pavel Machek wrote:
> On Tue 2007-07-03 21:32:20, Oliver Neukum wrote:
> > Am Dienstag, 3. Juli 2007 schrieb Miklos Szeredi:
> > > > And a further question. The freezer is not atomic. What do you do
> > > > if a task not yet frozen calls sys_sync(), but fuse is alrea
On Thursday, 5 July 2007 02:29, Paul Mackerras wrote:
> Rafael J. Wysocki writes:
>
> > They will not trigger 100% of the time, but sporadically and generally at
> > random.
> >
> > At least the freezer problems are reproducible. ;-)
>
> Our experience with powermacs has been that it isn't actua
From: David Howells <[EMAIL PROTECTED]>
Be (self-)consistent and use CONFIG_GDB_CONSOLE everywhere rather than using
CONFIG_GDBSTUB_CONSOLE in some places and not others. This is also then
consistent with other archs.
Also remove the gdbstub console device() op which doesn't seem to be necessary
From: David Howells <[EMAIL PROTECTED]>
Remove some dead chunks of code that are bounded by preprocessor conditionals
controlled by apparently no-longer available config options.
These are:
CONFIG_BLK_DEV_BLKMEM
CONFIG_CHR_DEV_FLASH
CONFIG_BLK_DEV_FLASH
CONFIG_CON
On Mon 2007-06-25 06:43:37, Robert P. J. Day wrote:
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
>
> ---
>
> it's not clear from MAINTAINERS who's responsible for something this
> generic.
I'd cc andi here...
Pavel
> diff --g
> > Actually fuse allows SIGKILL, because it's always fatal, and the
> > syscall may not be restarted.
>
> I think you want to stick try_to_freeze() at the same places where you
> do SIGKILL handling. That should solve the 'syslogd is unfreezeable'
> problem.
I could, but it would not solve the g
On Thursday 05 July 2007, Al Viro wrote:
> Frankly, I would rather add a new primitive (__qualifier__) mirroring the
> __attribute__, but acting like real qualifiers do. And switched the
> noderef et.al. to it. The only real alternative is to have __attribute__
> behaviour dependent on its guts a
I recently experienced a lockup in the wireless code due to the
scenario described in patch 1 and wanted to have lockdep warn
about such scenarios as a way to catch such bugs in other
subsystems as well as to make sure we wouldn't get such things
ever again.
In discussions with Oleg and Ingo it tu
In the following scenario:
code path 1:
my_function() -> lock(L1); ...; flush_workqueue(); ...
code path 2:
run_workqueue() -> my_work() -> ...; lock(L1); ...
you can get a deadlock when my_work() is queued or running
but my_function() has acquired L1 already.
This patch adds a pseudo-lock
In the following scenario:
code path 1:
my_function() -> lock(L1); ...; cancel_work_sync(my_work)
[or cancel_rearming_delayed_work(my_work)]
code path 2:
run_workqueue() -> my_work.f() -> ...; lock(L1); ...
you can get a deadlock if my_work.f() is running but my_function()
has acquired L1
From: David Howells <[EMAIL PROTECTED]>
Connect up new system calls.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---
arch/frv/kernel/entry.S |4
include/asm-frv/unistd.h |6 +-
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/frv/kernel/entry.S b/arch/f
Hi,
Apparently the serial_pci module detects a lot of (non-existent?) serial
ports on my laptop:
ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 3
PCI: setting IRQ 3 as level-triggered
ACPI: PCI Interrupt :00:08.0[A] -> Link [LNKG] -> GSI 3 (level, low)
-> IRQ 3
:00:08.0: ttyS1 at I/O 0x88
> > Limiting what a userspace filesystem can do would defeat the whole
> > purpose of the bloody thing. This is not negotiable ;)
>
> Which doesn't change the fact that FUSE _is_ special, because it adds
> dependencies between processed that were not present before.
OK, fuse is special. So is t
Hello, Jens.
Jens Axboe wrote:
> On Mon, May 28 2007, Neil Brown wrote:
>> I think the implementation priorities here are:
>>
>> 1/ implement a zero-length BIO_RW_BARRIER option.
>> 2/ Use it (or otherwise) to make all dm and md modules handle
>>barriers (and loop?).
>> 3/ Devise and implement
On Thursday, 5 July 2007 03:22, Adrian Bunk wrote:
> On Thu, Jul 05, 2007 at 02:27:47AM +0200, Pavel Machek wrote:
> >
> > > IMHO the suspend code is currently way too much of a moving target which
> > > results in this mess.
> > >
> > > The correct order seems to be:
> >
> > 0. Get someone to
Hi!
> On some machines, buggy BIOSes don't properly setup WB MTRRs to
> cover all available RAM, meaning the last few megs (or even gigs)
> of memory will be marked uncached. Since Linux tends to allocate
> from high memory addresses first, this causes the machine to be
> unusably slow as soon as
On Thu, 5 Jul 2007, Pavel Machek wrote:
Hi!
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of memory will be marked uncached. Since Linux tends to allocate
from high memory addresses first, this causes the ma
On Thursday, 5 July 2007 02:36, Paul Mackerras wrote:
> Alan Stern writes:
>
> > Remember what I wrote a few minutes ago about khubd and ksuspend_usbd
> > wanting to resume devices during a system suspend transition? This is
> > exactly what happens when those threads aren't frozen.
>
> So, I wo
On Thu, 2007-07-05 at 14:51 +0200, Rafael J. Wysocki wrote:
> > > Remember what I wrote a few minutes ago about khubd and ksuspend_usbd
> > > wanting to resume devices during a system suspend transition? This is
> > > exactly what happens when those threads aren't frozen.
> >
> > So, I wonder wh
On Thursday, 5 July 2007 02:43, Paul Mackerras wrote:
> Miklos Szeredi writes:
>
> > OK, let me summarize the situation as I see it now: there are two
> > camps, the pro-freezers and the anti-freezers.
> >
> > Pro-freezers say:
> >
> > - don't remove the freezer, otherwise we'll have to deal w
Hi.
On Thursday 05 July 2007 22:25:06 Rafael J. Wysocki wrote:
> On Thursday, 5 July 2007 01:45, Pavel Machek wrote:
> > On Tue 2007-07-03 21:32:20, Oliver Neukum wrote:
> > > Am Dienstag, 3. Juli 2007 schrieb Miklos Szeredi:
> > > > > And a further question. The freezer is not atomic. What do you
On Thursday, 5 July 2007 10:37, Miklos Szeredi wrote:
> > > Pro-freezers say:
> > >
> > > - don't remove the freezer, otherwise we'll have to deal with
> > > numerous problems in drivers
> >
> > And these problems will generally be difficult to reproduce reliably
> > and debug.
>
> I see e
> > > PF_FREEZER_SKIP flag. Perhaps we can do similar thing with FUSE.
> >
> > It cannot be just worked around in fuse, as a task might be sleeping
> > on a number of VFS mutexes as well (i_mutex, s_vfs_rename_mutex, etc).
> > It would be a gigantic hack, possible at all.
>
> Well, obviously FUS
On Thursday, 5 July 2007 14:24, Miklos Szeredi wrote:
> > Don't you think, however, that it can be modified a little to play well,
> > for example, with the freezer?
>
> I could stick a couple of try_to_freeze()s into fuse, and that would
> make suspend failure less likely. But making problems le
On Thursday, 5 July 2007 14:07, Miklos Szeredi wrote:
> > > Actually fuse allows SIGKILL, because it's always fatal, and the
> > > syscall may not be restarted.
> >
> > I think you want to stick try_to_freeze() at the same places where you
> > do SIGKILL handling. That should solve the 'syslogd is
On Thursday, 5 July 2007 13:54, Miklos Szeredi wrote:
> > > Limiting what a userspace filesystem can do would defeat the whole
> > > purpose of the bloody thing. This is not negotiable ;)
> >
> > Which doesn't change the fact that FUSE _is_ special, because it adds
> > dependencies between proces
On 05.07.2007 11:16, Ingo Freund wrote (please find the answer below the
original text):
> Hi folks,
>
> I could temporarily only read your answers in archives.
> Thank you for your reaction.
> Hopefully this answer doesn't break the thread.
> If it does:
> sorry for it, there were some mail mail
On Wed, 4 Jul 2007, Adrian Bunk wrote:
On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote:
I know this may sound kind of stupid, but how about not deprecating either,
and fully supporting both sound systems? Maybe we can get them to work
together, and the distro or user can choose whether
Hi Satyam,
> + cat enabled # check if enabled is 1
> + echo 0 > enabled# disable the target (if required)
> + echo eth2 > dev_name# set local interface
I think that the above line should change from "echo eth2 > dev_name" to
"ec
Hi all,
Is there any mailing list or tutorial which provides guidelines for
porting Linux SMP into a new architecture?
Thanks a lot in advance.
Best Regards,
--
Mohamed Ahmed Bamakhrama
Am Schaeferanger 15, room 035
85764 Oberschleissheim, Germany
Email: [EMAIL PROTECTED]
Web: http://home.cs.tu
In 7d12e780e003f93433d49ce78cfedf4b4c52adc5 David Howells performed
this evolution:
"IRQ: Maintain regs pointer globally rather than passing to IRQ handlers"
He correctly updated many of the function definitions that were using
this extra regs pointer parameter but forgot to update some caller
Hi,
On Thursday, 5 July 2007 15:36, Nigel Cunningham wrote:
> Hi.
>
> On Thursday 05 July 2007 23:35:45 Rafael J. Wysocki wrote:
> > On Thursday, 5 July 2007 14:38, Nigel Cunningham wrote:
> > > On Thursday 05 July 2007 22:25:06 Rafael J. Wysocki wrote:
> > > > On Thursday, 5 July 2007 01:45, Pav
On Wed, Jul 04, 2007 at 11:30:08PM -0700, Joel Becker wrote:
> On Wed, Jul 04, 2007 at 04:37:01PM +0530, Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [0/3] configfs: Miscellaneous cleanups
> >
> > Simple cleanups for configfs (plus DLM and OCFS2, wherever applicable).
On Thu, 5 Jul 2007, Satyam Sharma wrote:
> [...]
> BTW I did some testing myself, and have found another *embarrassing* bug:
> if netconsole is loaded _without_ specifying any "netconsole=" parameter,
> module is still kept loaded, but on unloading configfs_unregister_...()
> obviously panics! :-)
On Thursday, 5 July 2007 14:50, Johannes Berg wrote:
> On Thu, 2007-07-05 at 14:51 +0200, Rafael J. Wysocki wrote:
>
> > > > Remember what I wrote a few minutes ago about khubd and ksuspend_usbd
> > > > wanting to resume devices during a system suspend transition? This is
> > > > exactly what hap
1 - 100 of 409 matches
Mail list logo
