On Wed, 16 May 2007 23:36:56 -0700,
"Williams, Dan J" <[EMAIL PROTECTED]> wrote:
> async_tx: add the Kconfig infrastructure for async_tx
>
> From: Dan Williams <[EMAIL PROTECTED]>
>
> async_tx is similar to crypto in that there is an api component and a
> drivers component.
>
> * Add 'source
> > Yes, on some implementations there can be other conditions that
> > make a decrementer exception go away; there is no contradiction
> > here (thankfully). My wording was sloppy.
>
> Some CPUs have the DEC exceptions basically edge triggered (yeah I know
for example?
> it sucks). That's
On Thu, May 17, 2007 at 10:22:17PM -0700, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Fri, 18 May 2007 07:12:38 +0200
>
> > The page->virtual thing is just a bonus (although have you seen what
> > sort of hoops SPARSEMEM has to go through to find page_address?! It
> > will
On 5/18/07, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
On Thu, May 17, 2007 at 03:43:26PM -0400, Benjamin LaHaise wrote:
> On Thu, May 17, 2007 at 01:39:54PM -0600, Matthew Wilcox wrote:
> > On Fri, May 18, 2007 at 12:34:40AM +0530, Satyam Sharma wrote:
> > > Hmmm, actually those other users
From: Nick Piggin <[EMAIL PROTECTED]>
Date: Fri, 18 May 2007 07:12:38 +0200
> The page->virtual thing is just a bonus (although have you seen what
> sort of hoops SPARSEMEM has to go through to find page_address?! It
> will definitely be a win on those architectures).
If you set the bit ranges
On Thu, May 17, 2007 at 09:47:40PM -0700, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Fri, 18 May 2007 06:08:54 +0200
>
> > I'd like to be the first to propose an increase to the size of struct page
> > just for the sake of increasing it!
> >
> > If we add 8 bytes to
>
> Yes, on some implementations there can be other conditions that
> make a decrementer exception go away; there is no contradiction
> here (thankfully). My wording was sloppy.
Some CPUs have the DEC exceptions basically edge triggered (yeah I know
it sucks). That's why, among others, the IRQ
From: Nick Piggin <[EMAIL PROTECTED]>
Date: Fri, 18 May 2007 06:08:54 +0200
> I'd like to be the first to propose an increase to the size of struct page
> just for the sake of increasing it!
>
> If we add 8 bytes to struct page on 64-bit machines, it becomes 64 bytes,
> which is quite a nice
-rt adds a futex_performance_hack sysctl, which is only defined if
kernel/futex.c is built in. This fixes the build in the CONFIG_FUTEX=n
case.
Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>
--
kernel/sysctl.c |2 ++
1 file changed, 2 insertions(+)
--- linux-2.6.21-rt3/kernel/sysctl.c
On Friday 18 May 2007 04:18, Davide Libenzi wrote:
> This fixed oprofile being broken on x86-64 SMP. The current reservation
> runs on all CPUs, but the ones following the first, will fail since the
> reservation bitmap has an 1 in the MSR entry.
> The reservation code should really run once, and
On Thursday 17 May 2007 16:49, Thomas Gleixner wrote:
> Both read the PIT directly, which will lead to interesting results. The
> PIT is either stopped or it can be used in one shot mode with per event
> changing intervals due to the changes introduced by the clock events
> layer.
>
> This code
On Sun, May 13, 2007 at 05:38:53PM +0200, Ingo Molnar wrote:
>> So i've added a yield workaround to -v12, which makes it work similar to
>> how the vanilla scheduler and SD does it. (Xorg has been notified and
>> this bug should be fixed there too. This took some time to debug because
>> the 3D
Hi,
I'd like to be the first to propose an increase to the size of struct page
just for the sake of increasing it!
If we add 8 bytes to struct page on 64-bit machines, it becomes 64 bytes,
which is quite a nice number for cache purposes.
However we don't have to let those 8 bytes go to waste:
the previous post i keep referring you to has a patch that was mangled
...here is the non-mangled version
--- ./linux-backup/arch/x86_64/kernel/cpufreq/Kconfig 2007-02-04
13:44:54.0 -0500
+++ ./linux-2.6.21-rc5-mm2/arch/x86_64/kernel/cpufreq/Kconfig
2007-05-17 18:13:07.0
Joshua Hoblitt wrote:
I think it's pretty clear that Dave and Daniel were both correct and
that ACPI_PROCESSOR is the correct dependency for multi-socket systems.
However, it's worth noting that this dependency seems to be unrelated to
SMP support. Ed Sweetman has reported that his
Rik van Riel wrote:
> Balbir Singh wrote:
>
>> A meaningful container size does not hamper performance. I am in the
>> process
>> of getting more results (with varying container sizes). Please let me
>> know
>> what you think of the results? Would you like to see different
>> benchmarks/
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christoph Lameter wrote:
> On Thu, 17 May 2007, Frank Sorenson wrote:
>> Frank Sorenson wrote:
>>
>>> Hrm. Looks like it gets past the hpet_is_known There's still something
>>> in the hpet detection code, but I didn't get to the bottom of it yet.
Andrew Morton wrote:
> On Thu, 17 May 2007 23:20:12 +0530
> Balbir Singh <[EMAIL PROTECTED]> wrote:
>
>> A meaningful container size does not hamper performance. I am in the process
>> of getting more results (with varying container sizes). Please let me know
>> what you think of the results?
Hi,
poll_wait() callback may modify the waitqueue without holding the
context private lock.
Signed-off-by: Davi E. M. Arnaut <[EMAIL PROTECTED]>
diff --git a/fs/eventfd.c b/fs/eventfd.c
index 480e2b3..9c672be 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -50,7 +50,7 @@ int
On Thu, May 17, 2007 at 01:39:54PM -0600, Matthew Wilcox wrote:
> On Fri, May 18, 2007 at 12:34:40AM +0530, Satyam Sharma wrote:
> > Hmmm, actually those other users could easily write and maintain
> > a 20-line patch that does the wait for async scans thing for them
> > using /proc/scsi/scsi in
Hi,
On Wed, 16 May 2007, Al Viro wrote:
> On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote:
> >
> > stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
> > end up with unbuildable configs.
>
> BTW, this kind of situation happens often enough, so how about doing
> the
Jeff Garzik wrote:
Jan Engelhardt wrote:
On May 16 2007 10:42, Chris Mason wrote:
For example, I'll pick on xfs for a minute. compilebench shows the
default FS you get from mkfs.xfs is pretty slow for untarring a bunch of
kernel trees.
I suppose you used 'nobarrier'? [
On 18 May 2007 10:52:57 +0800 Zou Nan hai <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-05-18 at 03:32, Andrew Morton wrote:
> > On 17 May 2007 10:40:07 +0800
> > Zou Nan hai <[EMAIL PROTECTED]> wrote:
> >
> > >
> > Please always prefer to use static inline functions rather than macros.
> > They
Sergei Shtylyov writes:
Kumar Gala wrote:
[Sergei Shtylyov]
Kumar Gala wrote:
I haven't looked at all the new clock/timer code, is there any
utility in having support for more than one clock source?
Of course, you may register as many as you like.
Sure, but is there any utility in
On Tue, May 15, 2007 at 08:52:12PM +0200, Luca Tettamanti wrote:
>
> CONFIG_CRYPTO_ALGAPI=m
Are you sure you're actually running 2.6.22-rc1? Due to a bug
in the padlock patch present in 2.6.22-rc1 it shouldn't be
possible to select ALGAPI as a module.
Cheers,
--
Visit Openswan at
On Thu, 2007-05-17 at 22:57 -0400, John Anthony Kazos Jr. wrote:
> Wouldn't the appropriate test be to demonstrate that the same program text
> opcodes are generated in both cases for all architectures?
No, empirical testing with the compiler is never the _correct_ thing to
do. It's just
Hi Bill,
On 5/18/07, Bill Davidsen <[EMAIL PROTECTED]> wrote:
Satyam Sharma wrote:
> *Unfortunately* (the trouble with C itself, is that a *committee* has made
> it into ... something ... that it should not have made it into) -- anyway,
> unfortunately C took it upon itself to solve a problem
I think it's pretty clear that Dave and Daniel were both correct and
that ACPI_PROCESSOR is the correct dependency for multi-socket systems.
However, it's worth noting that this dependency seems to be unrelated to
SMP support. Ed Sweetman has reported that his single-socket but
multi-core system
Balbir Singh wrote:
A meaningful container size does not hamper performance. I am in the process
of getting more results (with varying container sizes). Please let me know
what you think of the results? Would you like to see different benchmarks/
tests/configuration results?
AIM7 results
On Fri, 18 May 2007, David Woodhouse wrote:
> On Thu, 2007-05-17 at 20:30 +, Matthieu CASTET wrote:
> > On Thu, 17 May 2007 10:29:31 -0700, Andrew Morton wrote:
> >
> > > On Thu, 17 May 2007 18:09:50 +0300 Artem Bityutskiy
> > > <[EMAIL PROTECTED]> wrote:
> > >
> > > umm.. I'd say what
On Fri, 2007-05-18 at 03:32, Andrew Morton wrote:
> On 17 May 2007 10:40:07 +0800
> Zou Nan hai <[EMAIL PROTECTED]> wrote:
>
> >
> Please always prefer to use static inline functions rather than macros.
> They are more readable, they are more likely to have comments attached to
> them and they
Lguest guests don't use the TSC, and so we must disable it otherwise
sched-clock.c barfs.
Also, we no longer need to explicitly set the PGE feature bit:
cpu_detect->cpuid->lguest_cpuid does that for us now that cpu_detect
uses paravirt_ops (IIRC it used to do a direct cpuid from assembler).
Andrew patched up lguest after the boot parameters became a proper
structure, but in fact it can be considerably neatened.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r ffe7ce731118 drivers/lguest/lguest.c
--- a/drivers/lguest/lguest.c Fri May 18 10:18:56 2007 +1000
+++
(Not sure who's code this is, but it's in 2.6.22-rc1-mm1):
If you set tsc_disable (eg "notsc" on cmdline), sched-clock.c gives a
divide by zero on boot.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r fd2ae7085ca2 arch/i386/kernel/sched-clock.c
--- a/arch/i386/kernel/sched-clock.c
On Thu, 2007-05-17 at 20:30 +, Matthieu CASTET wrote:
> On Thu, 17 May 2007 10:29:31 -0700, Andrew Morton wrote:
>
> > On Thu, 17 May 2007 18:09:50 +0300 Artem Bityutskiy
> > <[EMAIL PROTECTED]> wrote:
> >
> > umm.. I'd say what you've done in there is an improvement to the
> > exiting
David Howells wrote:
Nick Piggin <[EMAIL PROTECTED]> wrote:
No, you shouldn't. We could theoretically introduce a new API for this,
but I think it would be preferable if you can fix the race in the fs.
Actually, I might be able to do better.
When making a StoreData call to the AFS server,
Hey Andrew, Andi,
The vsyscall time() function basically returns the second portion of
xtime directly. This however means that there is about a ticks worth of
time each second where time() will return a second value less then what
gettimeofday() does.
Additionally, this window where
This fixed oprofile being broken on x86-64 SMP. The current reservation
runs on all CPUs, but the ones following the first, will fail since the
reservation bitmap has an 1 in the MSR entry.
The reservation code should really run once, and their addresses used on
other CPUs. There are other
On Thu, May 17, 2007 at 10:05:11PM +0200, Michal Piotrowski wrote:
> I applied your patch and I get another oops
>
> [ 261.491499] XFS mounting filesystem loop0
> [ 261.501641] Ending clean XFS mount for filesystem: loop0
> [ 261.507698] SELinux: initialized (dev loop0, type xfs), uses xattr
>
Zoltan Boszormenyi wrote:
Hi,
thanks for publishing this.
Add the Software NCQ support to sata_nv.c for MCP51/MCP55/MCP61 SATA
controller.
This patch base on sata_nv.c file from kernel 2.6.22-rc1
See attachment for the patch.
Signed-off-by: Kuan Luo <[EMAIL PROTECTED]>
Signed-off-by: Peer
Peer Chen wrote:
Add the Software NCQ support to sata_nv.c for MCP51/MCP55/MCP61 SATA
controller.
This patch base on sata_nv.c file from kernel 2.6.22-rc1
See attachment for the patch.
Signed-off-by: Kuan Luo <[EMAIL PROTECTED]>
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
Good to finally
Main thing of note: still sorting out the shutdown mess. See the
extended commit texts for more info.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
Documentation/networking/netdevices.txt |2 +-
drivers/net/e1000/e1000.h |4 +-
drivers/net/e1000/e1000_main.c
On Thu, 2007-05-17 at 22:29 +0200, Fabio Comolli wrote:
> Is there a reason why this patch can't go upstream?
Yes. A change of that magnitude will most certainly introduce
regressions. So we can either:
- Have it in -mm for monthes trying to iron out all of them (and we'll
miss some). And
> This is what I'm using here, it's still the same old patch (Solomon's
> plus my stuff). I think I can coordinate with [EMAIL PROTECTED] to
> create an incremental patch to fix radeonfb on his hardware (provided
> that this mega-patch is suitable as baseline that is).
Yes, I would very much
On Thursday, May 17, 2007, Luca Tettamanti wrote:
> Il Thu, May 17, 2007 at 03:37:45PM -0700, Jesse Barnes ha scritto:
> > This patch adds the core of the new DRM based modesetting system.
>
> A couple of comments on drm_fb since I'm somewhat familiar with fb code:
> > new file mode 100644
> >
On May 17, 2007, at 13:45:33, Evgeniy Polyakov wrote:
On Thu, May 17, 2007 at 07:26:07PM +0200, Jan Engelhardt
([EMAIL PROTECTED]) wrote:
My plan was to move this code to lib/ sooner or later. If you
consider it useful in its current state, I can do it immediatly.
And if someone else
On Thu, May 17, 2007 at 05:30:13PM -0700, Eric W. Biederman wrote:
> So why does any of this matter?
>
> My memory says that the ioapic state for sending irqs gets reset when we
> unmask the irq.
No. Atleast not on the platform we have tested.
> If not I expect we can use the mask and edge,
On Thu, May 17, 2007 at 05:18:41PM -0700, Bill Huey wrote:
> On Sun, May 13, 2007 at 05:38:53PM +0200, Ingo Molnar wrote:
> > Even a simple 3D app like glxgears does a sys_sched_yield() for every
> > frame it generates (!) on certain 3D cards, which in essence punishes
> > any scheduler that
Tejun Heo wrote:
As with all other drivers, sata_nv's hpriv is allocated with
devm_kzalloc() and there's no need to free it explicitly. Kill
nv_remove_one() which incorrectly used kfree() instead of devm_kfree()
and use ata_pci_remove_one() directly.
Original fix is from Peer Chen.
On Thursday, May 17, 2007, Antonino A. Daplas wrote:
> On Thu, 2007-05-17 at 15:32 -0700, Jesse Barnes wrote:
> > Randy just informed me that the patch limits are bigger now, so here
> > are the actual patches.
> >
> > This patch allows for proper console unregistration via the VT layer,
> > and
On Thu, 17 May 2007 12:19:59 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > + if (!windows)
> > + goto out2;
> > controller->window = kmalloc_node(sizeof(*controller->window) * windows,
> > GFP_KERNEL, controller->node);
> > if (!controller->window)
> >
On Thu, May 17, 2007 at 04:58:02PM -0700, Eric W. Biederman wrote:
> In essence this makes sense, and it may be the best work around for
> buggy hardware available. However I am not convinced that the remote
> IRR on ioapics works reliably enough to be used for anything. I
> tested this
On Thu, 17 May 2007 19:01:43 + (GMT)
Francis Russell <[EMAIL PROTECTED]> wrote:
> I'm testing Linux kernel version 2.6.22-rc1 using Debian Testing on an Acer
> Ferrari 3400 Laptop. This has a VIA IDE controller with the internal HDD and
> DVD writer attached. The via_pata module and SCSI
Jean Delvare wrote:
Hi Michal,
On Sun, 13 May 2007 20:14:45 +0200, Michal Piotrowski wrote:
I2C
Subject: "Sensors Applet" give an error message "No chip detected"
References : http://lkml.org/lkml/2007/5/13/109
Submitter : Antonino Ingargiola <[EMAIL PROTECTED]>
Status : Unknown
"Siddha, Suresh B" <[EMAIL PROTECTED]> writes:
> on x86_64 kernel, level triggered irq migration gets initiated in the context
> of that interrupt(after executing the irq handler) and following steps are
> followed to do the irq migration.
>
> 1. mask IOAPIC RTE entry; // write to IOAPIC RTE
On Friday May 18, [EMAIL PROTECTED] wrote:
> Fix confirmed, filled the whole 11T hard disk, without crashing.
> I presume this would go into 2.6.22
Yes, and probably 2.6.21.y, though the patch will be slightly
different, see below.
>
> Thanks again.
And thank-you for pursuing this with me.
On Sun, May 13, 2007 at 05:38:53PM +0200, Ingo Molnar wrote:
> Even a simple 3D app like glxgears does a sys_sched_yield() for every
> frame it generates (!) on certain 3D cards, which in essence punishes
> any scheduler that implements sys_sched_yield() in a sane manner. This
> interaction of
greg
and part of /etc/udev/rules.d/60-libsane.rules
...
ACTION!="add", GOTO="libsane_rules_end"
SUBSYSTEM!="usb_device", GOTO="libsane_rules_end"
# Hewlett-Packard ScanJet 4100C
SYSFS{idVendor}=="03f0", SYSFS{idProduct}=="0101", SYMLINK+="scanner-%k"
# Hewlett-Packard Photosmart S20 (C5101A) |
Hi,
On 5/18/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
Hi!
Hmm.. so operating your camera on batteries should be against the
warranty, since batteries commonly run empty while storing pictures?
AFAIK, the camera stops writing to the flash card and automatically
turns off when it's low on
"Siddha, Suresh B" <[EMAIL PROTECTED]> writes:
> on x86_64 kernel, level triggered irq migration gets initiated in the context
> of that interrupt(after executing the irq handler) and following steps are
> followed to do the irq migration.
>
> 1. mask IOAPIC RTE entry; // write to IOAPIC RTE
On Thu, 17 May 2007, H. Peter Anvin wrote:
+Field name:kernel_version
+Type: read
+Offset/size: 0x20e/2
+Protocol: 2.00+
+
+ If set to a nonzero value, contains a pointer to a null-terminated
"nil-terminated"? "\0-terminated"?
Uh? That seems more than a little silly.
Satyam Sharma wrote:
*Unfortunately* (the trouble with C itself, is that a *committee* has made
it into ... something ... that it should not have made it into) -- anyway,
unfortunately C took it upon itself to solve a problem that it did not
have (and does not even bring about) in the first
Hi, Phillip,
I have said the gap between you and me is the definition of context.
In Robert's definition, *context* is used in a classification method
and really something in higher-level. And I used that term to explain
why ISR can not sleep.
If you do not like the name, name it your way and
On Thu, 17 May 2007 11:11:42 +0200
Matthias Andree <[EMAIL PROTECTED]> wrote:
> [please remember to Cc: me on your replies]
>
> Greetings,
>
> is there an easy way to dump a process's pagetables from outside that
> process? Tools, /proc or /sys file or syscall that I missed?
>
On Thu, 17 May 2007 16:30:44 -0700 Jeremy Fitzhardinge wrote:
> >>> + If set to a nonzero value, contains a pointer to a null-terminated
> >>>
> >>>
> >> "nil-terminated"? "\0-terminated"?
> >>
> >
> > Uh? That seems more than a little silly. Yes, I guess formally
> > speaking
Ingo Molnar wrote:
* Peter Williams <[EMAIL PROTECTED]> wrote:
Load balancing appears to be badly broken in this version. When I
started 4 hard spinners on my 2 CPU machine one ended up on one CPU
and the other 3 on the other CPU and they stayed there.
could you try to debug this a bit
Il Thu, May 17, 2007 at 03:37:45PM -0700, Jesse Barnes ha scritto:
> This patch adds the core of the new DRM based modesetting system.
A couple of comments on drm_fb since I'm somewhat familiar with fb code:
> new file mode 100644
> index 000..0d06792
> --- /dev/null
> +++
Andi Kleen wrote:
> Hmpf.
>
> We cold either use rdmsr_safe or add a family check again or clear it
> in k6 setup. I think clearing it in setup is cleanest.
>
> Does this patch work?
>
> -Andi
>
> Clear MCE flag on AMD K6
>
> It reports machine check capability in CPUID, but doesn't
Jeremy Fitzhardinge wrote:
> H. Peter Anvin wrote:
>> Given that we have already established littleendian byte order, it's the
>> same thing.
>>
>
> Well, not quite; mentioning the string form first creates an ambiguity.
> I'd express as something like: ``The magic number is 0x53726448
>
Philipp Kohlbecher wrote:
>
> I don't know of any problems this causes. The kernel needs to be aware
> of the fact that the xss and esp fields of the pt_regs struct may
> contain wrong values anyway, as hardware interrupts arriving while the
> CPU is in kernel mode would also lead to this
H. Peter Anvin wrote:
> Given that we have already established littleendian byte order, it's the
> same thing.
>
Well, not quite; mentioning the string form first creates an ambiguity.
I'd express as something like: ``The magic number is 0x53726448
(implicitly, stored little-endian), which
H. Peter Anvin wrote:
> Philipp Kohlbecher wrote:
>> From: Philipp Kohlbecher <[EMAIL PROTECTED]>
>>
>> The kernel_execve function issues a software interrupt (int 0x80) to make
>> a system call to sys_execve. This function expects to find the stack segment
>> and stack pointer of the function
I have posted the results of my initial testing, measuring IPC rates
using various schedulers under no load, limited nice load, and heavy
load at nice 0.
http://www.tmr.com/~davidsen/ctxbench_testing.html
--
bill davidsen <[EMAIL PROTECTED]>
CTO TMR Associates, Inc
Doing interesting things
On Thu, 2007-05-17 at 15:32 -0700, Jesse Barnes wrote:
> Randy just informed me that the patch limits are bigger now, so here are the
> actual patches.
>
> This patch allows for proper console unregistration via the VT layer, and
> updates the FB layer to use it. This makes debugging new console
Jeremy Fitzhardinge wrote:
> H. Peter Anvin wrote:
>> +Field name: boot_flag
>> +Type: read
>> +Offset/size:0x1fe/2
>> +Protocol: ALL
>> +
>> + Contains 0xAA55. This is the closest thing old Linux kernels have
>> + to a magic number.
>>
>
> Endianess? I guess a
Jörn Engel wrote:
> > Almost all your static functions start with logfs_, why not this one?
>
> Because after a while I discovered how silly it is to start every
> function with logfs_. That prefix doesn't add much unless the function
> has global scope. What I didn't do was remove the prefix
H. Peter Anvin wrote:
> +Field name: boot_flag
> +Type:read
> +Offset/size: 0x1fe/2
> +Protocol:ALL
> +
> + Contains 0xAA55. This is the closest thing old Linux kernels have
> + to a magic number.
>
Endianess? I guess a blanket statement saying that all constants are
on x86_64 kernel, level triggered irq migration gets initiated in the context
of that interrupt(after executing the irq handler) and following steps are
followed to do the irq migration.
1. mask IOAPIC RTE entry; // write to IOAPIC RTE
2. EOI; // processor EOI write
3.
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
The MCE handler already has an idle-task handler which checks for the
TIF_MCE_NOTIFY flag. Given that the system is idle at that point, we can
get even better granularity of MCE logging by polling for MCEs whenever
we enter the idle loop.
Tobias, did you test this patch and did it solve your problem?
Philip Langdale wrote:
> There is apparently at least one instance of the Ricoh SDHCI
> implementation out there where card insertion (and possibly
> removal) interrupts do not work - so the only way to detect
> a change in the
Fix confirmed, filled the whole 11T hard disk, without crashing.
I presume this would go into 2.6.22
Thanks again.
Jeff
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Zheng
> Sent: Thursday, 17 May 2007 5:39 p.m.
> To: Neil Brown; [EMAIL
A number of items in the i386 boot documentation have been either
vague, outdated or hard to read. This text revision adds several more
examples, including a memory map for a modern kernel load. It also
adds a field-by-field detailed description of the setup header, and a
bootloader ID for Qemu.
On Thursday 17 May 2007 04:40:24 David Chinner wrote:
> On Wed, May 16, 2007 at 11:31:16PM +0200, Jesper Juhl wrote:
> > Hi,
> >
> > The Coverity checker found a memory leak in xfs_inactive().
>
> > So, the code allocates a transaction, but in the case where 'truncate' is
> > !=0 and
On Thursday, May 17, 2007 3:37 pm Jesse Barnes wrote:
> This patch adds the core of the new DRM based modesetting system. It
> creates several new structures in the DRM, the primary ones being the
> CRTC, which controls all aspects of your device's CRTC(s), output,
> which describes and controls
On Thursday, May 17, 2007 3:40 pm Jesse Barnes wrote:
> This patch adds support for DRM modesetting to the Intel DRM driver
> and stubs out a simple FB driver to sit underneath. The code had to
> be refactored a bit, since current DRM drivers tend to be fully
> initialized by userspace via
On Thursday, May 17, 2007 3:32 pm Jesse Barnes wrote:
> Randy just informed me that the patch limits are bigger now, so here
> are the actual patches.
>
> This patch allows for proper console unregistration via the VT layer,
> and updates the FB layer to use it. This makes debugging new console
>
> Something similar happened to me on XE3, yes.
>
> (Actual values were different; BIOS specified critical temperature at
> cca 95C, but hw killed the power at cca 83C. Setting critical trip
> point at 80C made the problem go away.)
Great, please file a bug and include the acpidump from the XE3
> > No, writing trip-points is neither a fix, nor it is reasonable.
> > It is a workaround at best, and it is a dangerous and mis-leading hack.
> >
> > The OS has no capability to actually change the ACPI trip points
> > that are used by the BIOS. Changing the OS copy of them
> > to make the
Randy just informed me that the patch limits are bigger now, so here are the
actual patches.
This patch allows for proper console unregistration via the VT layer, and
updates the FB layer to use it. This makes debugging new console drivers
much easier, since you can properly clean them up before
Simon Arlott wrote:
> On 17/05/07 21:15, H. Peter Anvin wrote:
>> Simon Arlott wrote:
>>> Is it automatic? I have CONFIG_X86_CMPXCHG=y without cx8 showing in
>>> cpuinfo, and it appears to work fine.
>>>
>>> Will your changes needlessly prevent the kernel running? Would I be
>>> right in thinking
On Thu, 17 May 2007, Peter Zijlstra wrote:
> The way I read the cpuset page allocator, it will only respect the
> cpuset if there is memory aplenty. Otherwise it will grab whatever. So
> still, it will only ever use ALLOC_NO_WATERMARKS if the whole system is
> in distress.
Sorry no. The purpose
From: Philipp Kohlbecher <[EMAIL PROTECTED]>
The kernel_execve function issues a software interrupt (int 0x80) to make
a system call to sys_execve. This function expects to find the stack segment
and stack pointer of the function that issued the system call in the pt_regs
struct. The syscall
> This is the original ARM dyntick stuff, right ?
Yes this is a version is not using clocksource.
> The dyntick support on your architecture is broken. Why does it fiddle
> with the timer, when the system is not idle ?
I can't yet run the test sequence on the latest kernel so I'll have to
wait
Matthew Wilcox wrote:
On Tue, May 15, 2007 at 12:26:29PM +0100, Simon Arlott wrote:
I've already suggested a sysfs attribute - or something equivalent - would
be much better. It's just one function that a user might want to run multiple
times (e.g. after adding scsi devices?) - why should
On Thu, 17 May 2007 16:33:12 -0500
"MIke Miller (OS Dev)" <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-05-14 at 17:53 +, Gerald Britton wrote:
> > Fix an Oops in the cciss driver caused by system shutdown while a filesystem
> > on a cciss device is still active. The cciss_remove_one function
Philipp Kohlbecher wrote:
> From: Philipp Kohlbecher <[EMAIL PROTECTED]>
>
> The kernel_execve function issues a software interrupt (int 0x80) to make
> a system call to sys_execve. This function expects to find the stack segment
> and stack pointer of the function that issued the system call in
On 17/05/07 21:15, H. Peter Anvin wrote:
Simon Arlott wrote:
Is it automatic? I have CONFIG_X86_CMPXCHG=y without cx8 showing in
cpuinfo, and it appears to work fine.
Will your changes needlessly prevent the kernel running? Would I be
right in thinking that the kernel is successfully using
Dave Jones wrote:
On Thu, May 17, 2007 at 05:40:31PM -0400, Ed Sweetman wrote:
> Here's a patch
(please inline patches so they can be quoted in replies).
having this as a tristate makes no sense, that code can't be modular.
Also, there's a gratuitous whitespace change, and the default should
On Thu, May 17, 2007 at 10:20:10PM +0200, CIJOML wrote:
> Hi,
>
> with kernel 2.6.20 and 2.6.21 I have problem with my good old router
> Dell Dual P2 333MHz.
>
> Module 8250 getts loaded, but UPS driver is unable talk to UPS:
>
> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
1 - 100 of 890 matches
Mail list logo
