On Thu, Mar 10, 2005 at 07:37:40PM -0600, Josh Boyer wrote:
> 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
>
On Fri, Mar 11, 2005 at 02:14:14AM +0100, Christian Kujau wrote:
> 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
Hi,
My box gets stuck while booting (actually starting ntpd) whith tonight
pull from Linus. It looks like it is spinning in ipt_do_table when I do
SysRq-P. No call trace though.
Anyone else seeing it? Any ideas?
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe
On Fri, Mar 11, 2005 at 02:37:17PM +1100, Peter Chubb wrote:
> +/*
> + * The PCI subsystem is implemented as yet-another pseudo filesystem,
> + * albeit one that is never mounted.
> + * This is its magic number.
> + */
> +#define USR_PCI_MAGIC (0x12345678)
If you make it a real, mountable
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> The iMac G5 and new single CPU PowerMac G5 come with a new revision of
> the K2 ASIC called Shasta. The PATA cell in there now does 133Mhz. This
> patch adds support for it. It also adds some power management bits to
> the old 100MHz cell
Andrew Morton <[EMAIL PROTECTED]> writes:
> Why does the kernel need this feature?
>
> Have you any numbers on the overhead?
It does RDTSC and lots of complicated stuff twice for each system call.
On P4 this will be extremly slow (> 1000cycles combined)
It is pretty unlikely that whatever it
Chris Friesen <[EMAIL PROTECTED]> writes:
> 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
On Thu, 2005-03-10 at 11:27 +0100, Lars Marowsky-Bree wrote:
> On 2005-03-09T18:36:37, Alex Aizman <[EMAIL PROTECTED]> wrote:
> > >That works well in our current development series, and if you want to
> > >share code, you can either rip it off (Open Source, we love ya ;) or we
> > >can spin off
Hi !
The iMac G5 and latest single-cpu PowerMac G5 have seen the venerable
PMU (Power Management Unit) chip been sent to well deserved retirement.
It has been replaced by a newcomer, the SMU (System Management Unit ?)
which is of course totally undocumented and has no open source darwin
driver...
Hi !
The iMac G5 has some issues with Apple chips not having a valid
PCI_INTERRUPT_PIN. This patch fixes IRQ routing on PowerMac
platforms so that it only relies on the Open Firmware informations
which are correct.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: J. Mayer
Hi !
The iMac G5 and new single CPU PowerMac G5 come with a new revision of
the K2 ASIC called Shasta. The PATA cell in there now does 133Mhz. This
patch adds support for it. It also adds some power management bits to
the old 100MHz cell that was in Intrepid based ppc32 machines.
The original
Greetings Bartlomiej,
I've updated the following
* in_flags modification when out_flags != 0 && in_flags == 0
* more than one -> one or more than one
* tf_{in|out}_flags -> {in|out}_flags as tf_* are in-kernel names
I'll update the taskfile patch series after receiving your comments
about
Hi Andrew,
On Thu, 10 Mar 2005 20:40:06 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> in_atomic() is not a reliable indication of whether it is currently safe
> to call schedule().
>
> arch/ppc64/kernel/viopath.c
in_atomic() in viopath.c was just used to determine if we had
Hi !
The ppc64 vDSO is still exporting LINUX_2.6.11 (from -mm) for symbol
versioning. The glibc folks asked me to export the first kernel version
that will contain it, so this patch fixes it to LINUX_2.6.12
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Index:
Hello Marcelo,
I've got a fix for you on 2.4. I got reports of stalls with heavy writes
on 2.4. There was a mistake in nr_free_buffer_pages. That function is
definitely meant _not_ to take highmem into account (dirty cache cannot
spread over highmem in 2.4 [even when on top of fs]). For unknown
Jody McIntyre <[EMAIL PROTECTED]> wrote:
>
> 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
>
On Thu, Mar 10, 2005 at 04:58:51PM -0500, Felix Matathias wrote:
>
> I am running a 2.4.21-9.0.3.ELsmp #1 kernel and I can setsockopt and
> getsockopt correctly the SO_RCVLOWAT option, but select() seems to mark a
> socket readable even if a single byte is ready to be read. Then, a read()
>
Hi !
After discussion with ATIs, it seems that the workarounds they initially
gave me were not completely correct.
This patch implements the proper ones, which includes sleeping in PLL
accesses, and thus requires the previous patch to make sure we do not
call unblank at interrupt time (unless
> 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
> > 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
> > ---
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
+++
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(), currently done in
> >
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
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
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 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
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
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
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
> "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
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
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
>
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
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(), currently done in
> drivers/ieee1394/nodemgr.c and fs/xfs/linux-2.6/xfs_buf.c, and will work
> on all
> 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
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
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 +++-
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...
>
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
>
> 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
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:
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
===
---
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
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
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
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:
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(-)
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:
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
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
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
-
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
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
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
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
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
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.
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
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.
-
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
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
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 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
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:
> 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
>
> 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
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) {
> > -
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
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 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
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
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
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);
> > > -
On Fri, Mar 11, 2005 at 12:24:54PM +1100, Paul Mackerras wrote:
> In fact there are other bogosities in drivers/char/agp/generic.c. I
> can't believe Dave ever tested that code with an AGP 3.0 device.
Hrmm, I'm fairly sure I did. It's also been sat in -mm without complaint
for a few weeks,
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 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
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
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
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
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
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
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 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.
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
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!
>
>
>
>
> 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
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.
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 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.
> >
> >
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 @@
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
"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
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
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
1 - 100 of 718 matches
Mail list logo
