On Fri, Feb 08, 2008 at 02:26:41PM -0800, Dave Hansen wrote:
> This is against current Linus git
> (a4ffc0a0b240a29cbe489f6db9dae112a49ef1c1).
>
> This rolls up all the -mm bugfixes that were accumulated, and
> addresses some new review comments from Al. Also contains some
> reworking from hch
On Tue, 5 Feb 2008 14:05:06 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > http://students.zipernowsky.hu/~oliverp/kernel/regression_2624/
> I think ub.c is basically abandoned in favour of usb-storage.
> If so, perhaps we should remove or disble ub.c?
Looks like it's just Tomo or Jens
--- On Fri, 2/8/08, Nicholas A. Bellinger <[EMAIL PROTECTED]> wrote:
> > Is there an open iSCSI Target implementation which
> does NOT
> > issue commands to sub-target devices via the SCSI
> mid-layer, but
> > bypasses it completely?
> >
> >Luben
> >
>
> Hi Luben,
>
> I am guessing you
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Fri, 8 Feb 2008 22:45:22 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > Linus, please pull the latency tracer tree from:
> >
> >git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git
> >
> > Find the shortlog below.
> >
--- On Fri, 2/8/08, Vladislav Bolkhovitin <[EMAIL PROTECTED]> wrote:
> > Is there an open iSCSI Target implementation which
> does NOT
> > issue commands to sub-target devices via the SCSI
> mid-layer, but
> > bypasses it completely?
>
> What do you mean? To call directly low level backstorage
>
On Sat, Feb 09, 2008 at 02:19:27AM -0500, Erez Zadok wrote:
> > * Invokes filesystem specific ->unlocked_ioctl, if one exists; otherwise
> > * invokes * filesystem specific ->ioctl method. If neither method exists,
> ^
>
> I also think this extra '*' in the last comment line
On Fri, 8 Feb 2008 22:45:22 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Linus, please pull the latency tracer tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git
>
> Find the shortlog below.
>
> This is the latency tracer from -rt
I've never seen any
In message <[EMAIL PROTECTED]>, Christoph Hellwig writes:
> - remove non-standard in/out markers
> - use tabs for formatting
>
>
> Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
>
> Index: linux-2.6/fs/ioctl.c
> ===
> ---
- remove non-standard in/out markers
- use tabs for formatting
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Index: linux-2.6/fs/ioctl.c
===
--- linux-2.6.orig/fs/ioctl.c 2008-02-09 07:49:02.0 +0100
+++
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> It does include one very interesting new feature that deserves to be
> mentioned outside of the shortlog: 'dynamic ftrace' - which is a
> transparent kernel-image-patcher mechanism that lazily patches out
> mcount callsites from all functions that
On Sat, Feb 09, 2008 at 12:39:41AM -0600, Jason Wessel wrote:
> The kgdb tree has been collapsed review. It includes
> the kgdb core, the x86 arch, the kgdb8250 uart driver
> and the kgdb console sharing driver.
>
> Since the last time the kgdb patches were posted to LKML
> several months ago,
On Fri, Feb 08, 2008 at 11:31:24PM +, Chris Rankin wrote:
> Hi,
>
> I've just tried booting the 2.6.24.1 kernel, except without
> nmi_watchdog being enabled. It looks like there are IRQs still not
> being enabled.
Does 2.6.24 work? Is this a 2.6.24.1 regression?
thanks,
greg k-h
--
To
The kgdb tree has been collapsed review. It includes
the kgdb core, the x86 arch, the kgdb8250 uart driver
and the kgdb console sharing driver.
Since the last time the kgdb patches were posted to LKML
several months ago, the kgdb core has undergone some
significant cleanup, as well as the kgdb
On Fri, Feb 08, 2008 at 07:00:37PM +0100, Rodolfo Giometti wrote:
> This patch adds the kernel side of the PPS support currently named
> "LinuxPPS".
>
> PPS means "pulse per second" and a PPS source is just a device which
> provides a high precision signal each second so that an application
> can
On Fri, Feb 08, 2008 at 02:26:41PM -0800, Dave Hansen wrote:
> This is against current Linus git
> (a4ffc0a0b240a29cbe489f6db9dae112a49ef1c1).
>
> This rolls up all the -mm bugfixes that were accumulated, and
> addresses some new review comments from Al. Also contains some
> reworking from hch
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> one of these caused a build failure in x86.git overnight randconfig
> testing:
>
> drivers/built-in.o: In function `acpi_fan_remove':
> fan.c:(.text+0x361d5): undefined reference to
> `thermal_cooling_device_unregister'
> drivers/built-in.o: In
* Len Brown <[EMAIL PROTECTED]> wrote:
> Hi Linus,
>
> please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release
one of these caused a build failure in x86.git overnight randconfig
testing:
drivers/built-in.o: In function `acpi_fan_remove':
Regarding:
commit 18dabf473e15850c0dbc8ff13ac1e2806d542c15
This actually breaks the 802.11 subsystem (http://80211.sf.net) which
relies on the page struct. (ieee80211_crypt_wep.c, line 190) Can
anyone suggest an alternative kernel function or method? As of 2.6.24,
the 802.11 subsystem cannot
On Fri, 8 Feb 2008, Vladislav Bolkhovitin wrote:
2. I think, everybody will agree that Linux iSCSI target should work over
some standard SCSI target framework. Hence the choice gets narrower: SCST
vs STGT. I don't think there's a way for a dedicated iSCSI target (i.e.
PyX/LIO) in the
(Carlos Cc:-ed too)
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Len Brown <[EMAIL PROTECTED]> wrote:
>
> > Len Brown (6):
> > ACPI: add newline to printk
> > ACPI: build WMI on X86 only
> > acer-wmi, tc1100-wmi: select ACPI_WMI
>
> hm, this new WMI code caused a bootup
On Fri, 2008-02-08 at 23:10 -0400, Konrad Rzeszutek wrote:
> + if (hdr->id == id_nic) {
> + pci_dev = pci_get_bus_and_slot((nic->pci_bdf & 0xff00) >> 8,
> + (nic->pci_bdf & 0xff));
> + if (pci_dev) {
> +
On Fri, 2008-02-08 at 23:10 -0400, Konrad Rzeszutek wrote:
> + ibft_device = kmalloc(len, GFP_KERNEL);
> + if (!ibft_device)
> + return -ENOMEM;
> +
> + memcpy(ibft_device, hdr, len);
This piece looks a bit odd. you're making ibft_device an exact
duplicate of
On Fri, 2008-02-08 at 23:10 -0400, Konrad Rzeszutek wrote:
> +/*
> + * Physical location of iSCSI Boot Format Table.
This is now the Virtual address, isn't it? So just drop the Physical.
> + */
> +unsigned long ibft_addr;
> +EXPORT_SYMBOL(ibft_addr);
And since it is the virtual address,
On Sat, 9 Feb 2008 05:47:18 +0100 (CET) Roman Zippel <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Fri, 8 Feb 2008, john stultz wrote:
>
> >
> > clock = clocksource_get_next();
> > - clocksource_calculate_interval(clock,
> > - (unsigned
On Fri, Feb 08, 2008 at 08:24:25PM -0800, Roland Dreier wrote:
> So I was perusing the code in lib/kobject.c, and I saw this:
>
> void kobject_init(struct kobject *kobj, struct kobj_type *ktype)
> {
> // [a couple of of parameter checks...]
> if
On Fri, Feb 08, 2008 at 02:26:54PM -0800, Dave Hansen wrote:
>
> open_namei() will, in the future, need to take mount write counts
> over its creation and truncation (via may_open()) operations. It
> needs to keep these write counts until any potential filp that is
> created gets __fput()'d.
>
Hi,
On Fri, 8 Feb 2008, john stultz wrote:
>
> clock = clocksource_get_next();
> - clocksource_calculate_interval(clock,
> - (unsigned long)(current_tick_length()>>TICK_LENGTH_SHIFT));
> + clocksource_calculate_interval(clock, NTP_INTERVAL_LENGTH);
>
Commit c18bab80 ("Input: i8042 - non-x86 build fix") introduced the
following warning on non-x86 builds:
drivers/input/serio/i8042.c: In function 'i8042_probe':
drivers/input/serio/i8042.c:1154: warning: unused variable 'param'
Fix this by moving the parameter variable declaration into
Commit c18bab80 ("Input: i8042 - non-x86 build fix") introduced the
following warning on non-x86 builds:
drivers/input/serio/i8042.c: In function 'i8042_probe':
drivers/input/serio/i8042.c:1154: warning: unused variable 'param'
Fix this by moving the parameter variable declaration into
From: Randy Dunlap <[EMAIL PROTECTED]>
cc: Alan Cox <[EMAIL PROTECTED]>
Drop z85230 support library info from kernel-api since it's duplicated
in the Z85230 book.
Alan, is this OK with you?
(This is one of several patches that I have my queue for reducing the
size of kernel-api.* .)
So I was perusing the code in lib/kobject.c, and I saw this:
void kobject_init(struct kobject *kobj, struct kobj_type *ktype)
{
// [a couple of of parameter checks...]
if (kobj->state_initialized) {
/* do not error out as
On Sat, 9 Feb 2008 01:33:22 + Samuel Thibault wrote:
> Document the keyboard notifier.
>
> Signed-off-by: Samuel Thibault <[EMAIL PROTECTED]>
>
> --- /dev/null 2008-02-09 01:22:34.790011677 +
> +++ linux/Documentation/input/notifier.txt2008-02-09 01:28:12.0
> +
> @@
On 2/8/08, Michael Opdenacker <[EMAIL PROTECTED]> wrote:
> +config CPU_SUP_INTEL
> + default y
> + bool "Support Intel processors" if PROCESSOR_SELECT
> + help
> + This enables extended support for Intel processors
> -obj-$(CONFIG_X86_32) += intel.o
>
Whoops. I've attached an incorrect patch in the previous
e-mail (http://lkml.org/lkml/2008/2/8/350) that didn't take
in to account the 'reserve_bootmem' parameters changes.
Here is fresher copy which has been tested on 2.6.24-git19
on a machine with iBFT and without.
This patch (v0.4.7) adds
On Fri, 2008-02-08 at 18:53 -0800, Harvey Harrison wrote:
> diff --git a/fs/affs/file.c b/fs/affs/file.c
> index 6e0c939..ac05dc2 100644
> --- a/fs/affs/file.c
> +++ b/fs/affs/file.c
> @@ -570,11 +570,11 @@ affs_extent_file_ofs(struct inode *inode, u32 newsize)
> bh->b_state &= ~(1UL
Introduce _tmp in the small if-blocks where this is shadowed.
fs/affs/file.c:573:8: warning: symbol 'tmp' shadows an earlier one
fs/affs/file.c:530:6: originally declared here
fs/affs/file.c:714:9: warning: symbol 'tmp' shadows an earlier one
fs/affs/file.c:661:6: originally declared here
On Fri, 2008-02-08 at 18:33 +0100, Roman Zippel wrote:
> Hi,
>
> On Fri, 1 Feb 2008, John Stultz wrote:
>
> > > CLOCK_TICK_ADJUST is based on LATCH and HZ, if the update frequency isn't
> > > based on HZ, there is no point in using it!
> >
> > Hey Roman,
> >
> > Again, I'm sorry I don't seem
On Sat, 9 Feb 2008, Andrea Arcangeli wrote:
> The VM shouldn't break if try_to_unmap doesn't actually make the page
> freeable for whatever reason. Permanent pins shouldn't happen anyway,
VM is livelocking if too many page are pinned that way right now. The
higher the processors per node the
On Fri, Feb 08, 2008 at 05:27:03PM -0800, Christoph Lameter wrote:
> Pages will still be on the LRU and cycle through rmap again and again.
> If page migration is used on those pages then the code may make repeated
> attempt to migrate the page thinking that the page count must at some
> point
Olof Johansson wrote:
Hi,
I ended up with a customer benchmark in my lap this week that doesn't
do well on recent kernels. :(
After cutting it down to a simple testcase/microbenchmark, it seems like
recent kernels don't do as well with short-lived threads competing
with the thread it's cloned
Document the keyboard notifier.
Signed-off-by: Samuel Thibault <[EMAIL PROTECTED]>
--- /dev/null 2008-02-09 01:22:34.790011677 +
+++ linux/Documentation/input/notifier.txt 2008-02-09 01:28:12.0
+
@@ -0,0 +1,52 @@
+Keyboard notifier
+
+One can use
Alan Cox wrote:
The word "illegal" has a precise dictionary meaning of "prohibited by
law".
Also "contrary to or forbidden by official rules, regulations, etc".
So word meanings are like standards, there are so many to choose
from.
The error messages are therefore incorrect as so far nobody
On Sat, 9 Feb 2008, Andrea Arcangeli wrote:
> > H.. that means we need something that actually pins pages for good so
> > that the VM can avoid reclaiming it and so that page migration can avoid
> > trying to migrate them. Something like yet another page flag.
>
> What's wrong with pinning
On Fri, Feb 08, 2008 at 04:36:16PM -0800, Christoph Lameter wrote:
> On Fri, 8 Feb 2008, Roland Dreier wrote:
>
> > That would of course work -- dumb adapters would just always fail,
> > which might be inefficient.
>
> H.. that means we need something that actually pins pages for good so
>
> > > As long as one or more GPIOs on a gpio chip are used its driver should
> > > not
> > > be unloaded.
> >
> > The mechanism currently in place is to have gpiochip_remove() fail
> > if the platform's teardown() logic doesn't reject it. (It may be
> > practical to have the teardown code get
On Thu, Feb 07, 2008 at 01:58:34PM -0800, Greg KH wrote:
> On Thu, Feb 07, 2008 at 11:41:42PM +0200, S.??a??lar Onur wrote:
> > Hi;
> >
> > 07 ??ub 2008 Per tarihinde, Greg KH ??unlar?? yazmt??:
> > > This is the start of the stable review cycle for the 2.6.24.1 release.
> > > There are 45
2008/2/9, Jan Engelhardt <[EMAIL PROTECTED]>:
>
> On Feb 9 2008 00:14, Joonwoo Park wrote:
> >2008/2/8, rohit h <[EMAIL PROTECTED]>:
> >> Hi,
> >> I am a kernel newbie.
> >> I tried to insmod a C++ module containing classes, inheritance.
> >> I am getting 'unresolved symbol' error when I use
On Fri, 8 Feb 2008, David Brownell wrote:
> On Friday 08 February 2008, Guennadi Liakhovetski wrote:
> > As long as one or more GPIOs on a gpio chip are used its driver should not
> > be unloaded.
>
> The mechanism currently in place is to have gpiochip_remove() fail
> if the platform's
On Fri, 8 Feb 2008, Roland Dreier wrote:
> That would of course work -- dumb adapters would just always fail,
> which might be inefficient.
H.. that means we need something that actually pins pages for good so
that the VM can avoid reclaiming it and so that page migration can avoid
trying
Rafael J. Wysocki wrote:
Consolidated patch is appended. I'll test it tomorrow on x86-64.
I'd like to add the cleaned up beeping code to it and perhaps try to push it
for -mm testing without any further changes. We can still do more cleanups in
followup patches.
The other thing to figure
On Sat, Feb 09, 2008 at 01:08:30AM +0100, Ingo Molnar wrote:
>
> * Olof Johansson <[EMAIL PROTECTED]> wrote:
>
> > 2.6.22: 3332 ms
> > 2.6.23: 4397 ms
> > 2.6.24: 8953 ms
> > 2.6.24-git19: 8986 ms
>
> if you enable SCHED_DEBUG, and subtract 4 from the value of
>
On Sat, Feb 09, 2008 at 01:05:15AM +0100, Jiri Kosina wrote:
> On Sat, 9 Feb 2008, Adrian Bunk wrote:
>
> > Commit dd2cc4dff3b08ab54c4c177a080046bcc84ac41d broke uml:
> > <-- snip -->
> > ...
> > CC fs/hostfs/hostfs_kern.o
> >
Jon wrote:
> So here's a version which merges the information into
> SubmittingPatches instead.
Reviewed-by: Paul Jackson <[EMAIL PROTECTED]>
---
That's my first time using that tag ... fun. Now I'm wondering if there
might be some improvements that you, me, or someone could make to the
> I thought the adaptor can always remove the mapping by renegotiating
> with the remote side? Even if its dumb then a callback could notify the
> driver that it may be required to tear down the mapping. We then hold the
> pages until we get okay by the driver that the mapping has been
On Friday, 8 of February 2008, Pavel Machek wrote:
> On Fri 2008-02-08 23:01:51, Rafael J. Wysocki wrote:
> > On Friday, 8 of February 2008, Pavel Machek wrote:
> > > Hi!
> > >
> > > Rafael, this is for you.
> >
> > Thanks.
> >
> > > My cleanups, relative to your cleanup patch. You may need
On Fri, 8 Feb 2008, Andrew Morton wrote:
> Quite possibly none of the infiniband developers even know about it..
Well Andrea's initial approach was even featured on LWN a couple of
weeks back.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Commit 9e016a719209d95338e314b46c3012cc7feaaeec causes the following
compile error:
<-- snip -->
...
CC drivers/ide/arm/bast-ide.o
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ide/arm/bast-ide.c: In
function 'bastide_register':
On Fri, 8 Feb 2008, Roland Dreier wrote:
> In general, this MMU notifier stuff will only be useful to a subset of
> InfiniBand/RDMA hardware. Some adapters are smart enough to handle
> changing the IO virtual -> bus/physical mapping on the fly, but some
> aren't. For the dumb adapters, I think
> We have done several rounds of discussion on linux-kernel about this so
> far and the IB folks have not shown up to join in. I have tried to make
> this as general as possible.
Sorry, this has been on my "things to look at" list for a while, but I
haven't gotten a chance to really
On Fri, 8 Feb 2008 16:05:00 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Fri, 8 Feb 2008, Andrew Morton wrote:
>
> > You took it correctly, and I didn't understand the answer ;)
>
> We have done several rounds of discussion on linux-kernel about this so
> far and the IB folks
* Olof Johansson <[EMAIL PROTECTED]> wrote:
> 2.6.22: 3332 ms
> 2.6.23: 4397 ms
> 2.6.24: 8953 ms
> 2.6.24-git19: 8986 ms
if you enable SCHED_DEBUG, and subtract 4 from the value of
/proc/sys/kernel/sched_features, does it get any better?
if not, does writing 0 into
On Fri, 8 Feb 2008, Andrew Morton wrote:
> You took it correctly, and I didn't understand the answer ;)
We have done several rounds of discussion on linux-kernel about this so
far and the IB folks have not shown up to join in. I have tried to make
this as general as possible.
--
To unsubscribe
On Sat, 9 Feb 2008, Adrian Bunk wrote:
> Commit dd2cc4dff3b08ab54c4c177a080046bcc84ac41d broke uml:
> <-- snip -->
> ...
> CC fs/hostfs/hostfs_kern.o
> /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/hostfs/hostfs_kern.c: In
> function 'hostfs_show_options':
>
Commit 30b0c37b27485a9cb897bfe3824f6f517b8c80d6 causes the following
compile error:
<-- snip -->
...
CC drivers/scsi/arm/fas216.o
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/scsi/arm/fas216.c: In
function 'fas216_std_done':
On Fri, 08 Feb 2008 16:22:12 -0600
Anthony Liguori <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
> > I notice that recent KVM is incompatiable with older versions.
> >
> > Using a KVM image created on 2.6.24 will crash on 2.6.25 (or
> > vice versa). It appears that Ubuntu Hardy has
Hi,
I ended up with a customer benchmark in my lap this week that doesn't
do well on recent kernels. :(
After cutting it down to a simple testcase/microbenchmark, it seems like
recent kernels don't do as well with short-lived threads competing
with the thread it's cloned off of. The CFS
net/sunrpc/xprtrdma/svc_rdma_sendto.c:160: warning: format '%llx' expects type
'long long unsigned int', but argument 3 has type 'u64'
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
diff --git a/net/sunrpc/xprtrdma/svc_rdma_sendto.c
b/net/sunrpc/xprtrdma/svc_rdma_sendto.c
index
Andrew Morton wrote:
On Fri, 8 Feb 2008 15:37:41 -0800 Randy Dunlap <[EMAIL PROTECTED]> wrote:
I think someone already sent a patch to select the LEDS
I did... and more. Who will merge it? (below)
---
From: Randy Dunlap <[EMAIL PROTECTED]>
Add I2C to config since the driver makes several
On Friday 08 February 2008, Guennadi Liakhovetski wrote:
> As long as one or more GPIOs on a gpio chip are used its driver should not
> be unloaded.
The mechanism currently in place is to have gpiochip_remove() fail
if the platform's teardown() logic doesn't reject it. (It may be
practical to
On Fri, 2008-02-08 at 17:42 +0300, Vladislav Bolkhovitin wrote:
> Nicholas A. Bellinger wrote:
> > On Thu, 2008-02-07 at 12:37 -0800, Luben Tuikov wrote:
> >
> >>Is there an open iSCSI Target implementation which does NOT
> >>issue commands to sub-target devices via the SCSI mid-layer, but
>
On Fri, Feb 08, 2008 at 03:22:29PM -0800, Badari Pulavarty wrote:
>
> On Thu, 2008-02-07 at 20:55 -0800, Greg KH wrote:
> > On Thu, Feb 07, 2008 at 05:25:46PM -0800, Badari Pulavarty wrote:
> > > On Thu, 2008-02-07 at 16:38 -0800, Greg KH wrote:
> > > > On Thu, Feb 07, 2008 at 03:56:58PM -0800,
On Fri, Feb 08, 2008 at 02:56:09PM -0800, Arjan van de Ven wrote:
> Nick Piggin wrote:
> >>>Maybe cpus these days have so much store bandwith that doing
> >>>things like the above is OK, but I doubt it :-)
> >>on modern x86 cpus the memset may even be faster if the memory isn't in
> >>cache;
>
On Fri, 8 Feb 2008 17:43:02 -0600 Robin Holt <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 08, 2008 at 03:41:24PM -0800, Christoph Lameter wrote:
> > On Fri, 8 Feb 2008, Robin Holt wrote:
> >
> > > > > What about ib_umem_get()?
> >
> > Correct.
> >
> > You missed the turn of the conversation to how
On Fri, 8 Feb 2008 15:37:41 -0800 Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > I think someone already sent a patch to select the LEDS
>
> I did... and more. Who will merge it? (below)
>
> ---
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Add I2C to config since the driver makes several i2c*()
On Fri, 8 Feb 2008 15:22:44 -0800 Randy Dunlap <[EMAIL PROTECTED]> wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Fix printk format warnings:
> linux-2.6.24-git19/drivers/pcmcia/i82092.c:650: warning: format '%lx' expects
> type 'long unsigned int', but argument 3 has type
On Fri, 2008-02-08 at 17:36 +0300, Vladislav Bolkhovitin wrote:
> Nicholas A. Bellinger wrote:
> - It has been discussed which iSCSI target implementation should be in
> the mainstream Linux kernel. There is no agreement on this subject
> yet. The short-term options are as follows:
>
On 09/02/2008, Randy Dunlap <[EMAIL PROTECTED]> wrote:
...
> > On Sat, 9 Feb 2008 00:25:36 +0100
> > Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
...
> > I think someone already sent a patch to select the LEDS
>
> I did... and more. Who will merge it? (below)
>
> ---
> From: Randy Dunlap <[EMAIL
On Thursday 31 January 2008, Guennadi Liakhovetski wrote:
> As discussed on i2c mailing list with David Brownell, and number
> outside of the 0...MAX_INT range is invalid as a GPIO number.
> Define a macro, similar to NO_IRQ, to be used as a deliberate
> invalid GPIO, rather than defining a
On Fri, Feb 08, 2008 at 03:41:24PM -0800, Christoph Lameter wrote:
> On Fri, 8 Feb 2008, Robin Holt wrote:
>
> > > > What about ib_umem_get()?
>
> Correct.
>
> You missed the turn of the conversation to how ib_umem_get() works.
> Currently it seems to pin the same way that the SLES10 XPmem
On Friday, 8 of February 2008, Jeff Mahoney wrote:
> Rafael J. Wysocki wrote:
> > On Friday, 8 of February 2008, Pavel Machek wrote:
> >> Hi!
> >>
> >>> Our old friend kernel BUG at kernel/power/snapshot.c:464! is back, this
> >>> time from mainline. I can't reproduce with 2.6.24-final, but I can
On Fri, 8 Feb 2008, Robin Holt wrote:
> > > What about ib_umem_get()?
> >
> > Ok. It pins using an elevated refcount. Same as XPmem right now. With that
> > we effectively pin a page (page migration will fail) but we will
> > continually be reclaiming the page and may repeatedly try to move
Hi David,
> > Anyway you are still under the impression that a Linux kernel module can
> > be original work in the end. We keep telling you that could be a wrong
> > assumption which is based on the view of many of the kernel developers
> > and of most of the lawyers that looked at this specific
Change cpu_buffer from array to per_cpu variable in
oprofile functions.
Based on linux-2.6.git + x86.git
Cc: Philippe Elie <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
drivers/oprofile/buffer_sync.c|2 +-
drivers/oprofile/cpu_buffer.c
On Fri, 8 Feb 2008 15:28:12 -0800 Stephen Hemminger wrote:
> On Sat, 9 Feb 2008 00:25:36 +0100
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > * Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> >
> > > Stephen Hemminger (2):
> > > Input: add driver for Fujitsu application buttons
> >
> >
Removal of trivial comments in processor.h
Based on linux-2.6.git + x86.git
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
include/asm-x86/processor.h |4
1 file changed, 4 deletions(-)
--- a/include/asm-x86/processor.h
+++ b/include/asm-x86/processor.h
@@ -302,10 +302,6 @@ union
Change cpu frequency tables from arrays to per_cpu variables.
Based on linux-2.6.git + x86.git
Cc: Dave Jones <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
drivers/cpufreq/cpufreq_userspace.c | 71 +++-
1 file
Here's another round of removing static allocations of arrays
using NR_CPUS to size the length. The change is to use PER_CPU
variables in place of the static tables.
Based on linux-2.6.git + x86.git
Cc: Dave Jones <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: Len Brown <[EMAIL PROTECTED]>
Cc:
Change cpufreq tables from arrays to per_cpu variables in
drivers/acpi/processor_thermal.c
Based on linux-2.6.git + x86.git
Cc: Len Brown <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
drivers/acpi/processor_thermal.c | 21 +++--
1
On Fri, 8 Feb 2008, Jan Engelhardt wrote:
>
> On Feb 8 2008 22:34, ael wrote:
> >
> >Sure, I looked there in some depth. But some/most are special purpose or
> > 'locals'. One needs a map for the "main" repositories...
>
> Indeed, a page on kernelnewbies.org with the most important repositories
On Fri, Feb 08, 2008 at 03:32:19PM -0800, Christoph Lameter wrote:
> On Fri, 8 Feb 2008, Andrew Morton wrote:
>
> > What about ib_umem_get()?
>
> Ok. It pins using an elevated refcount. Same as XPmem right now. With that
> we effectively pin a page (page migration will fail) but we will
>
On Fri, Feb 08, 2008 at 02:46:15PM -0800, Andrew Morton wrote:
> I think it would have been better to define a new CONFIG_MODULEPARAM_CONST
> for those three archictures, rather than muckying up the code like this.
I'd prefer to keep this as is for now (sorta the uglier the better ;-)
I really
On Fri, 8 Feb 2008, Andrew Morton wrote:
> What about ib_umem_get()?
Ok. It pins using an elevated refcount. Same as XPmem right now. With that
we effectively pin a page (page migration will fail) but we will
continually be reclaiming the page and may repeatedly try to move it. We
have issues
Hi,
I've just tried booting the 2.6.24.1 kernel, except without nmi_watchdog being
enabled. It looks
like there are IRQs still not being enabled.
Cheers,
Chris
Linux version 2.6.24.1 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070925 (Red Hat
4.1.2-33))
#1 SMP PREEMPT Fri Feb 8 22:41:10 GMT 2008
On Sat, 9 Feb 2008 00:25:36 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
>
> > Stephen Hemminger (2):
> > Input: add driver for Fujitsu application buttons
>
> this change broke the build on x86 in randconfig testing:
>
>
Hi Valdis,
> > And while you are talking to a lawyer. Ask him/her if it is okay to
> > create a binary only application that uses a GPL library. Tell him/her
>
> It's perfectly legal to create such an application.
>
> It only gets interesting if you *distribute* it...
>
> (And yes, this is
On Friday 08 February 2008 16:36:37 Alan Cox wrote:
> > In other words "EXPORT_SYMBOL_GPL" isn't his idea of "a good legal idea",
> > but people ignoring this and doing things that circumvent this will,
> > eventually, have problems with the people who hold the copyright on the
> > code. (In
* Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger (2):
> Input: add driver for Fujitsu application buttons
this change broke the build on x86 in randconfig testing:
drivers/built-in.o: In function `apanel_detach_client':
apanel.c:(.text+0x15c120): undefined reference
On Fri, 8 Feb 2008, Jiri Kosina wrote:
> > > I hope that, from at least my perspective, your question is
> > > rhetorical.
> > Yeah. The non rhetorical one was directed to Jiri. :)
> Actually, I have no idea :) I am right now confused too, I am quite
> surprised that 'nohpet' fixes the problem
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix printk format warnings:
linux-2.6.24-git19/drivers/pcmcia/i82092.c:650: warning: format '%lx' expects
type 'long unsigned int', but argument 3 has type 'resource_size_t'
linux-2.6.24-git19/drivers/pcmcia/i82092.c:650: warning: format '%lx' expects
type
And the same thing with 2.6.24.1.
Cheers,
Chris
Linux version 2.6.24.1 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070925 (Red Hat
4.1.2-33))
#1 SMP PREEMPT Fri Feb 8 22:41:10 GMT 2008
BIOS-provided physical RAM map:
BIOS-e820: - 0009fc00 (usable)
BIOS-e820:
1 - 100 of 1083 matches
Mail list logo
