On Wed, Sep 12, 2007 at 01:24:13PM +0800, WANG Cong wrote:
> On Tue, Sep 11, 2007 at 08:29:26PM +0200, Adrian Bunk wrote:
> >On Tue, Sep 11, 2007 at 10:16:44AM -0700, Randy Dunlap wrote:
> >>...
> >> +~~
> >> +Mutt (TUI)
> >> +
> >> +Plenty of Linux
On Tue, Sep 11 2007, Bartlomiej Zolnierkiewicz wrote:
> On Sunday 09 September 2007, Adrian Bunk wrote:
> > On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
> > >...
> > > Changes since 2.6.23-rc3-mm1:
> > >...
> > > git-block.patch
> > >...
> > > git trees
> > >...
> >
> >
The following code seems to me to be a valid example of a binary semaphore
(mutex) in a timer:
//timer called 10 times a second
static void status_timer(unsigned long device)
{
struct etp_device_private *dp = (struct etp_device_private *)device;
if (unlikely(dp->status_interface == 0))
On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> I have developed a device driver and use the sysFS to export some
> registers to userspace.
Uuuh, uggly. Don't do that. Device drivers are there to abstract things,
not to play around with registers from userspace.
> I opened the
On Tue, Sep 11, 2007 at 08:29:26PM +0200, Adrian Bunk wrote:
>On Tue, Sep 11, 2007 at 10:16:44AM -0700, Randy Dunlap wrote:
>>...
>> +~~
>> +Mutt (TUI)
>> +
>> +Plenty of Linux developers use mutt, so it must work pretty well.
>> +
>> +Are there any
Hi Alan,
To be specific I want to call the function 0x60 ,0x61 and few more
specified in the BBS specification (attached). These functions or alive
in 16 bit mode (0xf000 segment)
We can call this functions in i386 using the pnpbios driver
(bioscalls.c). I must call this functions to change
Hi,
I would like to use the Real time signalling mechanism. When I try to
use "F_SETAUXFL", compilation fails. While looking through the
archives I found a patch one-sig-perfd-2.4.4.patch.gz at
http://www.uwsg.iu.edu/hypermail/linux/kernel/0105.2/0642.html which
needs to be applied for the
Michael Neuling wrote:
> The "tty: termios locking functions break with new termios type" patch
> (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
> This adds the required API to asm-powerpc.
>
> Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
> --
> This needs to go up
On Tue, Sep 11, 2007 at 08:52:14PM +0200, Peter Zijlstra wrote:
>
>On Tue, 2007-09-11 at 14:38 -0400, Lee Revell wrote:
>> On 9/11/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>> > On Tue, 2007-09-11 at 10:16 -0700, Randy Dunlap wrote:
>> >
>> > >
Hi Linus,
Please consider pulling from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
or
master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus
to receive updates for input subsystem.
Changelog:
--
Elvis Pranskevichus (1):
Le mardi 11 septembre 2007 à 23:30 +0200, Francois Romieu a écrit :
> Xavier Bestel <[EMAIL PROTECTED]> :
> [...]
> > with the r8169 I can't send a magic packet anymore. I'm using ethtool
> > for that, with the previous one (an rtl8139b) it was working very well.
> > ethtool -D apparently says it
This patch removes this unneeded mutex. Indeed it was used
to serialized access to the hardware, but this is already
done by the i2c-core layer, see 'bus_lock' mutex used by
i2c_transfer().
Signed-off-by: Francis Moreau <[EMAIL PROTECTED]>
Acked-by: Bryan Wu <[EMAIL PROTECTED]>
Acked-by: Sonic
On Sat, 1 Sep 2007 07:55:36 +0200 Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
> Hello,
>
> This patch fixes the unbalanced parenthesis inroduced by
> add-a-rounddown_pow_of_two-routine-to-log2h.patch.
>
> Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
>
> include/linux/log2.h |
From: Randy Dunlap <[EMAIL PROTECTED]>
Requested by Jeff Garzik.
v2, updated from lkml comments.
Add info about various email clients and their applicability
in being used to send Linux kernel patches.
Some notes takes from http://mbligh.org/linuxdocs/Email/Clients
Portions used with
On Tue, 11 Sep 2007 19:36:42 +0200 Peter Zijlstra wrote:
> On Tue, 2007-09-11 at 10:16 -0700, Randy Dunlap wrote:
>
> > +~~
> > +Evolutions (GUI)
>
> I take it you mean: Evolution
Yep, lousy keyboard. ;)
I've updated the text file and will
Ed Swierk <[EMAIL PROTECTED]> wrote:
>
> The patch caps the MTU somewhat arbitrarily at 16000 bytes. This is
> slightly lower than the value used by the e1000 driver, so it seems
> like a safe upper limit.
Please make it 65535 without an Ethernet header and 65521
with an Ethernet header.
Jeff Garzik wrote:
Chris Friesen wrote:
Can someone describe the problems with just attaching the patch in
Thunderbird? It's what Martin says he does on the linked document...
Email clients don't like to quote attachments, even text/plain ones,
which then makes attached patches much more
On Wed, 15 Aug 2007 17:52:28 +0400 Dmitry Monakhov <[EMAIL PROTECTED]> wrote:
> Currently block device size calculated regardless its
> bd_block_size. This may result attempt to write outside
> block device if i_size not aligned to bdev->bd_block_size
> and result in EIO.
>
>
On Fri, 17 Aug 2007 13:28:38 +0800 "Huang, Ying" <[EMAIL PROTECTED]> wrote:
> This patch fixes a bug of change_page_attr/change_page_attr_addr on
> Intel x86_64 CPU. After changing page attribute to be executable with
> these functions, the page remains un-executable on Intel x86_64
> CPU.
On Fri, 17 Aug 2007 00:08:58 +0200 Jesper Juhl <[EMAIL PROTECTED]> wrote:
>
> Fix this tiny compiler warning in Moxa driver :
> drivers/char/mxser.c:386: warning: 'mxser_get_PCI_conf' declared 'static'
> but never defined
> when building without CONFIG_PCI.
>
>
> Signed-off-by: Jesper Juhl
On Wed, 2007-09-12 at 12:05 +1000, David Gibson wrote:
> On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > Hello,
> >
> > I have developed a device driver and use the sysFS to export some
> > registers to userspace. I opened the sysFS File for one register and did
> > some reads
Peter> Scale writeback cache per backing device, proportional to its
Peter> writeout speed. By decoupling the BDI dirty thresholds a
Peter> number of problems we currently have will go away, namely:
Ah, this clarifies my questions! Thanks!
Peter> - mutual interference starvation (for any
On Tue, Sep 11, 2007 at 07:17:42PM -0700, Linus Torvalds wrote:
> Really?
>
> It shouldn't. The use of kernel_termios_to_user_termios_1() is conditional
> on the architecture having a define for TCGETS2, and I think they match
> up. I see:
>
> [EMAIL PROTECTED] linux]$ git grep -l
> On Wed, 12 Sep 2007, Michael Neuling wrote:
> >
> > The "tty: termios locking functions break with new termios type" patch
> > (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
>
> Really?
>
> It shouldn't. The use of kernel_termios_to_user_termios_1() is conditional
> on
Peter> Per device dirty throttling patches These patches aim to
Peter> improve balance_dirty_pages() and directly address three
Peter> issues:
Peter> 1) inter device starvation
Peter> 2) stacked device deadlocks
Peter> 3) inter process starvation
Peter> 1 and 2 are a direct result from
On Wed, 12 Sep 2007, Michael Neuling wrote:
>
> The "tty: termios locking functions break with new termios type" patch
> (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
Really?
It shouldn't. The use of kernel_termios_to_user_termios_1() is conditional
on the
SSB uses a bool (SSB_PCMCIAHOST_POSSIBLE) to determine whether to
build in PCMCIA support or not, as the PCMCIA host code itself is
also only a bool, make SSB_PCMCIAHOST_POSSIBLE depend on PCMCIA=y.
Without this, SSB_PCMCIAHOST_POSSIBLE evaluates to y when PCMCIA
is built as a module, which
"Josef 'Jeff' Sipek":
> So, if I understand correctly, you create the entire block as if you were
> going to write to disk? Unionfs keeps the data in a linked list.
Basically yes.
But the dir block in cache has no hole which is contiguous memory.
Junjiro Okajima
-
To unsubscribe from this
There's nothing that is problematic for file_fsync() with CONFIG_BLOCK=n,
and it's built in unconditionally anyways, so move the prototype out to
reflect that. Without this, the unionfs build bails out.
CC fs/unionfs/file.o
fs/unionfs/file.c:148: error: 'file_fsync' undeclared here (not in
The "tty: termios locking functions break with new termios type" patch
(f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
This adds the required API to asm-powerpc.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
--
This needs to go up for 2.6.23.
Should we really put
On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> Hello,
>
> I have developed a device driver and use the sysFS to export some
> registers to userspace. I opened the sysFS File for one register and did
> some reads from this File, but I alwas becoming the same value from the
>
Convert cpu_sibling_map to a per_cpu cpumask_t array for the ia64
architecture. This fixes build errors in block/blktrace.c and
kernel/sched.c when CONFIG_SCHED_SMT is defined.
There was one access to cpu_sibling_map before the per_cpu data
area was created, so that step was moved to after the
Convert cpu_sibling_map to a per_cpu cpumask_t array for the ppc64
architecture. This fixes build errors in block/blktrace.c and
kernel/sched.c when CONFIG_SCHED_SMT is defined.
Note: these changes have not been built nor tested.
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
This is from an earlier message from Christoph Lameter:
processor_core.c currently tries to determine the apicid by special casing
for IA64 and x86. The desired information is readily available via
cpu_physical_id()
on IA64, i386 and x86_64.
Signed-off-by: Christoph
Convert cpu_sibling_map to a per_cpu cpumask_t array for the sparc64
architecture. This fixes build errors in block/blktrace.c and
kernel/sched.c when CONFIG_SCHED_SMT is defined.
Note: these changes have not been built nor tested.
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
Convert cpu_sibling_map from a static array sized by NR_CPUS to a
per_cpu variable. This saves sizeof(cpumask_t) * NR unused cpus.
Access is mostly from startup and CPU HOTPLUG functions.
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c |2 -
This patch converts the x86_cpu_to_apicid array to be a per
cpu variable. This saves sizeof(apicid) * NR unused cpus.
Access is mostly from startup and CPU HOTPLUG functions.
MP_processor_info() is one of the functions that require access
to the x86_cpu_to_apicid array before the per_cpu data
Convert cpu_llc_id from a static array sized by NR_CPUS to a
per_cpu variable. This saves sizeof(cpu_llc_id) * NR unused
cpus. Access is mostly from startup and CPU HOTPLUG functions.
Note there's an addtional change of the type of cpu_llc_id
from int to u8 for ARCH i386 to correspond with the
Fix four instances where cpu_to_node is referenced
by array instead of via the cpu_to_node macro. This
is preparation to moving it to the per_cpu data area.
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/vsyscall.c |2 +-
arch/x86_64/mm/numa.c |4 ++--
This is from an earlier message from 'Christoph Lameter':
cpu_core_map is currently an array defined using NR_CPUS. This means that
we overallocate since we will rarely really use maximum configured cpu.
If we put the cpu_core_map into the per cpu area then it will be allocated
Note:
This patch consolidates all the previous patches regarding
the conversion of static arrays sized by NR_CPUS into per_cpu
data arrays and is referenced against 2.6.23-rc6 .
v1 Intro:
In x86_64 and i386 architectures most arrays that are sized
using NR_CPUS lay in local memory on node 0.
This is a copy of an older patch that is in rc3-mm1. It's needed
to allow the remaining patches to integrate correctly.
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/genapic.c |2 --
arch/x86_64/kernel/genapic_flat.c |1 -
arch/x86_64/kernel/smpboot.c |
On Tue, Sep 11, 2007 at 04:00:17PM +1000, Nick Piggin wrote:
> > > OTOH, I'm not sure how much buy-in there was from the filesystems guys.
> > > Particularly Christoph H and XFS (which is strange because they already
> > > do vmapping in places).
> >
> > I think they use vmapping because they have
Per cpuset dirty ratios
This implements dirty ratios per cpuset. Two new files are added
to the cpuset directories:
background_dirty_ratio Percentage at which background writeback starts
throttle_dirty_ratioPercentage at which the application is throttled
and we
Throttle VM writeout in a cpuset aware way
This bases the vm throttling from the reclaim path on the dirty ratio
of the cpuset. Note that a cpuset is only effective if shrink_zone is called
from direct reclaim.
kswapd has a cpuset context that includes the whole machine. VM throttling
will only
Make page writeback obey cpuset constraints
Currently dirty throttling does not work properly in a cpuset.
If f.e a cpuset contains only 1/10th of available memory then all of the
memory of a cpuset can be dirtied without any writes being triggered.
If all of the cpusets memory is dirty then
Direct reclaim: cpuset aware writeout
During direct reclaim we traverse down a zonelist and are carefully
checking each zone if its a member of the active cpuset. But then we call
pdflush without enforcing the same restrictions. In a larger system this
may have the effect of a massive amount of
pdflush: Allow the passing of a nodemask parameter
If we want to support nodeset specific writeout then we need a way
to communicate the set of nodes that an operation should affect.
So add a nodemask_t parameter to the pdflush functions and also
store the nodemask in the pdflush control
Add a dirty map to struct address_space
In a NUMA system it is helpful to know where the dirty pages of a mapping
are located. That way we will be able to implement writeout for applications
that are constrained to a portion of the memory of the system as required by
cpusets.
This patch
Perform writeback and dirty throttling with awareness of cpuset mem_allowed.
The theory of operation has two primary elements:
1. Add a nodemask per mapping which indicates the nodes
which have set PageDirty on any page of the mappings.
2. Add a nodemask argument to wakeup_pdflush() which is
On Wed, Sep 12, 2007 at 05:48:52AM +1000, Paul Mackerras wrote:
> Keshavamurthy, Anil S writes:
>
> > Subject: Fix IOMMU early crash
> >
> > This patch avoids copying pci_bus's->sysdata to
> > pci_dev's->sysdata as one can easily obtain
> > the same through pci_dev->bus->sysdata.
>
> At the
Hi Ingo,
When compiling, I get:
In file included from kernel/sched.c:794:
kernel/sched_fair.c: In function 'task_new_fair':
kernel/sched_fair.c:857: error: 'sysctl_sched_child_runs_first'
undeclared (first use in this function)
kernel/sched_fair.c:857: error: (Each undeclared identifier is
On Tue, Sep 11, 2007 at 09:23:35AM -0400, Mark M. Hoffman wrote:
> I am not an IPMI expert, so I would appreciate getting an Acked-by from
> someone who knows more about that subsystem.
>
> Anyway, some comments are below. This is nowhere near a complete review yet.
Thank you for the review!
On Wed, Sep 12, 2007 at 01:09:59AM +0200, Michal Januszewski wrote:
> The VGA registers are only available at their legacy IO locations on x86.
> Don't try to access them when running on other arches.
>
> Note that the code accessing them directly is just an optimization (limits
> slow BIOS
Hi,
Hi,
Out of curiousity: will I ever get answers to my questions?
bye, Roman
-
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 Tue, Sep 11, 2007 at 10:34:23PM +0100, Andi Kleen wrote:
> > People do not expect code under arch/i386/ to be used by code under
> > arch/x86_64/ and vice versa.
> >
> > That regularly results in people sending patches that don't compile on
> > the other architecture.
> >
> > With one
On Wed, 12 Sep 2007, Andrea Arcangeli wrote:
> On Tue, Sep 11, 2007 at 01:41:08PM -0700, Christoph Lameter wrote:
> > The advantages of this approach over Andreas is basically that the 4k
> > filesystems still can be used as is. 4k is useful for binaries and for
>
> If you mean that with my
On 12/09/2007, Björn Steinbrink <[EMAIL PROTECTED]> wrote:
>
> A fix would likely initialize "when" to jiffies.
>
> Björn
>
Thanks, I'll try that :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tue, 11 Sep 2007, Nick Piggin wrote:
> > Well its seems that we have different interpretations of what was agreed
> > on. My understanding was that the large blocksize patchset was okay
> > provided that I supply an acceptable mmap implementation and put a
> > warning in.
>
> Yes. I think we
[EMAIL PROTECTED] wrote:
The patch titled
git-net-broke-ixgbe
has been added to the -mm tree. Its filename is
git-net-broke-ixgbe.patch
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to
On 2007.09.12 00:10:19 +0100, Adrian McMenamin wrote:
> On 12/09/2007, Björn Steinbrink <[EMAIL PROTECTED]> wrote:
> > On 2007.09.12 00:19:09 +0200, Rene Herman wrote:
> > > On 09/12/2007 12:15 AM, Adrian McMenamin wrote:
> > >
> > >> On 11/09/2007, Rene Herman <[EMAIL PROTECTED]> wrote:
> > >>>
Bartlomiej Zolnierkiewicz wrote:
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/bart/ide-2.6.git/
to receive the following updates:
drivers/ata/pata_ali.c |7 ++
drivers/ide/Kconfig|4 +-
drivers/ide/ide-iops.c |3 +-
Most of the load in my system is triggered by a single ethernet IRQ.
Essentially the IRQ schedules a tasklet and most of the work is done in the
taskelet which is scheduled in the IRQ. From what I read looks like the tasklet
would be executed on the same CPU on which it was scheduled. So this
On Tue, Sep 11, 2007 at 01:41:08PM -0700, Christoph Lameter wrote:
> The advantages of this approach over Andreas is basically that the 4k
> filesystems still can be used as is. 4k is useful for binaries and for
If you mean that with my approach you can't use a 4k filesystem as is,
that's not
On 09/12/2007 01:09 AM, Björn Steinbrink wrote:
On 2007.09.12 00:19:09 +0200, Rene Herman wrote:
On 09/12/2007 12:15 AM, Adrian McMenamin wrote:
On 11/09/2007, Rene Herman <[EMAIL PROTECTED]> wrote:
On 09/12/2007 12:05 AM, Adrian McMenamin wrote:
OK, why does this line occasionally return
The VGA registers are only available at their legacy IO locations on x86.
Don't try to access them when running on other arches.
Note that the code accessing them directly is just an optimization (limits
slow BIOS function calls). We don't lose any functionality by using
BIOS calls instead of it
On 12/09/2007, Björn Steinbrink <[EMAIL PROTECTED]> wrote:
> On 2007.09.12 00:19:09 +0200, Rene Herman wrote:
> > On 09/12/2007 12:15 AM, Adrian McMenamin wrote:
> >
> >> On 11/09/2007, Rene Herman <[EMAIL PROTECTED]> wrote:
> >>> On 09/12/2007 12:05 AM, Adrian McMenamin wrote:
> >>>
> OK,
On 2007.09.12 00:19:09 +0200, Rene Herman wrote:
> On 09/12/2007 12:15 AM, Adrian McMenamin wrote:
>
>> On 11/09/2007, Rene Herman <[EMAIL PROTECTED]> wrote:
>>> On 09/12/2007 12:05 AM, Adrian McMenamin wrote:
>>>
OK, why does this line occasionally return true:
What exactly is
On Tue, Sep 11, 2007 at 09:31:59PM +0900, Paul Mundt wrote:
> > Anyway, I think it is up to Michal to decide if we should remove the
> > kernel support for other archs, or let it stay a bit more while working
> > on solving the v86d side of things. So I'll just step aside now
> >
> Once
eCryptfs is currently just passing through splice reads to the lower
filesystem. This is obviously incorrect behavior; the decrypted data
is what needs to be read, not the lower encrypted data. I cannot think
of any good reason for eCryptfs to implement splice_read, so this
patch points the
On Sun, 09 Sep 2007 13:35:26 +0200
Patrizio Bassi <[EMAIL PROTECTED]> wrote:
> Patrizio Bassi ha scritto:
> > Jan Engelhardt ha scritto:
> >> On Sep 8 2007 11:38, Patrizio Bassi wrote:
> >>
> >>> Jan Engelhardt wrote:
> >>>
> I shall give this a spin too, since I happen to have
Patch below fixes the problem we were seeing (negative delta calculated
in tick_do_update_jiffies64).
Thanks again Thomas!
On Wed, Sep 12, 2007 at 12:36:34AM +0200, Thomas Gleixner wrote:
> Timekeeping resume adjusts xtime by adding the slept time in seconds and
> resets the reference value of
On Tue, Sep 11, 2007 at 05:03:57PM +0200, Adrian Bunk wrote:
> On Tue, Sep 11, 2007 at 10:29:47AM -0400, Bill Davidsen wrote:
> > So if you want people to try a new driver, I think it really has to have
> > some benefits to the users, in terms of performance, reliability, or
> > features.
Timekeeping resume adjusts xtime by adding the slept time in seconds and
resets the reference value of the clock source (clock->cycle_last).
clock->cycle last is used to calculate the delta between the last xtime
update and the readout of the clock source in __get_nsec_offset(). xtime
plus the
This includes a small doc update, which I missed earlier. It doesn't change
any code. The other three patches are real fixes.
--Mark
Please pull from 'upstream-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2.git upstream-linus
to receive the following
--- Stephen Hemminger
<[EMAIL PROTECTED]> wrote:
> On Sun, 9 Sep 2007 13:13:26 +0200
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > On Sat, Sep 08, 2007 at 10:42:20PM -0400, Kyle
> Rose wrote:
> > >
> > > > You are a regular reader of linux-kernel, and
> therefore the sk98lin
> > > > removal
On 09/12/2007 12:15 AM, Adrian McMenamin wrote:
On 11/09/2007, Rene Herman <[EMAIL PROTECTED]> wrote:
On 09/12/2007 12:05 AM, Adrian McMenamin wrote:
OK, why does this line occasionally return true:
if ((maple_dev->interval > 0) && (jiffies >maple_dev->when))
while this one never
On 11/09/2007, Rene Herman <[EMAIL PROTECTED]> wrote:
> On 09/12/2007 12:05 AM, Adrian McMenamin wrote:
>
> > OK, why does this line occasionally return true:
> >
> > if ((maple_dev->interval > 0) && (jiffies >maple_dev->when))
> >
> > while this one never does (no other changes made):
> >
>
On 09/12/2007 12:05 AM, Adrian McMenamin wrote:
OK, why does this line occasionally return true:
if ((maple_dev->interval > 0) && (jiffies >maple_dev->when))
while this one never does (no other changes made):
if ((maple_dev->interval > 0) && (time_after(jiffies, maple_dev->when)))
I have an Asus Striker Extreme motherboard with two built in MCP55 GigE
interfaces. When I build with the original Fedora 7 release kernel (
ftp://ftp.belnet.be/linux/fedora/linux/releases/7/Fedora/i386/os/Fedora/kernel-2.6.21-1.3194.fc7.i686.rpm
) everything works fine. However, when I boot
On Tue, Sep 11, 2007 at 14:38:13 -0400, Lee Revell wrote:
> You can also diff -Nru old.c new.c | xclip, select Preformat, then
> paste with the middle button.
mutt does not come with text editor, so
I'd like to add note about vim:
If using xclip, type command
:set paste
before middle button or
OK, why does this line occasionally return true:
if ((maple_dev->interval > 0) && (jiffies >maple_dev->when))
while this one never does (no other changes made):
if ((maple_dev->interval > 0) && (time_after(jiffies, maple_dev->when)))
Is this a gcc issue or what?
-
To unsubscribe from
On Wednesday 12 September 2007 07:48, Christoph Lameter wrote:
> On Tue, 11 Sep 2007, Nick Piggin wrote:
> > But that's not my place to say, and I'm actually not arguing that high
> > order pagecache does not have uses (especially as a practical,
> > shorter-term solution which is unintrusive to
On (11/09/07 14:48), Christoph Lameter didst pronounce:
> On Tue, 11 Sep 2007, Nick Piggin wrote:
>
> > But that's not my place to say, and I'm actually not arguing that high
> > order pagecache does not have uses (especially as a practical,
> > shorter-term solution which is unintrusive to
On Saturday 01 September 2007, Jeff Garzik wrote:
>
> commit 457b6eb3bf3341d2e143518a0bb99ffbb8d754c4
> Author: Jeff Garzik <[EMAIL PROTECTED]>
> Date: Sat Sep 1 10:16:45 2007 -0400
>
> drivers/firmware: const-ify DMI API and internals
>
> Three main sets of changes:
>
>
On Tue, 11 Sep 2007, Nick Piggin wrote:
> > No you have not explained why the theoretical issues continue to exist
> > given even just considering Lumpy Reclaim in .23 nor what effect the
> > antifrag patchset would have.
>
> So how does lumpy reclaim, your slab patches, or anti-frag have
> much
On Tue, 11 Sep 2007, Andi Kleen wrote:
>
> Will that cause people to compile test both? I have my doubts that
> will really work.
If people don't compile-test both now, then why would they compile-test
things when merged?
So no, that's not the point.
But at least things like "grep" will
On Tue, 2007-09-11 at 17:48 +0900, Yoichi Yuasa wrote:
> This patch has added #include to include/linux/leds.h for
> rwlock_t.
>
> Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
Added to the leds tree[1], thanks.
http://git.o-hand.com/?p=linux-rpurdie-leds;a=shortlog;h=for-mm
Richard
-
To
On Tue, Sep 11, 2007 at 10:34:23PM +0100, Andi Kleen wrote:
>
> >
> > People do not expect code under arch/i386/ to be used by code under
> > arch/x86_64/ and vice versa.
> >
> > That regularly results in people sending patches that don't compile on
> > the other architecture.
> >
> > With one
On Tue, 11 Sep 2007, Nick Piggin wrote:
> But that's not my place to say, and I'm actually not arguing that high
> order pagecache does not have uses (especially as a practical,
> shorter-term solution which is unintrusive to filesystems).
>
> So no, I don't think I'm really going against the
On Tue, 2007-09-11 at 21:52 +0200, Thomas Gleixner wrote:
> > C1: type[C1] promotion[C2] demotion[--] latency[001]
> > usage[0010] duration[]
> >*C2: type[C2] promotion[--] demotion[C1] latency[001]
> > usage[8316]
On Wednesday 12 September 2007 07:41, Christoph Lameter wrote:
> On Tue, 11 Sep 2007, Nick Piggin wrote:
> > I think I would have as good a shot as any to write a fragmentation
> > exploit, yes. I think I've given you enough info to do the same, so I'd
> > like to hear a reason why it is not a
On Tue, 2007-09-11 at 21:07 +0100, Denys Vlasenko wrote:
> This patch is needed for --gc-sections to work, regardless
> of which final form that support will have.
>
> This patch renames .text.xxx and .data.xxx sections
> into .xxx.text and .xxx.data, respectively.
I think you'll have better
On Wed, Sep 12, 2007 at 05:48:52AM +1000, Paul Mackerras wrote:
> Keshavamurthy, Anil S writes:
>
> > Subject: Fix IOMMU early crash
> >
> > This patch avoids copying pci_bus's->sysdata to
> > pci_dev's->sysdata as one can easily obtain
> > the same through pci_dev->bus->sysdata.
>
> At the
On Tue, 11 Sep 2007, Nick Piggin wrote:
> I think I would have as good a shot as any to write a fragmentation
> exploit, yes. I think I've given you enough info to do the same, so I'd
> like to hear a reason why it is not a problem.
No you have not explained why the theoretical issues continue
On Wednesday 12 September 2007 06:53, Mel Gorman wrote:
> On (11/09/07 11:44), Nick Piggin didst pronounce:
> However, this discussion belongs more with the non-existant-remove-slab
> patch. Based on what we've seen since the summits, we need a thorough
> analysis with benchmarks before making a
On Saturday 08 September 2007, Sergei Shtylyov wrote:
> Hello, I wrote:
> Sergei Shtylyov wrote:
>
> >The patch was 4/4 of course. :-<
> > Probably I was too esctatic about the code. ;-)
>
> Or rarher me. :-)
>
> >> The Marvell bridge chips used on HighPoint SATA cards do not seem
On Sunday 09 September 2007, Adrian Bunk wrote:
> On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.23-rc3-mm1:
> >...
> > git-block.patch
> >...
> > git trees
> >...
>
> ide_get_error_location() is no longer used.
>
> Signed-off-by: Adrian Bunk
Hi,
On Saturday 08 September 2007, Sergei Shtylyov wrote:
> Once I quothed:
>
> > Make ide_rate_filter() also respect PIO/SWDMA/MWDMA mode masks. While at
> > it,
> > make the udma_filter() method calls take precedence over using the mode
> > masks.
>
> This one not looking to pretty --
>
> People do not expect code under arch/i386/ to be used by code under
> arch/x86_64/ and vice versa.
>
> That regularly results in people sending patches that don't compile on
> the other architecture.
>
> With one architecture it's much more obvious that the code is shared.
Will that cause
1 - 100 of 1058 matches
Mail list logo
