-stable review patch. If anyone has any objections, please let us know.
--
While working on the saa7110 driver I found a problem with the way
various video drivers (found on Zoran-based boards) prepare i2c messages
to be used by i2c_transfer. The drivers improperly copy the
Hi,
Update of the NFS client. A lot of cleanups of the RPC auth code, but
also a couple of notable new features:
- flock support for NFS.
- Improved ESTALE recovery (Chuck + Al Viro).
- NFSv4 network partition recovery code
- bugfixes.
Cheers,
Trond
Please do a
bk
On Thu, 10 Mar 2005 23:20:14 +
Christoph Hellwig [EMAIL PROTECTED] wrote:
--- a/net/ipv4/tcp_timer.c 2005-03-09 17:20:38 -08:00
+++ b/net/ipv4/tcp_timer.c 2005-03-09 17:20:38 -08:00
@@ -38,6 +38,7 @@
#ifdef TCP_DEBUG
const char tcp_timer_bug_msg[] = KERN_DEBUG tcpbug:
-stable review patch. If anyone has any objections, please let us know.
--
Backport of fix described below.
From: Herbert Xu [EMAIL PROTECTED]
Fix bug #4223.
OK, this happened because we got preempted before sis900_mii_probe
finished setting the sis_priv-mii.
-stable review patch. If anyone has any objections, please let us know.
--
From: Eric Lammerts [EMAIL PROTECTED]
When I stat(2) a device node on a cramfs, the st_blocks field is bogus
(it's derived from the size field which in this case holds the major/minor
numbers). This
-stable review patch. If anyone has any objections, please let us know.
--
This is a rewrite of the saa7110_write_block function, which was plain
broken in the case where the underlying adapter supports I2C_FUNC_I2C.
It also includes related fixes which ensure that different
On Wed, Mar 09, 2005 at 05:32:00PM +, Linux Kernel wrote:
ChangeSet 1.1994.11.3, 2005/03/09 09:32:00-08:00, [EMAIL PROTECTED]
[PATCH] cpufreq 2.4 interface removal schedule
ChangeSet 1.1994.11.2, 2005/03/09 09:31:40-08:00, [EMAIL PROTECTED]
[PATCH] Add 2.4.x cpufreq
On Thursday 10 March 2005 03:59 pm, Russell King wrote:
On Thu, Mar 10, 2005 at 03:40:11PM -0700, Steven Cole wrote:
I'll test current bk tonight, but I don't see any recent fix to
drivers/serial/8250.c when browsing linux.bkbits.net/linux-2.6.
Ok, so Stephen's bug is already fixed. After
-stable review patch. If anyone has any objections, please let us know.
--
Fix for trivial fix for 2.6.11 oprofile compilation on e500 based ppc.
Signed-off-by: Andy Fleming [EMAIL PROTECTED]
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman
-stable review patch. If anyone has any objections, please let us know.
--
The status and received packets indication in the Rx descriptor ring
are not correctly reset when a descriptor is recycled.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Signed-off-by: Chris Wright
-stable review patch. If anyone has any objections, please let us know.
--
Egbert Eich reported a bug 2673 on bugs.freedesktop.org and tracked it
down to a missing memset in the setversion ioctl, this causes X server
crashes...
From: Egbert Eich [EMAIL PROTECTED]
On an VIA EPIA board, I got this single oops at boot. Wasn't stored on
file so I had to take a screenshot with a digital camera. Basicallly
goes along those lines:
Process: S36mountvirtfs
Call trace:
run_timer_softirq+0x16f/0x200
__do_softirq
do_softirq
irq_exit
do_IRQ
Convert XFS to use sem_getcount instead of nasty hack. Should fix warning
with XFS debugging on PARISC. Untested since there is no obvious way to
turn on XFS debugging.
Signed-off-by: Jody McIntyre [EMAIL PROTECTED]
Index: 1394-dev/fs/xfs/linux-2.6/xfs_buf.c
Convert 1394's node manager to use sem_getcount instead of nasty hack.
Tested on parisc (where it eliminates a warning), ia64, i386.
Signed-off-by: Jody McIntyre [EMAIL PROTECTED]
Index: 1394-dev/drivers/ieee1394/nodemgr.c
===
---
-stable review patch. If anyone has any objections, please let us know.
--
This wrecks the ipv6 modular build for a lot of people.
In fact, since I always build ipv6 modular I am surprised
I never hit this. My best guess is that my compiler is
optimizing the reference away,
parisc and frv define sem_getcount() in semaphore.h, which returns the
current semaphore value. This is cleaner than doing
atomic_read(semaphore.count), currently done in
drivers/ieee1394/nodemgr.c and fs/xfs/linux-2.6/xfs_buf.c, and will work
on all architectures if sem_getcount() is added.
On Thu, 10 Mar 2005, John Richard Moser wrote:
A Linux specific binary driver format might be more useful,
No, it wouldn't. I can use a source code driver on x86,
x86-64 and PPC64 systems, but a binary driver is only
usable on the architecture it was compiled for.
Source code is way more
On Fri, 4 Mar 2005 16:23:39 -0800
Jean Tourrilhes [EMAIL PROTECTED] wrote:
More trivial fixes in various places of the IrDA stack and
driver, no biggies. Freshly tested on 2.6.11, most have been on my web
pages for a while.
This should go in 2.6.12-rc1.
All applied, thanks Jean.
On Thursday March 10, [EMAIL PROTECTED] wrote:
On Thu, Mar 10, 2005 at 09:00:51PM +1100, Neil Brown wrote:
On Tuesday March 8, [EMAIL PROTECTED] wrote:
So here's a first cut at how this 2.6 -stable release process is going
to work that Chris and I have come up with. Does anyone have any
This could be part of the unknown 2% performance regression with
db transaction processing benchmark.
The four functions in the following patch use to be inline. They
are un-inlined since 2.6.7.
We measured that by re-inline them back on 2.6.9, it improves performance
for db transaction
Christian Kujau [EMAIL PROTECTED] wrote:
i was going to compile 2.6.11-rc5-bk4, to sort out the bad kernel.
compiling went fine. ok, finished some email, ok, suddenly my swap was
used up again, and no memory left - uh oh! OOM again, with 2.6.11-rc5-bk2!
Well if you ran out of swap then yes,
Chen, Kenneth W [EMAIL PROTECTED] wrote:
This could be part of the unknown 2% performance regression with
db transaction processing benchmark.
The four functions in the following patch use to be inline. They
are un-inlined since 2.6.7.
We measured that by re-inline them back on 2.6.9,
On Thu, Mar 10, 2005 at 11:17:03PM +0100, Ingo Oeser wrote:
David Gibson wrote:
Andrew, please apply.
Allow userspace programs on ppc64 to use the (privileged) mfpvr
instruction to determine the processor type. At the moment it
emulates the instruction to provide the real PVR value,
Hi Ralf,
On Thu, 10 Mar 2005 17:14:29 +
Ralf Baechle [EMAIL PROTECTED] wrote:
On Fri, Mar 04, 2005 at 01:16:57PM -0800, [EMAIL PROTECTED] wrote:
Signed-off-by: Yoichi Yuasa [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
@@ -307,7 +308,7 @@ asmlinkage void
On Fri, 2005-03-11 at 10:02 +1100, Benjamin Herrenschmidt wrote:
On Wed, 2005-02-23 at 02:25 +, Linux Kernel Mailing List wrote:
ChangeSet 1.1982.82.19, 2005/02/22 21:25:33-05:00, [EMAIL PROTECTED]
[AGPGART] Map the graphic card to the bridge its connected to.
Changelog:
- use Kconfig and CONFIG_CLEAR_PAGES
The zeroing of a page of a arbitrary order in page_alloc.c and in hugetlb.c may
benefit from a
clear_page that is capable of zeroing multiple pages at once. The following
patch adds
a function clear_pages that is capable of clearing multiple
On Thursday 10 March 2005 03:59 pm, Russell King wrote:
On Thu, Mar 10, 2005 at 03:40:11PM -0700, Steven Cole wrote:
I'll test current bk tonight, but I don't see any recent fix to
drivers/serial/8250.c when browsing linux.bkbits.net/linux-2.6.
Ok, so Stephen's bug is already fixed. After
Andrew Morton wrote:
Christian Kujau [EMAIL PROTECTED] wrote:
i was going to compile 2.6.11-rc5-bk4, to sort out the bad kernel.
compiling went fine. ok, finished some email, ok, suddenly my swap was
used up again, and no memory left - uh oh! OOM again, with 2.6.11-rc5-bk2!
Well if you ran
When I try to start X, my machine reboots. The screen goes dark as
usual when setting the video mode, but then I get a beep and I'm
greeted with the BIOS boot messages. This happened 4/5 times i've
tried, and once the video mode was actually set (at least I saw the
usual X b/w pattern with
Linus,
I see that you did a cset -x on a changeset from Dave Jones that added
a bogus test for which AGP bridge a device is under. That has left us
with code in agp_collect_device_status that will never find any device
(just take a look and you'll see).
In fact there are other bogosities in
On Thu, 2005-03-10 at 15:07 -0800, Greg KH wrote:
-stable review patch. If anyone has any objections, please let us know.
--
This is a rewrite of the saa7110_write_block function, which was plain
broken in the case where the underlying adapter supports I2C_FUNC_I2C.
It
So.. did we end up deciding that the Geode patch should be reverted
wholesale?
-
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.org/majordomo-info.html
Please read the FAQ at
On Thursday March 10, [EMAIL PROTECTED] wrote:
On Thu, 2005-03-10 at 21:00 +1100, Neil Brown wrote:
One rule that I thought would make sense, but that I don't see listed
is:
- must fix a regression
If some problem was in 2.6.X and is still there in 2.6.X+1, then there
is no great
Badari Pulavarty [EMAIL PROTECTED] wrote:
So, why is these slab cache are not getting purged/shrinked even
under memory pressure ? (I have seen lowmem as low as 6MB). What
can I do to keep the machine healthy ?
Tried increasing /proc/sys/vm/vfs_cache_pressure? (That might not be in
2.6.8
On Thursday 10 March 2005 16:52, Lee Revell wrote:
On Wed, 2005-03-09 at 08:27 -0600, K.R. Foley wrote:
Lee Revell wrote:
Of course all of the above settings provide flawless xrun-free
performance with 2.6.11-rc4 + PREEMPT_RT.
The above mentioned patch will apply (and build and run) just
On Fri, 11 Mar 2005, Paul Mackerras wrote:
Oh, and by the way, I have 3D working relatively well on my G5 with a
64-bit kernel (and 32-bit X server and clients), which is why I care
about AGP 3.0 support. :)
Ok, I can't even compile it on my G5, so you're obviously withholding some
Andrew Morton wrote:
Chen, Kenneth W [EMAIL PROTECTED] wrote:
This could be part of the unknown 2% performance regression with
db transaction processing benchmark.
The four functions in the following patch use to be inline. They
are un-inlined since 2.6.7.
We measured that by re-inline them back
On Thursday, March 10, 2005 5:24 pm, Paul Mackerras wrote:
The patch below fixes these problems. It will work in the 99.99% of
cases where we have one AGP bridge and one AGP video card. We should
eventually cope with multiple AGP bridges, but doing the matching of
bridges to video cards is a
Jesse Barnes writes:
I have a system in my office with several gfx pipes on different AGP busses,
and I'd like that to work well too! :)
Interesting, could you post the output from lspci -v on that system?
What is the relationship in the PCI device tree between the video
cards and their
On Thursday, March 10, 2005 6:11 pm, Paul Mackerras wrote:
What is the relationship in the PCI device tree between the video
cards and their bridges? Is there for instance only one AGP bridge
per host bridge?
I *think* a TIO (numalink-agp numalink-pci) has two AGP busses coming
off of it...
On Fri, Mar 11, 2005 at 01:18:36PM +1100, Paul Mackerras wrote:
Dave Jones writes:
cap_ptr = pci_find_capability(device, PCI_CAP_ID_AGP);
- if (!cap_ptr) {
- pci_dev_put(device);
- continue;
-
Chris Wedgwood wrote:
it's driver in windows can do it.
windows can get 200MB of memory on a running system relaibly? does it
swap like mad when you do this?
I'm guessing that driver isn't too likely to pass WHQL testing on
Windows either, whatever it's doing..
--
Robert Hancock
Dave Jones writes:
cap_ptr = pci_find_capability(device, PCI_CAP_ID_AGP);
- if (!cap_ptr) {
- pci_dev_put(device);
- continue;
- }
- cap_ptr = 0;
}
This part I'm not so sure about.
The
On Wed, 09 Mar 2005 20:45:35 +0100
Patrick McHardy [EMAIL PROTECTED] wrote:
Michal Vanco wrote:
I see this problem running 2.6.11 on dual AMD64:
Running quagga routing daemon (ospf+bgp) and issuing netstat -rn |wc
-l command
while quagga tries to load more than 154000 routes from
Ingo Oeser writes:
Why not putting the required information into the AUX table
when executing your ELF programs? I loved this feature in the
ix86 arch.
We do put an AT_HWCAP entry in the aux table, which is a bitmap of
features supported by the cpu. But for some applications, such as
On Fri, 11 Mar 2005, Paul Mackerras wrote:
The point is that pci_get_class does a pci_dev_put() on the from
parameter, so your code ended up doing a double put.
Ahh, I missed that too.
Hmm.. We seem to not have any tests for the counts becoming negative, and
this would seem to be an easy
This part I'm not so sure about.
The pci_get_class() call a few lines above will get a refcount that
we will now never release.
We will ... on the next loop iteration when we call pci_get_class again.
Thanks for taking a look at this. The absense of hardware to test
on means I pretty
On Thu, 10 Mar 2005, Dave Jones wrote:
/* ARQSZ - Set the value to the maximum one.
@@ -642,11 +638,6 @@
return 0;
}
cap_ptr = pci_find_capability(device, PCI_CAP_ID_AGP);
- if (!cap_ptr) {
-
After it does that pci_dev_put on the from, it does another pci_dev_get
on 'dev', which is what my put was releasing.
Or am I terribly confused ?
Well, pci_get_class() put's the passed-in device and get's() the
returned one. So if you run it in a loop, you should never have to
either get or
On Fri, Mar 11, 2005 at 11:10:37AM +1100, Neil Brown wrote:
I didn't mean If it fixes a regression, it should be accepted.
I meant If it does not fix a regression, it should not be accepted.
... Presumably with the obvious exception for security fixes.--b.
-
To unsubscribe from this list: send
On Fri, Mar 11, 2005 at 01:35:40PM +1100, Benjamin Herrenschmidt wrote:
This part I'm not so sure about.
The pci_get_class() call a few lines above will get a refcount that
we will now never release.
We will ... on the next loop iteration when we call pci_get_class again.
This patch adds AGP support for the U3 northbridge used in Apple G5
machines to drivers/char/agp/uninorth-agp.c. This patch is based on
earlier work by Jerome Glisse. With this patch, the driver works in
both ppc32 and ppc64 kernels.
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
diff -urN
On Thu, 2005-03-10 at 18:18 -0800, Jesse Barnes wrote:
On Thursday, March 10, 2005 6:11 pm, Paul Mackerras wrote:
What is the relationship in the PCI device tree between the video
cards and their bridges? Is there for instance only one AGP bridge
per host bridge?
I *think* a TIO
On Fri, Mar 11, 2005 at 01:40:24PM +1100, Benjamin Herrenschmidt wrote:
After it does that pci_dev_put on the from, it does another pci_dev_get
on 'dev', which is what my put was releasing.
Or am I terribly confused ?
Well, pci_get_class() put's the passed-in device and
On Thu, Mar 10, 2005 at 01:52:59PM -0500, Jon Smirl wrote:
Here's a big clue, if I build ata_piix in I can boot. If it is a
module I can't. The console output definitely shows that the module is
being loaded.
Can you post your config?
--
Mathematics is the supreme nostalgia of our time.
-
To
On Wednesday 09 March 2005 09:15 pm, Jeff Dike wrote:
This implements a hardware random number generator for UML which attaches
itself to the host's /dev/random.
Direct use of /dev/random always makes me nervous. I've had a recurring
problem with /dev/random blocking, and generally configure
On Thu, 10 Mar 2005 19:11:37 -0800, Matt Mackall [EMAIL PROTECTED] wrote:
On Thu, Mar 10, 2005 at 01:52:59PM -0500, Jon Smirl wrote:
Here's a big clue, if I build ata_piix in I can boot. If it is a
module I can't. The console output definitely shows that the module is
being loaded.
Can
As many of you will be aware, we've been working on infrastructure for
user-mode PCI and other drivers. The first step is to be able to
handle interrupts from user space. Subsequent patches add
infrastructure for setting up DMA for PCI devices.
The user-level interrupt code doesn't depend on
USER LEVEL DRIVERS: enable PCI device drivers at user space.
This patch adds the capability for suitably privileged user-level processes to
enable a PCI device, and set up DMA for it. A subsequent patch hooks up
the actual system calls.
There are three new system calls:
long
User-level drivers: Add system calls for I386 and IA64.
Signed-Off-By: Peter Chubb [EMAIL PROTECTED]
#
# arch/i386/kernel/entry.S |4
# arch/ia64/kernel/entry.S |8
# include/asm-i386/unistd.h |6 +-
# include/asm-ia64/unistd.h |4
# 4 files changed, 17
Patch to make detection of boot video device more robust. Should I
leave the printk in?
--
Jon Smirl
[EMAIL PROTECTED]
= arch/i386/pci/fixup.c 1.24 vs edited =
--- 1.24/arch/i386/pci/fixup.c 2005-01-11 19:42:41 -05:00
+++ edited/arch/i386/pci/fixup.c2005-03-10 22:32:35 -05:00
To contact us, please do_not_replyto.
See the bottom of this email to contact us by telephone or email.
It's absolutely right. You are going to get emails like this very soon
Quickly, send me an email or call me and you will get real com.miss.ion
emails with this
subject line and big, big
Microstate Accounting
-
Timing data on threads at present is pretty crude: when the timer
interrupt occurs, a tick is added to either system time or user time
for the currently running thread. Thus in an unpacthed kernel one can
distinguish three timed states: On-cpu in
On Thu, 2005-03-10 at 22:39 -0500, Jon Smirl wrote:
Patch to make detection of boot video device more robust. Should I
leave the printk in?
Hrm... yes, but make it KERN_DEBUG.
Ben.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Thu, Mar 10, 2005 at 07:08:26PM +0100, Moritz Muehlenhoff wrote:
I've got the e100 and with WOL disabled and Matthew's hacked radeontool
power consumption decreases to 970 mWh.
I have a T40p, and with the following patches (versus 2.6.11) and the
following sleep script, I have power
Microstate Accounting: Track time in system calls and interrupts, i386 code.
Signed-off-by; Peter Chubb [EMAIL PROTECTED]
arch/i386/kernel/entry.S | 16
arch/i386/kernel/irq.c | 13 -
Index: linux-2.6-ustate/arch/i386/kernel/entry.S
Microstate Accounting:
Add hooks into the scheduler to track state changes.
Arrange for parent process's child times to be updated at process exit.
kernel/sched.c |8
kernel/exit.c |3 +++
Index: linux-2.6-ustate/kernel/sched.c
Hi.
On Fri, 2005-03-11 at 14:02, Paul Mackerras wrote:
+struct agp_bridge_driver u3_agp_driver = {
+ .owner = THIS_MODULE,
+ .aperture_sizes = (void *)u3_sizes,
+ .size_type = U32_APER_SIZE,
+ .num_aperture_sizes = 8,
+
Microstate accounting:
Provide I386-dependent MSA clocks, and Kconfig options.
arch/i386/Kconfig | 39 ++-
include/asm-i386/msa.h | 49 +
2 files changed, 87 insertions(+), 1 deletion(-)
Microstate accounting: Add the I386 system call.
arch/i386/kernel/entry.S |2 +-
include/asm-i386/unistd.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6-ustate/arch/i386/kernel/entry.S
===
---
When detecting the boot video device, allow for the case of multiple
cards on the same bus. Check each candidate to make sure that the card
is active.
Signed off by: Jon Smirl [EMAIL PROTECTED]
--
Jon Smirl
[EMAIL PROTECTED]
= arch/i386/pci/fixup.c 1.24 vs edited =
---
Microstate accounting: Track time spent asleep while paging,
in poll() or select(), or on a futex separately from other sleeps.
fs/select.c |2 ++
kernel/futex.c |2 ++
mm/memory.c |6 +-
Index: linux-2.6-ustate/mm/memory.c
On Thursday, March 10, 2005 6:38 pm, Benjamin Herrenschmidt wrote:
That one is even worse... from what I see in your lspci output, you have
no bridge with AGP capability at all, and the various AGP devices are
all siblings...
Both of the video cards are sitting on agp busses in agp slots
Nigel Cunningham writes:
No power management support? :
The suspend/resume methods are in the pci_driver struct, not the
agp_bridge_driver struct. Not that we have suspend/resume on the G5
yet.
Paul.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Microstate accounting: Account for time in interrupt handlers for I386.
arch/i386/kernel/irq.c | 13 -
1 files changed, 12 insertions(+), 1 deletion(-)
Index: linux-2.6-ustate/arch/i386/kernel/irq.c
===
---
Peter Chubb [EMAIL PROTECTED] wrote:
Timing data on threads at present is pretty crude: when the timer
interrupt occurs, a tick is added to either system time or user time
for the currently running thread. Thus in an unpacthed kernel one can
distinguish three timed states: On-cpu in
No power management support? :
Heh, not yet :) We can't really put a G5 to sleep yet. I haven't figured
out the magic incantations for the PMU chip on those.
Ben.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Hi.
On Fri, 2005-03-11 at 15:02, Paul Mackerras wrote:
Nigel Cunningham writes:
No power management support? :
The suspend/resume methods are in the pci_driver struct, not the
agp_bridge_driver struct. Not that we have suspend/resume on the G5
yet.
Ah. Thought I'd seen some in others.
On Thu, 2005-03-10 at 20:02 -0800, Jesse Barnes wrote:
On Thursday, March 10, 2005 6:38 pm, Benjamin Herrenschmidt wrote:
That one is even worse... from what I see in your lspci output, you have
no bridge with AGP capability at all, and the various AGP devices are
all siblings...
Both of
Microstate Accounting:
Add suppoort for IA64.
linux-2.6-ustate/arch/ia64/Kconfig | 25 +++
linux-2.6-ustate/arch/ia64/kernel/entry.S| 44 +++
linux-2.6-ustate/arch/ia64/kernel/irq_ia64.c | 21 +++-
in_atomic() is not a reliable indication of whether it is currently safe
to call schedule().
This is because the lockdepth beancounting which in_atomic() uses is only
accumulated if CONFIG_PREEMPT=y. in_atomic() will return false inside
spinlocks if CONFIG_PREEMPT=n.
Consequently the use of
Consequently the use of in_atomic() in the below files is probably
deadlocky if CONFIG_PREEMPT=n:
...
drivers/infiniband/core/mad.c
Thanks for pointing this out. I'll get you a patch in the next day or
two. As you can probably tell, the code is just trying to decide
whether
Jody McIntyre [EMAIL PROTECTED] wrote:
parisc and frv define sem_getcount() in semaphore.h, which returns the
current semaphore value. This is cleaner than doing
atomic_read(semaphore.count), currently done in
drivers/ieee1394/nodemgr.c and fs/xfs/linux-2.6/xfs_buf.c, and will work
on
On Thu, 2005-03-10 at 22:46 -0500, Theodore Ts'o wrote:
On Thu, Mar 10, 2005 at 07:08:26PM +0100, Moritz Muehlenhoff wrote:
I've got the e100 and with WOL disabled and Matthew's hacked radeontool
power consumption decreases to 970 mWh.
I have a T40p, and with the following patches (versus
jerome lacoste [EMAIL PROTECTED] wrote:
On an VIA EPIA board, I got this single oops at boot. Wasn't stored on
file so I had to take a screenshot with a digital camera. Basicallly
goes along those lines:
Process: S36mountvirtfs
Call trace:
run_timer_softirq+0x16f/0x200
Neil Brown wrote:
If a data corruption bug has been there for 10 weeks without being
noticed, then the real risk is not that great. We are calling it
-release, not -hardened.
I disagree. If there's a simple, obvious, small fix that passes all the
other criteria, it should go into -stable ASAP
Andrew == Andrew Morton [EMAIL PROTECTED] writes:
Andrew Peter Chubb [EMAIL PROTECTED] wrote:
Timing data on threads at present is pretty crude: when the timer
interrupt occurs, a tick is added to either system time or user
time for the currently running thread. Thus in an unpacthed kernel
Andrew (Why do they want to do this anyway?)
Neither use seems really fundamental. The XFS use is explicitly
inside #ifdef DEBUG and seems to be used only for assertions.
ieee1394 is just sticking the value in a read-only sysfs attribute.
- R.
-
To unsubscribe from this list: send the line
drivers/video/intelfb/intelfbdrv.h:31: warning: 'intelfb_setup' declared
`static' but never defined
-
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.org/majordomo-info.html
Please read
Lennart Sorensen writes:
You forgot the very important:
- Only works on architecture it was compiled for. So anyone not
using i386 (and maybe later x86-64) is simply out of luck. What do
nvidia users that want accelerated nvidia drivers for X DRI do
right now if they have
On Thu, Mar 10, 2005 at 09:10:42PM -0800, Roland Dreier wrote:
Andrew (Why do they want to do this anyway?)
Neither use seems really fundamental. The XFS use is explicitly
inside #ifdef DEBUG and seems to be used only for assertions.
Right, our peeking at that value is debug-only (so
Hi,
2.6.10-as is now in purely maintenance mode; that is, I'll only include
security fixes or quick things that people send me (that don't require
much effort on my part :). This includes the security fix from
2.6.11.2. I'll have 2.6.11-as1 soon, after I sync up w/ Debian stuff
and go through
On Thu, Mar 10, 2005 at 03:04:18PM -0800, long wrote:
PCI Express error signaling can occur on the PCI Express link itself
or on behalf of transactions initiated on the link. PCI Express
defines the Advanced Error Reporting capability, which is implemented
with a PCI Express advanced error
Peter Chubb writes:
There are three new system calls:
long usr_pci_open(int bus, int slot, int function, __u64 dma_mask);
Returns a filedescriptor for the PCI device described
by bus,slot,function. It also enables the device, and sets it
up as a
Hi !
This patch removes the call to unblank() from printk, and avoids calling
unblank at irq() time _unless_ oops_in_progress is 1. I also export
oops_in_progress() so drivers who care like radeonfb can test it and
know what to do. I audited call sites of unblank_screen(),
console_unblank(),
On Thu, Mar 10, 2005 at 08:55:03PM -0800, Andrew Morton wrote:
Jody McIntyre [EMAIL PROTECTED] wrote:
parisc and frv define sem_getcount() in semaphore.h, which returns the
current semaphore value. This is cleaner than doing
atomic_read(semaphore.count), currently done in
Vendor Sealevel suggested these changes for its new board. Tried them,
they work with the card. Please apply the patch below, which was made
from 2.6.10 but can be applied to 2.6.11.2 without errors.
Dick
--- linux/drivers/serial/8250_pci.orig 2005-03-10 13:09:39.0 -0600
+++
fix: drivers/base/class.c
fix how? What are you fixing?
I'm sorry. Previous subject was [PATCH 2.6.11] fix call kobject_get_path()
with zero kobject argument in drivers/base/class.c
diff -uNrp linux/drivers/base/class.orig.c linux/drivers/base/class.c
---
If this is the same version as in 2.6.11-mm2 (you didn't offer a GNU
patch so that I could check it), the following is still present:
http://www.ussg.iu.edu/hypermail/linux/kernel/0502.2/1507.html
Thanks Adrian, I forgot about that one.
It is now fixed and pushed to
Hi !
The powermac has a kernel-based driver for controlling the backlight
from the keyboard that used to call into some fbdev's from interrupt
contexts. This patch moves it to a workqueue (and additionally makes
sure the console semaphore is taken and held).
I hope I'll replace this by the new
601 - 700 of 718 matches
Mail list logo
