On Fri, 29 Dec 2006 03:32:02 -0800
Amit Choudhary <[EMAIL PROTECTED]> wrote:
> Description: Fix error-path leak in function jffs2_scan_medium(), in file
> fs/jffs2/scan.c
>
> Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
>
> diff --git a/fs/jffs2/scan.c b/fs/jffs2/scan.c
> index e241346..cd
Unlike x86, x86_64 already passes arguments in registers. The use of
regparm attribute makes no difference in produced code, and the use of
fastcall just bloats the code.
--
Glauber de Oliveira Costa
Red Hat Inc.
"Free as in Freedom"
diff -rup linux-2.6.19.1-devel/arch/x86_64/kernel/acpi/sleep.c
On Sun, Dec 31, 2006 at 04:55:51PM +, Alistair John Strachan wrote:
> On Sunday 31 December 2006 16:27, Adrian Bunk wrote:
> > On Sat, Dec 30, 2006 at 04:59:35PM +, Alistair John Strachan wrote:
> > > On Thursday 28 December 2006 04:14, Alistair John Strachan wrote:
> > > > On Thursday 28 D
On Tue, 2006-12-26 at 13:37 -0500, jamal wrote:
>On Tue, 2006-26-12 at 18:56 +0100, Ingo Molnar wrote:
>
>
> > + xfrm_audit_log(NETLINK_CB(skb).loginuid, NETLINK_CB(skb).sid,
> > + AUDIT_MAC_IPSEC_DELSPD, delete, xp, NULL);
> > +
> > if (!delete) {
> > struct s
On Sun, Dec 31, 2006 at 04:48:43PM +, Alistair John Strachan wrote:
> On Sunday 31 December 2006 16:28, Adrian Bunk wrote:
> > On Sat, Dec 30, 2006 at 06:29:15PM +, Alistair John Strachan wrote:
> > > On Saturday 30 December 2006 17:21, Chuck Ebbert wrote:
> > > > In-Reply-To: <[EMAIL PROTE
> > This is a silly complaint because the SFF layer in libata doesn't handle
> > this case yet anyway.
>
> Yes, it's "silly" people people use configurations you find inconvenient.
>
> At least one embedded x86 case cares, that I know of. They only needed
> to make two minor changes to make it
> I/O errors could go unnoticed when syncing, for example the following code
> could
> write a file bigger than 10Mib on a 10Mib filesystem. With this patch, msync()
> will report the error originally encountered by sync(). Tuning the number of
> sync may be needed to reproduce the bug.
> make_fil
Alan wrote:
This is a silly complaint because the SFF layer in libata doesn't handle
this case yet anyway.
Yes, it's "silly" people people use configurations you find inconvenient.
At least one embedded x86 case cares, that I know of. They only needed
to make two minor changes to make it work
Jeff Garzik wrote:
* After your patch, the code explicitly calls pci_request_region() for
BARs 0-4, but never for BAR5.
Without checking for failures, I might add.
Let's call that regression/obvious bug #4, because the previous code
actually CARED if the resource was reserved.
The 32bit and 64bit PARISC Linux kernels suffers from the problem, that the
gettimeofday() call sometimes returns non-monotonic times.
The easiest way to fix this, is to drop the PARISC-specific implementation and
switch over to the generic TIME_INTERPOLATION framework.
But in order to make it ev
Quoting Mimi Zohar ([EMAIL PROTECTED]):
> Being able to compile both SELinux and SLIM into the kernel was done
> intentionally.
Intentionally so that you can switch back and forth for testing?
> The kernel parameters 'selinux' and 'slim' can enable
> or disable the LSM module at boot. Perhaps, f
On Tue, Jan 02, 2007 at 10:33:25PM +0100, Helge Deller wrote:
> Ok, not Ok ?
Um, this is still doing cmpxchg() with insufficient locking. So, not
OK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at htt
On Mon, Dec 25, 2006 at 01:08:31AM -0700, Grant Grundler wrote:
> On Mon, Dec 25, 2006 at 01:06:35AM -0700, Grant Grundler wrote:
> > On Sat, Dec 23, 2006 at 11:07:26PM -0700, Grant Grundler wrote:
> > > "final" patch v7 and commit log entry appended below. :)
> >
> > v8 adds 2cd round of feedback
Oops ;-) resending, as I forgot to sign last version:
Unlike x86, x86_64 already passes arguments in registers. The use of
regparm attribute makes no difference in produced code, and the use of
fastcall just bloats the code.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
--
Glaube
On Tuesday 02 January 2007 21:10, Adrian Bunk wrote:
[snip]
> > > Comparing your report and [1], it seems that if these are the same
> > > problem, it's not a hardware bug but a gcc or kernel bug.
> >
> > This bug specifically indicates some kind of miscompilation in a driver,
> > causing boot time
This patch contains the scheduled IEEE1394_EXPORT_FULL_API removal.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
Documentation/feature-removal-schedule.txt |8 ---
drivers/ieee1394/Kconfig |7 --
drivers/ieee1394/ieee1394_core.c | 22 -
Incremental bugfix to previous 3 patch patchset of cpufreq lock rewrite.
There was one code path in cpufreq_get, that was using the write lock
in place of read and also potential recursive lock with sysfs
interface of cpuinfo_cur_freq.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Inde
This patch contains the scheduled find_trylock_page() removal.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
Documentation/feature-removal-schedule.txt | 12
include/linux/pagemap.h|2 --
mm/filemap.c | 20 -
On Tue, 2 Jan 2007, Adrian Bunk wrote:
>
> My point is that we have several reported problems only visible
> with gcc 4.1.
>
> Other bug reports are e.g. [2] and [3], but they are only present with
> using gcc 4.1 _and_ using -Os.
Traditionally, afaik, -Os has tended to show compiler problems
On Fri, 2006-12-29 at 11:25 -0500, Shawn Starr wrote:
> Hello,
>
> If any of you have used a Commodore 64 emulator in Linux (such as vice)
> noticed when using audio there is severe starvation while other activities of
> the system are going on. i.e. moving a window in X or starting another
>
On Tuesday 02 January 2007 16:56, Alistair John Strachan wrote:
> On Tuesday 02 January 2007 21:10, Adrian Bunk wrote:
> [snip]
>
> > > > Comparing your report and [1], it seems that if these are the same
> > > > problem, it's not a hardware bug but a gcc or kernel bug.
> > >
> > > This bug specifi
In the kernels later than 2.6.19 there is a regression that makes swsusp fail
if the resume device is not explicitly specified.
It can be fixed by adding an additional parameter to
mm/swapfile.c:swap_type_of() allowing us to pass the (struct block_device *)
corresponding to the first available swa
On Tue, 2 Jan 2007, Alistair John Strachan wrote:
>
> At any rate, I have absolute confirmation that it is GCC 4.1.1, because with
> GCC 3.4.6 the same kernel I reported booting three days ago is still
> cheerfully working. I regularly get uptimes of 60+ days on that machine,
> rebooting only
On Tuesday January 2, [EMAIL PROTECTED] wrote:
> On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
> > On Tue, 2 Jan 2007, Theodore Tso wrote:
> >
> > > I can very easily believe it. The US patent system and "justice"
> > > system in the US is completely and totally insane, and co
On Tue, Jan 02, 2007 at 11:23:35AM -0500, Lee Schermerhorn wrote:
> When building 2.6.20-rc2-mm1 with CHECK_HEADERS=y, the Makefile will
> build the target "include/config/kernel.release" twice.
I will try to take a look at this tomorrow.
> This behavior appears to have been introduced by the pat
I am wondering if we should define __likely/__unlikely macros no matter whether
CONFIG_LIKELY_PROFILE is defined, like the following. This way people can always
use the raw macros in case the debugging version causes problems.
Signed-off-by: Hua Zhong <[EMAIL PROTECTED]>
--- linux-2.6/include/li
> > We use BAR5 on two devices in legacy mode. Both of those reserve all the
> > other resources.
>
> Translation: You want to hand-wave away an obvious regression that YOU
> have created with your fix-to-a-fix.
It's not regressing anything.
> Why INTRODUCE these 2.6.20 Alan-isms, if they are
On Tue, 02 Jan 2007 16:32:01 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Jeff Garzik wrote:
> > * After your patch, the code explicitly calls pci_request_region() for
> > BARs 0-4, but never for BAR5.
>
> Without checking for failures, I might add.
The old code didn't reserve 1 or 3 at all l
On Wed, 3 Jan 2007 08:11:21 +1100 Neil Brown wrote:
> Of course if people would just put milk in their coffee, we would have
> this problem :-)
>
> [We now return you to our regular program of filesystem corruption
> and flame wars].
Yes, PLEEZE!
---
~Randy
-
To unsubscribe from this list: send
Bill Huey (hui) wrote:
> On Tue, Dec 26, 2006 at 04:51:21PM -0800, Chen, Tim C wrote:
>> Ingo Molnar wrote:
>>> If you'd like to profile this yourself then the lowest-cost way of
>>> profiling lock contention on -rt is to use the yum kernel and run
>>> the attached trace-it-lock-prof.c code on the
Alan wrote:
We use BAR5 on two devices in legacy mode. Both of those reserve all the
other resources.
Translation: You want to hand-wave away an obvious regression that YOU
have created with your fix-to-a-fix.
It's not regressing anything.
False:
2.6.0 - 2.6.19: libata guarantees that all
> How many of them stuffed the cup between their legs though? I think it
> she would have sqeezed the cup too hard and burned her hand and sued
> McDonalds for that people would be more understainding...
How would what she did have any bearing on the key issue, which is whether
or not McDonald's
Alan wrote:
Actually it didn't reserve BAR1 and BAR3 in legacy mode precisely because
of the PCI resource mismanagement in the old tree. So you take your pick.
I pick old bugs over new regressions.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Tue, Jan 02, 2007 at 02:51:05PM -0800, Chen, Tim C wrote:
> Bill,
>
> I'm having some problem getting this patch to run stablely. I'm
> encoutering errors like that in the trace that follow:
>
> Thanks.
> Tim
>
> Unable to handle kernel NULL pointer dereference at 0008
Yes, thos
On Tue, 2 Jan 2007, Linus Torvalds wrote:
> Traditionally, afaik, -Os has tended to show compiler problems that
> _could_ happen with -O2 too, but never do in practice. It may be that
> gcc-4.1 without -Os miscompiles some very unusual code, and then with -Os
> we just hit more cases of that.
>
> > Certainly, but tar isn't going to remember all the inode numbers.
> > Even if you solve the storage requirements (not impossible) it would
> > have to do (4e9^2)/2=8e18 comparisons, which computers don't have
> > enough CPU power just yet.
>
> It is remembering all inode numbers with nlink > 1
Certainly, but tar isn't going to remember all the inode numbers.
Even if you solve the storage requirements (not impossible) it would
have to do (4e9^2)/2=8e18 comparisons, which computers don't have
enough CPU power just yet.
It is remembering all inode numbers with nlink > 1 and many other to
On 12/28/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
[ I'm only subscribed to linux-fsdevel@ from above Cc list, please keep this
list in Cc: for AIO related stuff. ]
On Wed, Dec 27, 2006 at 04:25:30PM +, Christoph Hellwig ([EMAIL PROTECTED])
wrote:
> (1) note that there is another prob
On Sat, 2006-12-30 at 19:19 +, Alistair John Strachan wrote:
> On Saturday 30 December 2006 19:11, Michael S. Tsirkin wrote:
> > > On Friday 29 December 2006 06:25, Michael S. Tsirkin wrote:
> > > > Virtual MIDI Card 1
> > >
> > > Compile this feature out, I bet things start working again.
> >
On Mon, 2007-01-01 at 23:45 +, Russell King wrote:
> > However the cache flushing in kmap/kunmap idea might be cleaner and
> > better.
>
> It has the significant advantage that, unlike the flush* calls, they
> can't really be forgotten by folk programming on cache alias-free
> hardware. That'
Benjamin Herrenschmidt wrote:
This is a trivial implementation that suits it's purpose.
It's simple. I'm not sure what more is needed for this
project when it's pretty clear that i386 will never need
any additional support for open firmware.
I don't agree. It's definitely not clear to me E
On Tue, 2007-01-02 at 12:45 +0100, Segher Boessenkool wrote:
> > In addition, I haven't given on the idea one day of actually merging
> > the
> > powerpc and sparc implementation of a lot of that stuff. Mostly the
> > device-tree accessors proper, the of_device/of_platform bits etc...
> > into
>
On Tue, 2007-01-02 at 12:37 +0100, Segher Boessenkool wrote:
> >> So please do this crap right.
> >
> > I strongly agree. Nowadays, both powerpc and sparc use an in-memory
> > copy
> > of the tree (wether you use the flattened format during the trampoline
> > from OF runtime to the kernel or not i
We could of course have the interface work either on a copy of the tree
or on a real OF (though that means changing things like get_property on
powerpc and fixing the gazillions of users) but I tend to think that
working on a copy always is more efficient.
The patch that I posted creates a
On Tue, 2007-01-02 at 13:22 +0100, Segher Boessenkool wrote:
> > Except that none of the powerpc platforms can keep OF alive after the
> > kernel has booted, which is why we do an in-memory copy of the tree.
>
> Adding that functionality hasn't gotten easier at all since
> we use the flattened tre
On Tue, 2007-01-02 at 10:11 -1000, Mitch Bradley wrote:
>
> > We could of course have the interface work either on a copy of the tree
> > or on a real OF (though that means changing things like get_property on
> > powerpc and fixing the gazillions of users) but I tend to think that
> > working on
Are you really suggesting that using a kernel copy of the
device tree is the correct thing to do, and the only correct
thing to do -- with the sole argument that "that's what the
current ports do"?
Well, there are reasons why that's what the current ports do :-)
Sure. It might have been a goo
Not single thread -- but a "global OF lock" yes. Not that
it matters too much, (almost) all property accesses are init
time anyway (which is effectively single threaded).
Not that true anymore. A lot of driver probe is being threaded
nowadays,
either bcs of the new multithread probing bits, o
> The kernel doesn't care if one CPU is in OF land while the others
> are doing other stuff -- well you have to make sure the OF won't
> try to use a hardware device at the same time as the kernel, true.
That statement alone hides an absolute can of worms btw ;-)
> I'm a bit concerned about the
I do object basically to having something that doesn't also provide
in-kernel interfaces to access the device nodes & properties.
That's the wrong way around. Work is underway to instead
have the devicetreefs *use* the in-kernel interfaces. Would
that be acceptable?
I don't
agree with the re
The kernel doesn't care if one CPU is in OF land while the others
are doing other stuff -- well you have to make sure the OF won't
try to use a hardware device at the same time as the kernel, true.
That statement alone hides an absolute can of worms btw ;-)
Oh I know. With a sane OF implement
> All should converge on the same interface. That does not
> ab initio mean we should converge on what you currently
> have (although that might eventually be that case).
Well, Dave and I will happen to be in the same place in a few weeks for
LCA so we might spend some time having a look there i
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Tue, 2 Jan 2007 22:15:50 +0100
> We also can keep the old names as compatibility accessors for
> PowerPC only for a while, until everything is converted -- SPARC
> can do the same then. You can't really keep the old PowerPC names
> in kernel-wide
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Tue, 2 Jan 2007 22:28:21 +0100
> >> Not single thread -- but a "global OF lock" yes. Not that
> >> it matters too much, (almost) all property accesses are init
> >> time anyway (which is effectively single threaded).
> >
> > Not that true anymore
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Tue, 2 Jan 2007 22:37:32 +0100
> Leaving aside the issue of in-memory or not, I don't think
> it is realistic to think any completely common implementation
> will work for this -- it might for current SPARC+PowerPC+OLPC,
> but more stuff will be a
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Tue, 2 Jan 2007 22:40:17 +0100
> >> The kernel doesn't care if one CPU is in OF land while the others
> >> are doing other stuff -- well you have to make sure the OF won't
> >> try to use a hardware device at the same time as the kernel, true.
> >
On Sat, 2006-12-30 at 02:04 +0100, Mikulas Patocka wrote:
>
> On Fri, 29 Dec 2006, Trond Myklebust wrote:
>
> > On Thu, 2006-12-28 at 19:14 +0100, Mikulas Patocka wrote:
> >> Why don't you rip off the support for colliding inode number from the
> >> kernel at all (i.e. remove iget5_locked)?
> >>
> 2.6.0 - 2.6.19: libata guarantees that all PCI BARs are reserved to the
> libata driver.
Please read the code Jeff. The old IDE quirk code in the PCI layer blanked
BAR 0 to BAR 3 of a compatibility mode controller
You then request_region 0x1f0 and 0x170 (BAR 0 and BAR 2) directly. You
never r
Linus,
On Tuesday 02 January 2007 22:13, Linus Torvalds wrote:
[snip]
> What are the exact crash details? That might narrow things down enough
> that maybe you could try just one or two files that are "suspect".
I'll do a digest of the problem for you and anybody else that's lost track of
the de
On Tue, Jan 02, 2007 at 05:06:14PM -0500, D. Hazelton wrote:
> On Tuesday 02 January 2007 16:56, Alistair John Strachan wrote:
> > On Tuesday 02 January 2007 21:10, Adrian Bunk wrote:
> > [snip]
> >
> > > > > Comparing your report and [1], it seems that if these are the same
> > > > > problem, it's
From: Daniel Jacobowitz <[EMAIL PROTECTED]>
Do not implement CLONE_PARENT_SETTID until we know that clone will succeed.
If we do it too early NPTL's data structures temporarily reference a
non-existant TID.
Signed-off-by: Daniel Jacobowitz <[EMAIL PROTECTED]>
---
On Tue, Sep 26, 2006 at 08:59:15
Shrink the held_lock struct by using bitfields.
This shrinks task_struct on lockdep enabled kernels by 480 bytes.
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index ea097dd..ba81cce 100644
--- a/include/linux/lockdep.h
+++ b/include/
On Tue, Jan 02, 2007 at 06:35:58PM -0500, Dave Jones wrote:
Sent the wrong diff. Here's the fixed version...
Shrink the held_lock struct by using bitfields.
This shrinks task_struct on lockdep enabled kernels by 480 bytes.
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
diff --git a/include/li
Subject: [patch] profiling: fix sched profiling typo
From: Ingo Molnar <[EMAIL PROTECTED]>
fix sched profiling typo, introduced by the sleep profiling patch. This
bug caused profile=sched to not work.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
kernel/profile.c |2 +-
1 file changed,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
* Paul Slootman <[EMAIL PROTECTED]> writes:
> Steve Youngs <[EMAIL PROTECTED]> wrote:
>>
>> The last kernel from Linus' tree[1] that boots for me is v2.6.19. And
>> before I take my firs
On Tuesday 02 January 2007 18:24, you wrote:
> On Tue, Jan 02, 2007 at 05:06:14PM -0500, D. Hazelton wrote:
> > On Tuesday 02 January 2007 16:56, Alistair John Strachan wrote:
> > > On Tuesday 02 January 2007 21:10, Adrian Bunk wrote:
> > > [snip]
> > >
> > > > > > Comparing your report and [1], it
Alan wrote:
2.6.0 - 2.6.19: libata guarantees that all PCI BARs are reserved to the
libata driver.
Please read the code Jeff. The old IDE quirk code in the PCI layer blanked
BAR 0 to BAR 3 of a compatibility mode controller
(a) I'm well of aware of this, and (b) that changes nothing.
I said
On Tue, Jan 02, 2007 at 03:12:34PM -0800, Bill Huey wrote:
> On Tue, Jan 02, 2007 at 02:51:05PM -0800, Chen, Tim C wrote:
> > Bill,
> >
> > I'm having some problem getting this patch to run stablely. I'm
> > encoutering errors like that in the trace that follow:
>
> It might the case that the lo
Or maybe this rephrase helps:
Regardless of how the IDE quirks have configured the PCI BARs, libata is
written to assume that /all/ struct pci_dev resources for a single PCI
device are reserved to the libata driver.
Thus, if you avoid calling pci_request_regions (as your patch does), you
mus
Hello Segher,
> The comment used to be inside the "if" block, is this
> change correct?
You'd prefer an empty line in there?
> [And, do we want all these changes anyway? I don't care
> either way, both sides have their pros and their cons --
> just asking :-) ]
You know my opinion already :-)
Across different boots using the same 2.6.19 kernel on a quad-core xeon
I see huge variance in the migration_cost being reported during boot.
-migration_cost=39,3940
+migration_cost=25,4941
This CPU has a very large cache which could be key here...
L1 Instruction cache: 32KB, 8-way associative.
I am posting this because my kernel told me so...
The attached file contains dmesg's with and without pci-assign-busses.
My hardware is a Samsung Q35 Pro. Feel free to contact me
if you need any further information.
--Michael
dmesg.bz2
Description: Binary data
On Tue, 2007-01-02 at 12:14 -0800, David Schwartz wrote:
> > The recommendet _serving_ temperature for coffe is 55 °C or below.
>
> Nonsense! 55C (100F) is ludicrously low for coffee.
>
> 70C (125F) is the *minimum* recommended serving temperature. 165-190F is the
> preferred serving range. I can
from: Brian Pomerantz <[EMAIL PROTECTED]>
Description:
The fatal vs. non-fatal mask for the sysbus FERR status is
incorrect
according to the E7520 datasheet. This patch corrects the mask to
correctly
handle fatal and non-fatal errors.
Signed-off-by: Brian Pomerantz <[EMAIL PROTECTED]
from: Frithiof Jensen <[EMAIL PROTECTED]>
This patch is meant for Kernel version 2.6.19
This is a first, naive, attempt of providing an interface for memory
scrubbing in EDAC.
The following things are still outstanding:
- Only the K8 driver has been refactored with a HW scrub functio
from: Brian Pomerantz <[EMAIL PROTECTED]>
Source: MontaVista Software, Inc.
MR: 17525
Type: Defect Fix
Disposition: local
Description:
The reading of the DRA registers should be a byte at a time (one
register at a time) instead of 4 bytes at a time (four registers).
Reading a dword at
from: Frithiof Jensen <[EMAIL PROTECTED]>
This patch is meant for Kernel version 2.6.19
This is a first, naive, attempt of providing an interface for memory
scrubbing in EDAC.
The following things are still outstanding:
- Only the K8 driver has been refactored with a HW scrub functio
The comment used to be inside the "if" block, is this
change correct?
You'd prefer an empty line in there?
Obviously, you should change the comment to include the
conditional, if that is what is needed.
[And, do we want all these changes anyway? I don't care
either way, both sides have thei
> The 32bit and 64bit PARISC Linux kernels suffers from the problem, that the
> gettimeofday() call sometimes returns non-monotonic times.
This certainly needs to be fixed. I see stuff like this from ping:
64 bytes from 132.246.100.193: icmp_seq=19 ttl=255 time=0.4 ms
64 bytes from 132.246.100.
> 1) Programmatically reserve /all/ resources associated with
> our PCI device
> 2) Manually reserve resources associated with our PCI device,
> but are not listed in struct pci_dev.
Which it doesn't actually do. You reserve 0x1F0-0x1F7 but forget the
other register.
On Sat, 30 Dec 2006 19:10:31 +0300
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> "[PATCH 1/2] reimplement flush_workqueue()" fixed one race when CPU goes down
> while flush_cpu_workqueue() plays with it. But there is another problem, CPU
> can die before flush_workqueue() has a chance to call flush_c
> Thus, if you avoid calling pci_request_regions (as your patch does), you
> must manually provide the same guarantees that pci_request_regions
> provides to its callers.
pci_request_regions reserves only BAR4/BAR5 in legacy mode because of the
fact the resources are mashed and eventually cleaar
Older versions of the iBase FWA7304 BIOS have a bug that causes the
system to use way too much power when you run 'init 0', causing
the power brick to burn out after about 3 hours.
The fix for this is to get an updated BIOS from the manufacturer:
IB798F-T2-CP1A-1229
The problem still happens if
> On Tue, 2007-01-02 at 12:14 -0800, David Schwartz wrote:
> > > The recommendet _serving_ temperature for coffe is 55 °C or below.
> >
> > Nonsense! 55C (100F) is ludicrously low for coffee.
> >
> > 70C (125F) is the *minimum* recommended serving temperature.
> 165-190F is the
> > preferred se
On Dec 29, 2006, at 6:31 PM, Chen, Kenneth W wrote:
The AIO wake-up notification from aio_complete is really inefficient
in current AIO implementation in the presence of process waiting in
io_getevents().
Yeah, it's a real deficiency. Thanks for taking a stab at it.
This patch adds a wait
Dave Jones <[EMAIL PROTECTED]> wrote:
> Shrink the held_lock struct by using bitfields.
> This shrinks task_struct on lockdep enabled kernels by 480 bytes.
> * The following field is used to detect when we cross into an
> * interrupt context:
> */
> - int irq_co
Adrian Bunk wrote:
> Documentation/feature-removal-schedule.txt |8 ---
> drivers/ieee1394/Kconfig |7 --
> drivers/ieee1394/ieee1394_core.c | 22 -
> 3 files changed, 37 deletions(-)
>
> --- linux-2.6.20-rc2-mm1/Documentation/feat
Alan wrote:
Once combined mode is fixed not to abuse resources (and it originally
did it that way for a good reason I grant and am not criticising that) the
entire management for legacy mode, mixed mode and native mode resources
for an ATA device (including 0x170, 0x3F6 and other wacky magic) bec
Given the previous patch "aio: add per task aio wait event condition"
that we properly wake up event waiting process knowing that we have
enough events to reap, it's just plain waste of time to insert itself
into a wait queue, and then immediately remove itself from the wait
queue for *every* even
On Wed, Jan 03, 2007 at 01:47:36AM +0100, Bodo Eggert wrote:
> Dave Jones <[EMAIL PROTECTED]> wrote:
>
> > Shrink the held_lock struct by using bitfields.
> > This shrinks task_struct on lockdep enabled kernels by 480 bytes.
>
> > * The following field is used to detect when we cross into
This makes the modulo of ring->head into local variable head
unnecessary.
This patch removes that bogus code.
Looks fine to me:
Acked-by: Zach Brown <[EMAIL PROTECTED]>
- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
--- ./include/linux/aio.h.orig 2006-12-24 22:31:55.0 -0800
+++ ./include/linux/aio.h 2006-12-24 22:41:28.0 -0800
@@ -165,7 +165,7 @@ struct aio_ring_info {
struct page **ring_pages;
spinlock_t ring_lock;
- long
Zach Brown wrote on Tuesday, January 02, 2007 4:49 PM
> On Dec 29, 2006, at 6:31 PM, Chen, Kenneth W wrote:
> > This patch adds a wait condition to the wait queue and only wake-up
> > process when that condition meets. And this condition is added on a
> > per task base for handling multi-threaded
Zach Brown wrote on Tuesday, January 02, 2007 5:14 PM
> To: Chen, Kenneth W
> > --- ./include/linux/aio.h.orig 2006-12-24 22:31:55.0 -0800
> > +++ ./include/linux/aio.h 2006-12-24 22:41:28.0 -0800
> > @@ -165,7 +165,7 @@ struct aio_ring_info {
> >
> > struct page
That is not possible because when multiple tasks waiting for
events, they
enter the wait queue in FIFO order, prepare_to_wait_exclusive() does
__add_wait_queue_tail(). So first io_getevents() with min_nr of 2
will
be woken up when 2 ops completes.
So switch the order of the two sleepers
I had that changes earlier, but dropped it to make the patch smaller.
Still have it kicking around?
Making this stuff more consistent would be nice, I agree, I'm just
not sure it's worth the risk of running into some subtle bugs.
- z
-
To unsubscribe from this list: send the line "unsubscr
From: James Bottomley <[EMAIL PROTECTED]>
Date: Tue, 02 Jan 2007 16:53:23 -0600
> OK, so lets get down to brass tacks and look at the API characteristics.
>
> Some of the issues are:
>
> 1. Should kmap() actually flush all the user spaces?
> 2. Do we need additional hints in to kmap/k
From: [EMAIL PROTECTED]
Date: Tue, 02 Jan 2007 15:02:47 -0800
>
> The patch titled
> net: ifb error path loop fix
> has been added to the -mm tree. Its filename is
> net-ifb-error-path-loop-fix.patch
>
> See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
> out
On Sun, 2006-12-31 at 16:19 -0500, Halevy, Benny wrote:
> Trond Myklebust wrote:
> >
> > On Thu, 2006-12-28 at 17:12 +0200, Benny Halevy wrote:
> >
> > > As an example, some file systems encode hint information into the
> > > filehandle
> > > and the hints may change over time, another example
On Sun, 2006-12-31 at 16:25 -0500, Halevy, Benny wrote:
> Trond Myklebust wrote:
> >
> > On Thu, 2006-12-28 at 15:07 -0500, Halevy, Benny wrote:
> > > Mikulas Patocka wrote:
> >
> > > >BTW. how does (or how should?) NFS client deal with cache coherency if
> > > >filehandles for the same file di
201 - 300 of 386 matches
Mail list logo