applied
-
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 http://www.tux.org/lkml/
applied
-
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 http://www.tux.org/lkml/
Grant Grundler writes:
> Ok this is good example - I see what the problem is.
> You could use the following sequence too then:
> pci_block_user_cfg_access
> pci_save_state
> block_ucfg_access = 1
> mb()
> while (spin_is_locked(_lock))
On Wednesday 07 September 2005 00:16, Daniel Phillips wrote:
> ...as long as ->task and ->previous_esp are initialized,
> staying on the bigger stack looks fine (previous_esp is apparently used
> only for backtrace) ... just like do_IRQ.
Ahem, but let me note before somebody else does: it isn't
/ 2005-09-07 01:03:00 -0400
\ Lee Revell:
> On Wed, 2005-09-07 at 00:45 -0400, Maurice Volaski wrote:
> > >What is drbd? An out of tree driver? Did it work with 2.6.13-rcX? If
> >
> > Yes, it implements RAID 1 across two computers over a network link in
> > realtime. Generally, you combine
Please pull from 'upstream' branch of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git
to obtain the following DocBook change:
Documentation/DocBook/mcabook.tmpl |2 +-
drivers/net/wan/syncppp.c |1 +
drivers/scsi/libata-core.c |4 ++--
On Wed, 2005-09-07 at 00:45 -0400, Maurice Volaski wrote:
> >What is drbd? An out of tree driver? Did it work with 2.6.13-rcX? If
>
> Yes, it implements RAID 1 across two computers over a network link in
> realtime. Generally, you combine with a program called heartbeat to
> implement
[just sent this to Andrew/Linus]
Please pull from 'upstream' branch of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to obtain the various updates described below:
drivers/net/Kconfig |7
drivers/net/Makefile |2
What is drbd? An out of tree driver? Did it work with 2.6.13-rcX? If
Yes, it implements RAID 1 across two computers over a network link in
realtime. Generally, you combine with a program called heartbeat to
implement high-availabilty failover. It's very neat ;-)
not, why didn't they
On Tue, 2005-09-06 at 21:35 -0400, John Richard Moser wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Are there any recent kernel profiles? I think from an acedemic
> perspective it'd be nice to see some graphs and numbers nobody
> understands showing where the longest running code
Kalin KOZHUHAROV thinrope.net> writes:
>
> A closer examination of the drive:
> (Model=ST3300831AS, FwRev=3.03, SerialNo=3NF07KA1 )
> and why is it so slow revealed that it was running not in UDMA.
>
> Got one total oops, even no logs were written to disk.
> Seems that rsync-ing huge
On Tuesday 06 September 2005 21:59, Mark Lord wrote:
> Daniel Phillips wrote:
> > There are only two stacks involved, the normal kernel stack and your new
> > ndis stack. You save ESP of the kernel stack at the base of the ndis
> > stack. When the Windows code calls your api, you get the ndis
On Tue, 2005-09-06 at 21:59 -0400, Mark Lord wrote:
> Daniel Phillips wrote:
> > There are only two stacks involved, the normal kernel stack and your new
> > ndis
> > stack. You save ESP of the kernel stack at the base of the ndis stack.
> > When
> > the Windows code calls your api, you get
On Tue, 2005-09-06 at 17:13 -0400, Maurice Volaski wrote:
> The kernel module drbd (version 0.7.13) can no longer find its
> devices (e.g., /dev/drbd0, /dev/drbd1) in kernel 2.6.13. The version
> of udev I am using 065/068 didn't make a difference. It works fine
> with kernel 2.6.12.5 and
More comments below.
>>-Original Message-
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED] On Behalf Of Adam Litke
>>Sent: Wednesday, September 07, 2005 5:59 AM
>>To: linux-kernel@vger.kernel.org
>>Cc: ADAM G. LITKE [imap]
>>Subject: Re: [PATCH 2/3 htlb-fault] Demand faulting for
Hi all,
This is regarding an external patch to enable routing over multiple network
connections, but I'm wondering if it's revealing another problem:
Up to 2.6.10 and the corresponding patch here:
(http://www.ssi.bg/~ja/#routes-2.6) allowed me to combine cable and DSL
Internet connections.
Hi Dave,
> This device driver provides the SCSI target side of the "virtual
> SCSI" on IBM Power5 systems. The initiator side has been in mainline
> for a while now (drivers/scsi/ibmvscsi/ibmvscsi.c.) Targets already
> exist for AIX and OS/400.
Good stuff. Got a couple of small suggestions.
- Include saa6588 compiler option and files.
- Fix comment on tuner.h
- linux/utsname.h replaced by linux/version.h to compile on vanilla 2.6.13
linux/drivers/media/video/Kconfig| 12
linux/drivers/media/video/Makefile |2
Andrew,
Sorry for the mess.
Please drop patches 11/24, 12/24 and 14/24. I'm resending patch 23/24
with a small fix.
I'll rework on the bad stuff and submit it maybe tomorrow.
Cheers,
Mauro.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
From: Esben Nielsen <[EMAIL PROTECTED]>
Date: Tue, 6 Sep 2005 20:56:40 +0200 (METDST)
> Andrew and David: I CC'ed you guyes because you took care of it the last
> time :-)
Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
David S. Miller wrote:
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Tue, 06 Sep 2005 21:51:21 -0400
NAK. Rationale: maintainer's choice. Pavel doesn't get to choose
the debugger of choice for the driver maintainer.
If it makes the driver unreadable and thus harder to maintain,
I think
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 07 Sep 2005 01:42:48 +0200
> The only other user of proto_list besides proto_register, which
> doesn't care, are the seqfs functions. They use the slab pointer,
> but in a harmless way:
>
> proto->slab == NULL ? "no" :
Jesper wrote:
> Something like that would be just fine for the
> patches that have been sent on to Linus.
No - not just the patches sent to Linus - that's a burden on Andrew to
separate things out.
Andrew can put the boiler plate statement on _all_ drop messages
> If I just sent the
>>-Original Message-
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED] On Behalf Of Adam Litke
>>Sent: Wednesday, September 07, 2005 5:59 AM
>>To: linux-kernel@vger.kernel.org
>>Cc: ADAM G. LITKE [imap]
>>Subject: Re: [PATCH 2/3 htlb-fault] Demand faulting for hugetlb
>>+retry:
>>+
On Wed, 07 Sep 2005 00:20:11 +0200, Esben Nielsen said:
> Which is too bad. You can do stuff much more elegant, effectively and
> safer in C++ than in C. Yes, you can do inheritance in C, but it leaves
> it up to the user to make sure the type-casts are done OK every time. You
> can with macros
Hello,
attached (as a patch against 2.6.13-git6) is a driver for laptop buttons
on my Fujitsu-Siemens Amilo Pro V2000; it seems quite a few other
laptops use the same interface (with differing sets of buttons).
Thanks,
Mirek
A driver for laptop buttons using an x86 BIOS interface that is
patches 1-4 look OK.
applied patch 1. patch 2 was corrupted, and did not apply. did not
attempt to apply patches 3-4, due to patch 2.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Brett Russ wrote:
Jeff Garzik wrote:
Brett Russ wrote:
2) Isn't it wrong for the IRQ disable at the chip to occur *after*
free_irq() is called to disconnect the handler (independent of
question 1...since this is the case currently)? Granted, all of the
ports have gone through
Daniel Phillips wrote:
There are only two stacks involved, the normal kernel stack and your new ndis
stack. You save ESP of the kernel stack at the base of the ndis stack. When
the Windows code calls your api, you get the ndis ESP, load the kernel ESP
from the base of the ndis stack, push
Francois Romieu wrote:
Miroslaw Mieszczak <[EMAIL PROTECTED]> :
There is a patch to driver of RLT8169 network card. This match make
possible detection of the link status even if network interface is down.
This is usefull for laptop users.
(side note: there is maintainer entry for the r8169
[EMAIL PROTECTED] wrote:
From: Pavel Machek <[EMAIL PROTECTED]>
This removes debug prints from entry/exit of functions. Such level of
debugging should probably be done by gdb or similar.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Cc: "James P.
Hi,
The kconfig from net/wireless says to look at the README.ipw2200 for
further installation of the firmware file. We have that information unde
INSTALL not under README.ipw2200, still I just added a part that talks
about installing the firmware file. This because README.ipw2200 is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Are there any recent kernel profiles? I think from an acedemic
perspective it'd be nice to see some graphs and numbers nobody
understands showing where the longest running code paths in the kernel
occur. It might also be nice for those latency
Pekka Enberg <[EMAIL PROTECTED]> writes:
> This patch removes duplicate directory scanning code from fs/fat/dir.c. The
> two functions that share identical code are fat_readdirx() and
> fat_search_long(). This patch also renames fat_readdirx to __fat_readdir().
Thanks, looks good. However, I
* Makes BFS code endianness-clean.
* Fixes some signedness warnings.
* Fixes a problem in fs/bfs/inode.c:164 where inodes not synced to disk
don't get fully marked as clean. Here's how to reproduce it:
# mount -o loop -t bfs /bfs.img /mnt
# df -i /mnt
FilesystemInodes IUsed
On Tuesday 06 September 2005 22:25, Sam Ravnborg wrote:
> I've already included below patch from you.
> It was included in -linus last night.
That was close.
> Do we really need more?
So it seems I'm afraid: With the version of this patch that just went
in, Jan Beulich <[EMAIL PROTECTED]> found
Am Dienstag, den 06.09.2005, 17:01 -0700 schrieb Andrew Morton:
> Two of these patches:
>
> v4l-adds-the-adapter-number-and-i2c-address-to.patch
> v4l-allows-clearer-message-prefixes-containing-the-i2c-for-tveeprom_hauppauge_analog.patch
>
> throw great reject storms, due to changes in Linus's
On 9/7/05, Paul Jackson <[EMAIL PROTECTED]> wrote:
> Andrew wrote"
> > So then I was asked to include an explanation
> > with the drop message and that all got too hard so I turned them off.
> >
> >
>
>
> Dang it, Andrew. It didn't have to be hard. Just adding a
> boiler plate sentence to all
This should be the entire contents of the SCSI tree I've been saving.
It also includes Jens' send SCSI requests via bios tree that he, Mike
Christie and I have been working on.
The patch is available here:
master.kernel.org:/pub/linux/kernel/scm/jejb/scsi-for-linus-2.6.git
The short changelog
Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> Andrew wrote"
> > So then I was asked to include an explanation
> > with the drop message and that all got too hard so I turned them off.
> >
> >
>
>
> Dang it, Andrew. It didn't have to be hard.
I got three unhappy emails and turned it off
Michael Matz wrote:
As "extern inline" is a GNU extension I don't understand this remark.
Sort of.
C99 has the equivalent construct, but spell it differently:
inline foo(int bar) {
...
}
extern foo(int bar);
There is no "static inline" in C99 either; it's just "inline".
Patch worked like a charm here, no more kernel panics! Excellent work, many
thanks for the quick fix...more people should have such a work ethic.
Cheers,
Matt
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linux-kernel-
> [EMAIL PROTECTED] On Behalf Of Herbert Xu
> Sent: Tuesday,
Andrew wrote"
> So then I was asked to include an explanation
> with the drop message and that all got too hard so I turned them off.
>
>
Dang it, Andrew. It didn't have to be hard. Just adding a
boiler plate sentence to all the drop messages saying something
like:
If I just sent
Two of these patches:
v4l-adds-the-adapter-number-and-i2c-address-to.patch
v4l-allows-clearer-message-prefixes-containing-the-i2c-for-tveeprom_hauppauge_analog.patch
throw great reject storms, due to changes in Linus's current tree. Greg's
i2c stuff.
I'm not confident that the v4l changes
On Tuesday 06 September 2005 18:28, Roland Dreier wrote:
> Daniel> There are only two stacks involved, the normal kernel
> Daniel> stack and your new ndis stack. You save ESP of the kernel
> Daniel> stack at the base of the ndis stack. When the Windows
> Daniel> code calls your
Paul Mackerras wrote:
Mark Bellon writes:
Simply put the existing code has a fixed reservation (claim) address and
once the kernel plus initrd image are large enough to pass this address
all sorts of bad things occur. The fix is the dynamically establish the
first claim address above the
Patch to make ide-host controllers use hwgroup lock where serialization with
hwgroup->lock is necessary
Signed-off-by: Vaibhav V. Nivargi <[EMAIL PROTECTED]>
Signed-off-by: Alok N. Kataria <[EMAIL PROTECTED]>
Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTECTED]>
Index:
David S. Miller wrote:
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 07 Sep 2005 01:02:01 +0200
You're right, good catch. This patch fixes it by moving the lock
down to the list-operation which it is supposed to protect.
I think we need to unlink from the list first if you're
going
Mark Bellon writes:
> Simply put the existing code has a fixed reservation (claim) address and
> once the kernel plus initrd image are large enough to pass this address
> all sorts of bad things occur. The fix is the dynamically establish the
> first claim address above the loaded kernel plus
Patch to convert piix driver to use per-driver/hwgroup lock and kill
ide_lock. In the case of piix, hwgroup->lock should be sufficient.
Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTECTED]>
Index: linux-2.6.13/drivers/ide/pci/piix.c
On Tue, 2005-09-06 at 18:36 -0400, Daniel Phillips wrote:
> But then how would thread_info->task on the irq stack ever get initialized?
>
> My "what for" question was re why interrupt routines even need a valid
> current. I see one answer out there on the web: statistical profiling. Is
> that
Patch to convert ide core code to use hwgroup lock instead of a global
ide_lock.
Signed-off-by: Vaibhav V. Nivargi <[EMAIL PROTECTED]>
Signed-off-by: Alok N. Kataria <[EMAIL PROTECTED]>
Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTECTED]>
Signed-off-by: Shai Fultheim <[EMAIL PROTECTED]>
Following patch moves the hwif tuning code from probe_hwif to ideprobe_init
after ideprobe_init calls hwif_init so that all hwif's have associated
hwgroups. With this patch, we should always have hwgroups for hwifs during
calls the drive tune routines.
Signed-off-by: Alok N Kataria <[EMAIL
The following patchset breaks down the global ide_lock to per-hwgroup lock.
We have taken the following approach.
1. Move the hwif tuning code from probe_hwif to ideprobe_init, after
hwif_init so that hwgroups are present for all the hwifs when the tune
routines for the hwifs are invoked (patch
"John W. Linville" <[EMAIL PROTECTED]> wrote:
>
> On Tue, Sep 06, 2005 at 03:15:46PM -0700, Andrew Morton wrote:
> > "John W. Linville" <[EMAIL PROTECTED]> wrote:
> > >
> > > I fully intend to have have a flag in the private data set based on
> > > the PCI ID when I accumulate some data on which
On Tue, Sep 06, 2005 at 11:10:29PM +0200, Frank van Maarseveen wrote:
> While playing with a new AMD Athlon64 X2 3800+ (i386) the keyboard goes
> wild for 10 (20?) seconds, behaves normally for 10 (20?) seconds, and
> then goes wild again: when "wild", every keypress results in a random
> number
On Tue, Sep 06, 2005 at 01:16:28AM +0200, Andi Kleen wrote:
> On Sat, Sep 03, 2005 at 02:33:30PM -0700, [EMAIL PROTECTED] wrote:
> >
> > From: Ashok Raj <[EMAIL PROTECTED]>
> >
> > Newly introduced physflat_* shares way too much with cluster with only a
> > very
> > differences. So we
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 07 Sep 2005 01:02:01 +0200
> You're right, good catch. This patch fixes it by moving the lock
> down to the list-operation which it is supposed to protect.
I think we need to unlink from the list first if you're
going to do it this way.
On Tue, Sep 06, 2005 at 01:18:08AM +0200, Andi Kleen wrote:
> On Sat, Sep 03, 2005 at 02:33:30PM -0700, [EMAIL PROTECTED] wrote:
> >
> > From: Ashok Raj <[EMAIL PROTECTED]>
> >
> > It is not required to choose the physflat mode when CPU hotplug is enabled
> > and
> > CPUs <=8 case. Use of
Daniele Orlandi wrote:
I'm looking at proto_unregister() in linux-2.6.13:
Il calls kmem_cache_destroy() while holding proto_list_lock:
void proto_unregister(struct proto *prot)
{
write_lock(_list_lock);
if (prot->slab != NULL) {
kmem_cache_destroy(prot->slab);
On 9/6/05, Lee Revell <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-09-06 at 13:39 -0700, Rumen Ivanov Zarev wrote:
> > Trivial patch against 2.6.13 to unhide SMBus on Compaq Evo N620c laptop
> > using
> > Intel 82855PM chipset.
>
> > + } else if (unlikely(dev->subsystem_vendor ==
On Tue, Sep 06, 2005 at 03:15:46PM -0700, Andrew Morton wrote:
> "John W. Linville" <[EMAIL PROTECTED]> wrote:
> >
> > I fully intend to have have a flag in the private data set based on
> > the PCI ID when I accumulate some data on which devices support this
> > and which don't. So far I've
Lee Revell wrote:
On Tue, 2005-09-06 at 13:39 -0700, Rumen Ivanov Zarev wrote:
Trivial patch against 2.6.13 to unhide SMBus on Compaq Evo N620c laptop using
Intel 82855PM chipset.
+ } else if (unlikely(dev->subsystem_vendor == PCI_VENDOR_ID_COMPAQ)) {
Should unlikely() be used for
Hi Andi
On Mon, Sep 05, 2005 at 06:48:21AM +0200, Andi Kleen wrote:
> On Sat, Sep 03, 2005 at 02:33:26PM -0700, [EMAIL PROTECTED] wrote:
> >
> > From: Ashok Raj <[EMAIL PROTECTED]>
> >
> > No need to enforce_max_cpus when hotplug code is enabled. This nukes out
> > cpu_present_map and
In PPC64 there are number of problems in arch/ppc64/boot/main.c that
prevent a kernel from making use of a large (greater than ~16MB) INITRD.
This is 64 bit architecture and really large INITRD images should be
possible.
Simply put the existing code has a fixed reservation (claim) address and
Andrew,
Yesterday, I wrote:
> Please throw away the following 4 patches in 2.6.13-mm1:
>
> cpusets-oom_kill-tweaks.patch
> cpusets-new-__gfp_hardwall-flag.patch
> cpusets-formalize-intermediate-gfp_kernel-containment.patch
> cpusets-confine-oom_killer-to-mem_exclusive-cpuset.patch
On Tue, 2005-09-06 at 13:39 -0700, Rumen Ivanov Zarev wrote:
> Trivial patch against 2.6.13 to unhide SMBus on Compaq Evo N620c laptop using
> Intel 82855PM chipset.
> + } else if (unlikely(dev->subsystem_vendor == PCI_VENDOR_ID_COMPAQ)) {
Should unlikely() be used for cases where the
On Tue, 6 Sep 2005 18:19:45 -0400, Daniel Phillips <[EMAIL PROTECTED]> said:
Daniel> There are only two stacks involved, the normal kernel stack
Daniel> and your new ndis stack. You save ESP of the kernel stack
Sadly, that is not the case: Some drivers, especially USB drivers,
create
On 9/7/05, Esben Nielsen <[EMAIL PROTECTED]> wrote:
> On Tue, 6 Sep 2005, Jesper Juhl wrote:
>
> > On 9/6/05, Budde, Marco <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > for one of our customers I have to port a Windows driver to
> > > Linux. Large parts of the driver's backend code consists of
On Tuesday 06 September 2005 18:21, Andi Kleen wrote:
> On Wednesday 07 September 2005 00:19, Daniel Phillips wrote:
> > Andi, their stack will have to have a valid thread_info->task because
> > interrupts will use it. Out of interest, could you please explain what
> > for?
>
> No, with 4k
Daniel> There are only two stacks involved, the normal kernel
Daniel> stack and your new ndis stack. You save ESP of the kernel
Daniel> stack at the base of the ndis stack. When the Windows
Daniel> code calls your api, you get the ndis ESP, load the kernel
Daniel> ESP from
I'm looking at proto_unregister() in linux-2.6.13:
Il calls kmem_cache_destroy() while holding proto_list_lock:
void proto_unregister(struct proto *prot)
{
write_lock(_list_lock);
if (prot->slab != NULL) {
kmem_cache_destroy(prot->slab);
However,
On Wed, 7 Sep 2005, Esben Nielsen wrote:
> On Tue, 6 Sep 2005, Jesper Juhl wrote:
>
> > On 9/6/05, Budde, Marco <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > for one of our customers I have to port a Windows driver to
> > > Linux. Large parts of the driver's backend code consists of
> > > C++.
On Tue, 6 Sep 2005, Jesper Juhl wrote:
> On 9/6/05, Budde, Marco <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > for one of our customers I have to port a Windows driver to
> > Linux. Large parts of the driver's backend code consists of
> > C++.
> >
> > How can I compile this code with kbuild? The
On Tue, Sep 06, 2005 at 06:47:08PM +0200, Thomas Kleffel (LKML) wrote:
>
> The following patch is against vanilla 2.6.13.
>
> ldiff -uprN a/drivers/ide/legacy/ide-cs.c b/drivers/ide/legacy/ide-cs.c
> --- a/drivers/ide/legacy/ide-cs.c 2005-08-08 15:30:35.0 +0200
> +++
On Wednesday 07 September 2005 00:19, Daniel Phillips wrote:
> Andi, their stack will have to have a valid thread_info->task because
> interrupts will use it. Out of interest, could you please explain what
> for?
No, with 4k interrupts run on their own stack with their own thread_info
Or rather
"John W. Linville" <[EMAIL PROTECTED]> wrote:
>
> I fully intend to have have a flag in the private data set based on
> the PCI ID when I accumulate some data on which devices support this
> and which don't. So far I've only got a short list... Do you think
> such a flag should be based on
On Tuesday 06 September 2005 13:23, Giridhar Pemmasani wrote:
> Jan Kiszka wrote:
> > The only way I see is to switch stacks back on ndiswrapper API entry.
> > But managing all those stacks correctly is challenging,
There are only two stacks involved, the normal kernel stack and your new ndis
Below is a patch to implement demand faulting for huge pages. The main
motivation for changing from prefaulting to demand faulting is so that
huge page memory areas can be allocated according to NUMA policy.
Thanks to consolidated hugetlb code, switching the behavior requires changing
only one
Initial Post (Thu, 18 Aug 2005)
Basic overcommit checking for hugetlb_file_map() based on an implementation
used with demand faulting in SLES9.
Since demand faulting can't guarantee the availability of pages at mmap time,
this patch implements a basic sanity check to ensure that the number of
Initial Post (Thu, 18 Aug 2005)
In preparation for hugetlb demand faulting, remove this get_user_pages()
optimization. Since huge pages will no longer be prefaulted, we can't assume
that the huge ptes are established and hence, calling follow_hugetlb_page() is
not valid.
With the
I am sending out the latest set of patches for hugetlb demand faulting.
I've incorporated all the feedback I've received from previous
discussions and I think this is ready for some more widespread testing.
Is anyone opposed to spinning this in -mm as it stands?
The three patches:
1) Remove a
> With my subsystem that would look like:
>
> static const struct spi_cs_table
> platform_spi1_cs_table[] = {
> {
> .name = "touchscreen",
> .cs_no = 1,
> .platform_data = NULL,
> .flags = SPI_CS_IDLE_HIGH,
> .cs_data = 0,
> },
> {
> .name = "flash",
> .cs_no = 3,
>
On Tuesday 06 September 2005 22:55, Terrence Miller wrote:
> Andi Kleen wrote:
> > I don't think the functionality of having single copies in case
> > an out of line version was needed was ever required by the Linux kernel.
>
> But shouldn't the compiler that compiles Linux be C99 compliant?
At
On Tue, Sep 06, 2005 at 01:23:56PM +0200, Budde, Marco wrote:
> Hi,
>
> for one of our customers I have to port a Windows driver to
> Linux. Large parts of the driver's backend code consists of
> C++.
>
> How can I compile this code with kbuild? The C++ support
> (I have tested with 2.6.11) of
Hi,
On Tue, 6 Sep 2005, Terrence Miller wrote:
> Andi Kleen wrote:
> > I don't think the functionality of having single copies in case
> > an out of line version was needed was ever required by the Linux kernel.
>
> But shouldn't the compiler that compiles Linux be C99 compliant?
As "extern
elf_aux is userland code; it uses symbol (ELF_CLASS) that doesn't exist in
userland headers; pulled into kernel-offsets.h, switched elf_aux to using it.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
diff -urN RC13-git5-base/arch/um/include/common-offsets.h
On Wed, 7 Sep 2005, Tony Breeds wrote:
> On Tue, Sep 06, 2005 at 08:53:38PM +0200, Thomas Glanzmann wrote:
> > Hello,
> > I would like to build the 3c59x vortex module into the kernel (not as
> > module) but don't loose the ability to use wakeup-on-lan. Because it
> > seems to be impossible to
On Tue, Sep 06, 2005 at 08:53:38PM +0200, Thomas Glanzmann wrote:
> Hello,
> I would like to build the 3c59x vortex module into the kernel (not as
> module) but don't loose the ability to use wakeup-on-lan. Because it
> seems to be impossible to specify 'module parameters' to a built-in
> kernel
On 31.08.2005 [13:01:09 -0700], Nishanth Aravamudan wrote:
> Sorry everybody, forgot the most important Cc: :)
>
> -Nish
>
> Hi Andrew,
>
> In looking at Bug 5132 and sys_poll(), I think there is a flaw in the
> current code.
>
> The @timeout parameter to sys_poll() is in milliseconds but we
[EMAIL PROTECTED] <[EMAIL PROTECTED]> :
> On Tue, 06 Sep 2005 22:42:21 +0200, Francois Romieu said:
>
> > Currently one can do 'ifconfig ethX up', check the link status, then try
> > to DHCP or whatever. Apparently a few drivers do not support tne detection
> > of link as presented above. So is
On 9/6/05, Budde, Marco <[EMAIL PROTECTED]> wrote:
> Hi,
>
> for one of our customers I have to port a Windows driver to
> Linux. Large parts of the driver's backend code consists of
> C++.
>
> How can I compile this code with kbuild? The C++ support
> (I have tested with 2.6.11) of kbuild seems
On Tue, Sep 06, 2005 at 09:13:25AM -0500, James Bottomley wrote:
> On Tue, 2005-09-06 at 17:49 +1000, Anton Blanchard wrote:
> > Any chance we could get this into 2.6.14? I just tested it on current
> > git and as expected the number of sg elements increased. Testing a dd
> > from a virtual disk
The kernel module drbd (version 0.7.13) can no longer find its
devices (e.g., /dev/drbd0, /dev/drbd1) in kernel 2.6.13. The version
of udev I am using 065/068 didn't make a difference. It works fine
with kernel 2.6.12.5 and 2.6.12.6.
--
Maurice Volaski, [EMAIL PROTECTED]
Computing Support,
While playing with a new AMD Athlon64 X2 3800+ (i386) the keyboard goes
wild for 10 (20?) seconds, behaves normally for 10 (20?) seconds, and
then goes wild again: when "wild", every keypress results in a random
number of repeats, e.g.:
$ pppsss aaxxxuuu
bash: pppsss: command not found
$
On Tue, Sep 06, 2005 at 01:30:34PM +0200, Bernd Petrovitsch wrote:
> Yes, because the official Linux kernel is pure C (using some gcc
> extensions).
> There is http://netlab.ru.is/exception/LinuxCXX.shtml but it is
> a) not integrated (and will probably never) and
> b) you can't use parts of C++
This patch is correct.
r~
On Mon, Sep 05, 2005 at 02:42:36PM -0400, Chaskiel Grundman wrote:
> On Mon, 5 Sep 2005, Jesper Juhl wrote:
> > Why not post the patch you made for review as well?
>
> In part because if the analysis is wrong, then the patch surely is.
>
> but mostly because I didn't
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> On Tue, Sep 06, 2005 at 04:44:00PM -0400, John W. Linville wrote:
> > Add module option to enable 3c59x driver to use memory-mapped PCI I/O
> > resources. This may improve performance for those devices so equipped.
> >
> > Add "use_mmio=1" to the
Oops, forgot the config file...
On Tue, 2005-09-06 at 14:25 -0400, Adam Petaccia wrote:
> On Mon, 2005-09-05 at 23:44 +1000, Con Kolivas wrote:
> > These are patches designed to improve system responsiveness and
> > interactivity.
> > It is configurable to any workload but the default ck* patch
On Tue, 06 Sep 2005 22:42:21 +0200, Francois Romieu said:
> Currently one can do 'ifconfig ethX up', check the link status, then try
> to DHCP or whatever. Apparently a few drivers do not support tne detection
> of link as presented above. So is it anything like a vendor requirement/a
> standard
1 - 100 of 533 matches
Mail list logo
