Re: IO queuing and complete affinity with threads (was Re: [PATCH 0/8] IO queuing and complete affinity)
On Fri, Feb 08, 2008 at 08:47:47AM +0100, Jens Axboe wrote: > On Fri, Feb 08 2008, Nick Piggin wrote: > > On Thu, Feb 07, 2008 at 07:25:45PM +0100, Jens Axboe wrote: > > > Hi, > > > > > > Here's a variant using kernel threads only, the nasty arch bits are then > > > not needed. Works for me, no performance testing (that's a hint for Alan > > > to try and queue up some testing for this variant as well :-) > > > > Well this stuff looks pretty nice (although I'm not sure whether the > > softirq->thread changes are a good idea for performance, I guess we'll > > see). > > Yeah, that is indeed an open question and why I have two seperate > patches for now (io-cpu-affinity branch and io-cpu-affinity-kthread > branch). As Ingo mentioned, this is how softirqs are handled in the -rt > branch already. True, although there are some IO workloads where -rt falls behind mainline. May not be purely due to irq threads though, of course. > > You still don't have the option that the Intel patch gave, that is, > > to submit on the completer. I guess that you could do it somewhat > > generically by having a cpuid in the request queue, and update that > > with the completing cpu. > > Not sure what you mean, if setting queue_affinity doesn't accomplish it. > If you know the completing CPU to begin with, surely you can just set > the queuing affinity appropriately? And if you don't? > > At least they reported it to be the most efficient scheme in their > > testing, and Dave thought that migrating completions out to submitters > > might be a bottleneck in some cases. > > More so than migrating submitters to completers? The advantage of only > movign submitters is that you get rid of the completion locking. Apart > from that, the cost should be the same, especially for the thread based > solution. Not specifically for the block layer, but higher layers like xfs. -- 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/
Re: [rfc] direct IO submission and completion scalability issues
On Tue, Feb 05, 2008 at 11:14:19AM +1100, David Chinner wrote: > On Mon, Feb 04, 2008 at 11:09:59AM +0100, Nick Piggin wrote: > > You get better behaviour in the slab and page allocators and locality > > and cache hotness of memory. For example, I guess in a filesystem / > > pagecache heavy workload, you have to touch each struct page, buffer head, > > fs private state, and also often have to wake the thread for completion. > > Much of this data has just been touched at submit time, so doin this on > > the same CPU is nice... > > [] > > > I'm surprised that the xfs global state bouncing would outweigh the > > bouncing of all the per-page/block/bio/request/etc data that gets touched > > during completion. We'll see. > > per-page/block.bio/request/etc is local to a single I/O. the only > penalty is a cacheline bounce for each of the structures from one > CPU to another. That is, there is no global state modified by these > completions. Yeah, but it is going from _all_ submitting CPUs to the one completing CPU. So you could bottleneck the interconnect at the completing CPU just as much as if you had cachelines being pulled the other way (ie. many CPUs trying to pull in a global cacheline). > The real issue is metadata. The transaction log I/O completion > funnels through a state machine protected by a single lock, which > means completions on different CPUs pulls that lock to all > completion CPUs. Given that the same lock is used during transaction > completion for other state transitions (in task context, not intr), > the more cpus active at once touches, the worse the problem gets. OK, once you add locking (and not simply cacheline contention), then the problem gets harder I agree. But I think that if the submitting side takes the same locks as log completion (eg. maybe for starting a new transaction), then it is not going to be a clear win either way, and you'd have to measure it in the end. -- 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/
Re: [PATCH 1/2] kmemcheck v3
Hi Christoph, On Thu, 7 Feb 2008, Vegard Nossum wrote: > > - DMA can be a problem since there's generally no way for kmemcheck to > > determine when/if a chunk of memory is used for DMA. Ideally, DMA should > > be > > allocated with untracked caches, but this requires annotation of the > > drivers in question. On Feb 8, 2008 9:10 AM, Christoph Lameter <[EMAIL PROTECTED]> wrote: > There is a fundamental misunderstanding here: GFP_DMA allocations have > nothing to do with DMA. Rather GFP_DMA means allocate memory in a special > range of physical memory that is required by legacy devices that cannot > use the high address bits for one or the other reason. Any regular > memory can be used for DMA. No there isn't and we've been over this with Vegard many times :-). Christoph, can you actually see this in the patch? There shouldn't be any __GFP_DMA confusion there. What we have is per-object __GFP_NOTRACK which can be used to suppress false positives for DMA-filled objects and SLAB_NOTRACK for whole _caches_ that contains objects which we must not take page faults at all. -- 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/
Re: IO queuing and complete affinity with threads (was Re: [PATCH 0/8] IO queuing and complete affinity)
On Fri, Feb 08 2008, Nick Piggin wrote: > On Thu, Feb 07, 2008 at 07:25:45PM +0100, Jens Axboe wrote: > > Hi, > > > > Here's a variant using kernel threads only, the nasty arch bits are then > > not needed. Works for me, no performance testing (that's a hint for Alan > > to try and queue up some testing for this variant as well :-) > > Well this stuff looks pretty nice (although I'm not sure whether the > softirq->thread changes are a good idea for performance, I guess we'll > see). Yeah, that is indeed an open question and why I have two seperate patches for now (io-cpu-affinity branch and io-cpu-affinity-kthread branch). As Ingo mentioned, this is how softirqs are handled in the -rt branch already. > You still don't have the option that the Intel patch gave, that is, > to submit on the completer. I guess that you could do it somewhat > generically by having a cpuid in the request queue, and update that > with the completing cpu. Not sure what you mean, if setting queue_affinity doesn't accomplish it. If you know the completing CPU to begin with, surely you can just set the queuing affinity appropriately? > At least they reported it to be the most efficient scheme in their > testing, and Dave thought that migrating completions out to submitters > might be a bottleneck in some cases. More so than migrating submitters to completers? The advantage of only movign submitters is that you get rid of the completion locking. Apart from that, the cost should be the same, especially for the thread based solution. -- Jens Axboe -- 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/
Re: [rft] s2ram wakeup moves to .c, could fix few machines
Pavel Machek wrote: Hi! I really need the entry point to be at offset 0, so that I can get pointers to my data. I could not figure out how to do it any other way. And if 0 is taken, I thought I'd put header at the end. Why not just put the structure at 0, and put pointers in the structure to everything else you need? segments:offsets rear its ugly head here. I need %ds to point to my data, and the way to do it is copy it from %cs; that needs start to be at 0. If you can find a solution that does not need this (some segment/offset arithmetics at beggining of wakeup?) we could use it, but I was lost between relocations. Let me look at it in the morning. Got a specific pointer? -hpa -- 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/
Re: [PATCH 2/5] Provide acpi_check_{mem_}region.
On Wed, 24 Oct 2007 16:32:59 +0200 Thomas Renninger <[EMAIL PROTECTED]> wrote:
> Provide acpi_check_{mem_}region.
>
> Drivers can additionally check against possible ACPI interference by also
> invoking this shortly before they call request_region.
> If -EBUSY is returned, the driver must not load.
> Use acpi_enforce_resources=strict/lax/no options to:
> - strict: let conflicting drivers fail to load with an error message
> - lax:let conflicting driver work normal with a warning message
> - no: no functional change at all
>
>
OK, so Len has merged these into the acpi test tree. My understanding is
that once this work hits mainline, we can then merge
check-for-acpi-resource-conflicts-in-hwmon-drivers.patch.
My normal approach would be to send
check-for-acpi-resource-conflicts-in-hwmon-drivers.patch to Mark for
inclusion in git-hwmon one Len has merged the prerequisites into mainline.
Problem is, if Len merges late in the 2.6.26 merge window, Mark might not
have time to gets these changes into mainline before 2.6.27. Which is all
getting a bit dumb considering I first merged everything in October.
Fortunately things aren't mormally _this_ inefficient when one follows the
rules - this was an unusual patchset.
But still, I think we could afford to speed things up a bit more than that.
We could ask Len to consider merging this work into 2.6.25 and then if
Mark can ack check-for-acpi-resource-conflicts-in-hwmon-drivers.patch
(below) for an akpm-merge, we're good to go. But I do recall that people
were a bit uncertain about it all back in October.
Please share your thoughts with us.
From: Jean Delvare <[EMAIL PROTECTED]>
Check for ACPI resource conflicts in hwmon drivers. I've included
all Super-I/O and PCI drivers.
I've voluntarily left out:
* Laptop specific and vendor-specific drivers: if they conflicted
on any system, this would pretty much mean that they conflict on all
systems, and we would know by now.
* Legacy ISA drivers (lm78 and w83781d): they only support chips found
on old designs were ACPI either wasn't supported or didn't deal with
thermal management.
* Drivers accessing the I/O resources indirectly (e.g. through SMBus):
the check will be added where it belongs, i.e. in the bus drivers.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Thomas Renninger <[EMAIL PROTECTED]>
Cc: "Mark M. Hoffman" <[EMAIL PROTECTED]>
Cc: Len Brown <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/hwmon/dme1737.c|5 +
drivers/hwmon/f71805f.c|5 +
drivers/hwmon/f71882fg.c |5 +
drivers/hwmon/it87.c |5 +
drivers/hwmon/pc87360.c|6 ++
drivers/hwmon/pc87427.c|5 +
drivers/hwmon/sis5595.c|5 +
drivers/hwmon/smsc47b397.c |5 +
drivers/hwmon/smsc47m1.c |5 +
drivers/hwmon/via686a.c|5 +
drivers/hwmon/vt1211.c |5 +
drivers/hwmon/vt8231.c |5 +
drivers/hwmon/w83627ehf.c |6 ++
drivers/hwmon/w83627hf.c |5 +
14 files changed, 72 insertions(+)
diff -puN
drivers/hwmon/dme1737.c~check-for-acpi-resource-conflicts-in-hwmon-drivers
drivers/hwmon/dme1737.c
--- a/drivers/hwmon/dme1737.c~check-for-acpi-resource-conflicts-in-hwmon-drivers
+++ a/drivers/hwmon/dme1737.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
/* ISA device, if found */
@@ -2238,6 +2239,10 @@ static int __init dme1737_isa_device_add
};
int err;
+ err = acpi_check_resource_conflict();
+ if (err)
+ goto exit;
+
if (!(pdev = platform_device_alloc("dme1737", addr))) {
printk(KERN_ERR "dme1737: Failed to allocate device.\n");
err = -ENOMEM;
diff -puN
drivers/hwmon/f71805f.c~check-for-acpi-resource-conflicts-in-hwmon-drivers
drivers/hwmon/f71805f.c
--- a/drivers/hwmon/f71805f.c~check-for-acpi-resource-conflicts-in-hwmon-drivers
+++ a/drivers/hwmon/f71805f.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
static unsigned short force_id;
@@ -1455,6 +1456,10 @@ static int __init f71805f_device_add(uns
}
res.name = pdev->name;
+ err = acpi_check_resource_conflict();
+ if (err)
+ goto exit_device_put;
+
err = platform_device_add_resources(pdev, , 1);
if (err) {
printk(KERN_ERR DRVNAME ": Device resource addition failed "
diff -puN
drivers/hwmon/f71882fg.c~check-for-acpi-resource-conflicts-in-hwmon-drivers
drivers/hwmon/f71882fg.c
---
a/drivers/hwmon/f71882fg.c~check-for-acpi-resource-conflicts-in-hwmon-drivers
+++ a/drivers/hwmon/f71882fg.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#define DRVNAME "f71882fg"
@@ -898,6 +899,10 @@ static int __init f71882fg_device_add(un
return -ENOMEM;
res.name = f71882fg_pdev->name;
+ err =
Re: IO queuing and complete affinity with threads (was Re: [PATCH 0/8] IO queuing and complete affinity)
On Thu, Feb 07, 2008 at 07:25:45PM +0100, Jens Axboe wrote: > Hi, > > Here's a variant using kernel threads only, the nasty arch bits are then > not needed. Works for me, no performance testing (that's a hint for Alan > to try and queue up some testing for this variant as well :-) Well this stuff looks pretty nice (although I'm not sure whether the softirq->thread changes are a good idea for performance, I guess we'll see). You still don't have the option that the Intel patch gave, that is, to submit on the completer. I guess that you could do it somewhat generically by having a cpuid in the request queue, and update that with the completing cpu. At least they reported it to be the most efficient scheme in their testing, and Dave thought that migrating completions out to submitters might be a bottleneck in some cases. -- 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/
Re: [GIT PULL] LED updates
Richard Purdie wrote: > On Thu, 2008-02-07 at 19:38 -0200, Henrique de Moraes Holschuh wrote: >> On Thu, 07 Feb 2008, Richard Purdie wrote: >>> Márton Németh: >>> leds: Add support for hardware accelerated LED flashing >>> leds: hw acceleration for Clevo mail LED driver >> This one has a loose end: when you call brightness_set on a led with >> hardware flash acceleration, you will leave the trigger armed, BUT the led >> won't blink anymore. That's just wrong. > > Agreed. My only question is that do you know any LED hardware which can blink _and_ can set the brightness independently? If there would be such a LED I could imagine that the brightness can be changed while the LED remains blinking at some low frequency. For example a simple LED with brightness set possibility and blinking directed by software is an example where the blinking and the brightness setting are completely independent. I agree, however, that if the brightness is set to LED_OFF, the trigger should be also removed. >> Either we should always remove *any* (hardware accelerated or not!) active >> trigger when a write to brightness_set is done, or the stuff about "calling >> brightness_set will disable the hardware accelerated blink" has to go. >> >> I personally prefer that we would always remove any active trigger if >> brightness_set is to be called. IMHO, it is neater, and it is also the >> least-surprise-behaviour from an user perspective with the LED_OFF:LED_FULL >> triggers we have right now. > > Even without the hardware acceleration, a user write to set_brightness > leaves any active trigger active and isn't really intuitive or right > either. > >> Which one will be? If it is "remove any active trigger", I'd not mind >> writing the patch. -- 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/
Re: [git pull] more SLUB updates for 2.6.25
Nick Piggin a écrit : On Friday 08 February 2008 13:13, Christoph Lameter wrote: are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/christoph/vm.git slub-linus (includes the cmpxchg_local fastpath since the cmpxchg_local work by Matheiu is in now, and the non atomic unlock by Nick. Verified that this is not doing any harm after some other patches had been removed. Ah, good. I think it is always a good thing to be able to remove atomics. They place quite a bit of burden on the CPU, especially x86 where it also has implicit memory ordering semantics (although x86 can speculatively get around much of the problem, it's obviously worse than no restriction) Even if perhaps some cache coherency or timing quirk makes the non-atomic version slower (all else being equal), then I'd still say that the non atomic version should be preferred. What about IRQ masking then ? Many CPU pay high cost for cli/sti pair... And SLAB/SLUB allocators, even if only used from process context, want to disable/re-enable interrupts... I understand kmalloc() want generic pools, but dedicated pools could avoid this cli/sti -- 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/
Re: [RFT 1/1] single_chip test
On Thu, Feb 07, 2008 at 22:51:04 +0100, Jiri Slaby wrote: [...] > What's the srev a phy ver printed few lines above this, please? ath5k_pci :02:00.0: registered as 'phy0' SINGLE: 1, srev: a3, phy: phy0: Selected rate control algorithm 'pid' ath5k phy0: Atheros AR5424 chip found (MAC: 0xa3, PHY: 0x61) Regards, Tino -- 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/
Re: [git pull] more SLUB updates for 2.6.25
On Friday 08 February 2008 13:13, Christoph Lameter wrote: > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/christoph/vm.git slub-linus > > (includes the cmpxchg_local fastpath since the cmpxchg_local work > by Matheiu is in now, and the non atomic unlock by Nick. Verified that > this is not doing any harm after some other patches had been removed. Ah, good. I think it is always a good thing to be able to remove atomics. They place quite a bit of burden on the CPU, especially x86 where it also has implicit memory ordering semantics (although x86 can speculatively get around much of the problem, it's obviously worse than no restriction) Even if perhaps some cache coherency or timing quirk makes the non-atomic version slower (all else being equal), then I'd still say that the non atomic version should be preferred. Thanks, Nick -- 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/
Re: [PATCH 1/2] kmemcheck v3
On Thu, 7 Feb 2008, Vegard Nossum wrote: > - DMA can be a problem since there's generally no way for kmemcheck to > determine when/if a chunk of memory is used for DMA. Ideally, DMA should be > allocated with untracked caches, but this requires annotation of the > drivers in question. There is a fundamental misunderstanding here: GFP_DMA allocations have nothing to do with DMA. Rather GFP_DMA means allocate memory in a special range of physical memory that is required by legacy devices that cannot use the high address bits for one or the other reason. Any regular memory can be used for DMA. Could you refactor the patch a bit? This is quite a big patch. -- 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/
Re: 2.6.24 says "serial8250: too much work for irq4" a lot.
On Thursday 07 February 2008 15:19:39 H. Peter Anvin wrote: > Rob Landley wrote: > > Specifically, qemu isn't paravirtualized, it's fully virtualized. The > > same kernel can run on real hardware just fine. (Sort of the point of > > the project...) > > > > I can yank the warning for the kernels I build (or set PASS_LIMIT to > > 999), but I'd rather not carry any more patches than I can avoid... > > Patch attached, completely untested beyond compilation. > > In particular: > > - we should probably clear the burst counter when the interrupt > line goes from inactive to active. > - there probably should be a timer which clears the burst > counter. > > However, I think I've covered most of the bases... Well, qemu still seems to work with the patch applied, and I haven't reproduced the error message yet... Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. -- 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/
Re: [rft] s2ram wakeup moves to .c, could fix few machines
Hi! > >I really need the entry point to be at offset 0, so > >that I can get > >pointers to my data. I could not figure out how to do > >it any other > >way. And if 0 is taken, I thought I'd put header at the > >end. > > > > Why not just put the structure at 0, and put pointers in > the structure to everything else you need? segments:offsets rear its ugly head here. I need %ds to point to my data, and the way to do it is copy it from %cs; that needs start to be at 0. If you can find a solution that does not need this (some segment/offset arithmetics at beggining of wakeup?) we could use it, but I was lost between relocations. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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/
Re: ACPI_WMI: worst config description of all times
Hi! > On Friday 08 February 2008 00:12:24 Ray Lee wrote: > > While I'm not trying to set you up for a firing squad, if you can show > > that the only use this driver has is as underlying support for Acer/HP > > xyz drivers, > > Certainly at the moment, this is the only real use it has (and the only > reason > I spent any time working on a generic ACPI-WMI driver - probably one of the > reasons Kconfig is somewhat neglected - ACPI-WMI is a means to an end for me > (getting my laptop properly supported by another driver on top of it), not > the end itself). > > Although, given most of the other laptop drivers in drivers/misc use 'select' > for various things, I don't see the harm here - unless anyone else has a > great objection to acer-wmi and tc1100-wmi having 'select ACPI_WMI'? I believe selct is the way to go here. What do acer-wmi handle? Additional buttons? Leds? Temperatures? Fan states? The laptops will boot fine without it, right? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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/
[PATCH] mxser: convert large macros to functions
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/char/mxser.c
===
--- linux-2.6.orig/drivers/char/mxser.c 2008-02-08 07:07:55.0 +0100
+++ linux-2.6/drivers/char/mxser.c 2008-02-08 07:42:32.0 +0100
@@ -307,6 +307,200 @@ static unsigned char mxser_msr[MXSER_POR
static struct mxser_mon_ext mon_data_ext;
static int mxser_set_baud_method[MXSER_PORTS + 1];
+static void mxser_enable_must_enchance_mode(unsigned long baseio)
+{
+ u8 oldlcr;
+ u8 efr;
+
+ oldlcr = inb(baseio + UART_LCR);
+ outb(MOXA_MUST_ENTER_ENCHANCE, baseio + UART_LCR);
+
+ efr = inb(baseio + MOXA_MUST_EFR_REGISTER);
+ efr |= MOXA_MUST_EFR_EFRB_ENABLE;
+
+ outb(efr, baseio + MOXA_MUST_EFR_REGISTER);
+ outb(oldlcr, baseio + UART_LCR);
+}
+
+static void mxser_disable_must_enchance_mode(unsigned long baseio)
+{
+ u8 oldlcr;
+ u8 efr;
+
+ oldlcr = inb(baseio + UART_LCR);
+ outb(MOXA_MUST_ENTER_ENCHANCE, baseio + UART_LCR);
+
+ efr = inb(baseio + MOXA_MUST_EFR_REGISTER);
+ efr &= ~MOXA_MUST_EFR_EFRB_ENABLE;
+
+ outb(efr, baseio + MOXA_MUST_EFR_REGISTER);
+ outb(oldlcr, baseio + UART_LCR);
+}
+
+static void mxser_set_must_xon1_value(unsigned long baseio, u8 value)
+{
+ u8 oldlcr;
+ u8 efr;
+
+ oldlcr = inb(baseio + UART_LCR);
+ outb(MOXA_MUST_ENTER_ENCHANCE, baseio + UART_LCR);
+
+ efr = inb(baseio + MOXA_MUST_EFR_REGISTER);
+ efr &= ~MOXA_MUST_EFR_BANK_MASK;
+ efr |= MOXA_MUST_EFR_BANK0;
+
+ outb(efr, baseio + MOXA_MUST_EFR_REGISTER);
+ outb(value, baseio + MOXA_MUST_XON1_REGISTER);
+ outb(oldlcr, baseio + UART_LCR);
+}
+
+static void mxser_set_must_xoff1_value(unsigned long baseio, u8 value)
+{
+ u8 oldlcr;
+ u8 efr;
+
+ oldlcr = inb(baseio + UART_LCR);
+ outb(MOXA_MUST_ENTER_ENCHANCE, baseio + UART_LCR);
+
+ efr = inb(baseio + MOXA_MUST_EFR_REGISTER);
+ efr &= ~MOXA_MUST_EFR_BANK_MASK;
+ efr |= MOXA_MUST_EFR_BANK0;
+
+ outb(efr, baseio + MOXA_MUST_EFR_REGISTER);
+ outb(value, baseio + MOXA_MUST_XOFF1_REGISTER);
+ outb(oldlcr, baseio + UART_LCR);
+}
+
+static void mxser_set_must_fifo_value(struct mxser_port *info)
+{
+ u8 oldlcr;
+ u8 efr;
+
+ oldlcr = inb(info->ioaddr + UART_LCR);
+ outb(MOXA_MUST_ENTER_ENCHANCE, info->ioaddr + UART_LCR);
+
+ efr = inb(info->ioaddr + MOXA_MUST_EFR_REGISTER);
+ efr &= ~MOXA_MUST_EFR_BANK_MASK;
+ efr |= MOXA_MUST_EFR_BANK1;
+
+ outb(efr, info->ioaddr + MOXA_MUST_EFR_REGISTER);
+ outb((u8)info->rx_high_water, info->ioaddr + MOXA_MUST_RBRTH_REGISTER);
+ outb((u8)info->rx_trigger, info->ioaddr + MOXA_MUST_RBRTI_REGISTER);
+ outb((u8)info->rx_low_water, info->ioaddr + MOXA_MUST_RBRTL_REGISTER);
+ outb(oldlcr, info->ioaddr + UART_LCR);
+}
+
+static void mxser_set_must_enum_value(unsigned long baseio, u8 value)
+{
+ u8 oldlcr;
+ u8 efr;
+
+ oldlcr = inb(baseio + UART_LCR);
+ outb(MOXA_MUST_ENTER_ENCHANCE, baseio + UART_LCR);
+
+ efr = inb(baseio + MOXA_MUST_EFR_REGISTER);
+ efr &= ~MOXA_MUST_EFR_BANK_MASK;
+ efr |= MOXA_MUST_EFR_BANK2;
+
+ outb(efr, baseio + MOXA_MUST_EFR_REGISTER);
+ outb(value, baseio + MOXA_MUST_ENUM_REGISTER);
+ outb(oldlcr, baseio + UART_LCR);
+}
+
+static void mxser_get_must_hardware_id(unsigned long baseio, u8 *pId)
+{
+ u8 oldlcr;
+ u8 efr;
+
+ oldlcr = inb(baseio + UART_LCR);
+ outb(MOXA_MUST_ENTER_ENCHANCE, baseio + UART_LCR);
+
+ efr = inb(baseio + MOXA_MUST_EFR_REGISTER);
+ efr &= ~MOXA_MUST_EFR_BANK_MASK;
+ efr |= MOXA_MUST_EFR_BANK2;
+
+ outb(efr, baseio + MOXA_MUST_EFR_REGISTER);
+ *pId = inb(baseio + MOXA_MUST_HWID_REGISTER);
+ outb(oldlcr, baseio + UART_LCR);
+}
+
+static void SET_MOXA_MUST_NO_SOFTWARE_FLOW_CONTROL(unsigned long baseio)
+{
+ u8 oldlcr;
+ u8 efr;
+
+ oldlcr = inb(baseio + UART_LCR);
+ outb(MOXA_MUST_ENTER_ENCHANCE, baseio + UART_LCR);
+
+ efr = inb(baseio + MOXA_MUST_EFR_REGISTER);
+ efr &= ~MOXA_MUST_EFR_SF_MASK;
+
+ outb(efr, baseio + MOXA_MUST_EFR_REGISTER);
+ outb(oldlcr, baseio + UART_LCR);
+}
+
+static void mxser_enable_must_tx_software_flow_control(unsigned long baseio)
+{
+ u8 oldlcr;
+ u8 efr;
+
+ oldlcr = inb(baseio + UART_LCR);
+ outb(MOXA_MUST_ENTER_ENCHANCE, baseio + UART_LCR);
+
+ efr = inb(baseio + MOXA_MUST_EFR_REGISTER);
+ efr &= ~MOXA_MUST_EFR_SF_TX_MASK;
+ efr |= MOXA_MUST_EFR_SF_TX1;
+
+ outb(efr, baseio + MOXA_MUST_EFR_REGISTER);
+ outb(oldlcr, baseio + UART_LCR);
+}
+
+static void mxser_disable_must_tx_software_flow_control(unsigned long baseio)
+{
+ u8 oldlcr;
+ u8 efr;
+
+ oldlcr = inb(baseio + UART_LCR);
+
Re: UBI: add mtd_num sysfs attribute
Greg KH wrote: On Thu, Feb 07, 2008 at 07:07:40PM +, Linux Kernel Mailing List wrote: Gitweb: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b6b76ba466bbd47397efad0fdaeaa5ebf7d462c7 Commit: b6b76ba466bbd47397efad0fdaeaa5ebf7d462c7 Parent: d1f3dd6cc00f5bf744118fb2820ecdf09a1f4b73 Author: Artem Bityutskiy <[EMAIL PROTECTED]> AuthorDate: Wed Dec 26 13:46:46 2007 +0200 Committer: Artem Bityutskiy <[EMAIL PROTECTED]> CommitDate: Wed Dec 26 19:15:17 2007 +0200 UBI: add mtd_num sysfs attribute Expose number or the underlying MTD device in sysfs. Can you please add this information to Documentation/ABI/ so that people know what is going on here? Sure, will do. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- 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/
[GIT PATCH] ACPI patches for 2.6.25-rc0 (#2)
Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release Nothing exciting here, generally just tweaks to the previous batch. This will update the files shown below. thanks! -Len ps. individual patches are available on [EMAIL PROTECTED] and a consolidated plain patch is available here: ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.24/acpi-release-20070126-2.6.24.diff.gz Documentation/thermal/sysfs-api.txt | 23 +-- drivers/acpi/Kconfig| 20 +++-- drivers/acpi/blacklist.c| 20 + drivers/acpi/osl.c |2 drivers/acpi/processor_perflib.c|7 +++ drivers/misc/Kconfig|5 +- drivers/thermal/Kconfig |4 - drivers/thermal/thermal.c | 49 +--- 8 files changed, 88 insertions(+), 42 deletions(-) through these commits: Carlos Corbacho (1): ACPI: WMI: Improve Kconfig description Len Brown (6): ACPI: add newline to printk ACPI: build WMI on X86 only intel_menlo: build on X86 only ACPI: thermal: syntax, spelling, kernel-doc ACPI: DMI: add Panasonic CF-52 and Thinpad X61 acer-wmi, tc1100-wmi: select ACPI_WMI Thomas Renninger (1): ACPI: cpufreq: Print _PPC changes via cpufreq debug layer with this log: commit 2e6c4e5101633a54aeee1f2e83020ee77fcb70d2 Merge: 446b1df... 4a507d9... Author: Len Brown <[EMAIL PROTECTED]> Date: Fri Feb 8 01:22:26 2008 -0500 Merge branches 'release', 'dmi' and 'misc' into release commit 4a507d93fac78ecd37d18343c57c564f6a126f01 Author: Len Brown <[EMAIL PROTECTED]> Date: Fri Feb 8 00:37:16 2008 -0500 acer-wmi, tc1100-wmi: select ACPI_WMI It is safe for these Kconfig entries to use select because they select ACPI_WMI, which already has its dependencies satisfied. This makes Kconfig more user friendly, since the user selects the driver they want and the dependency is met for them. Otherwise, the user would have to find and enable ACPI_WMI to make enabling these drivers possible. Signed-off-by: Len Brown <[EMAIL PROTECTED]> commit 20b4514799ebcfb04b45537e90e421cb73fd0cc9 Author: Carlos Corbacho <[EMAIL PROTECTED]> Date: Fri Feb 8 00:36:49 2008 -0500 ACPI: WMI: Improve Kconfig description As Pavel Machek has pointed out, the Kconfig entry for WMI is pretty non-descriptive. Rewrite it so that it explains what ACPI-WMI is, and why anyone would want to enable it. Many thanks to Ray Lee for ideas on this. Signed-off-by: Carlos Corbacho <[EMAIL PROTECTED]> CC: Pavel Machek <[EMAIL PROTECTED]> CC: Ray Lee <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> commit 446b1dfc4cd1c2bbc7eb22d5fec38e23a577492c Author: Len Brown <[EMAIL PROTECTED]> Date: Thu Feb 7 16:23:00 2008 -0500 ACPI: DMI: add Panasonic CF-52 and Thinpad X61 Add Lenovo X61 Add Panasonic Toughbook CF-52 Signed-off-by: Len Brown <[EMAIL PROTECTED]> commit 543a956140e1f57331c0e528d2367106057aeca0 Author: Len Brown <[EMAIL PROTECTED]> Date: Thu Feb 7 16:55:08 2008 -0500 ACPI: thermal: syntax, spelling, kernel-doc Reviewed-by: Randy Dunlap <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> commit 9f2eef25e044603527e121066284d22f51d853cc Author: Len Brown <[EMAIL PROTECTED]> Date: Thu Feb 7 16:19:56 2008 -0500 intel_menlo: build on X86 only Signed-off-by: Len Brown <[EMAIL PROTECTED]> commit 9c2f7de8c0f979fc6354bf0d22c0cdcc29722bf6 Author: Len Brown <[EMAIL PROTECTED]> Date: Thu Feb 7 16:18:24 2008 -0500 ACPI: build WMI on X86 only Signed-off-by: Len Brown <[EMAIL PROTECTED]> commit 919158d17b42683a5c7368e1e77661c65a20a48a Author: Thomas Renninger <[EMAIL PROTECTED]> Date: Wed Oct 31 15:41:42 2007 +0100 ACPI: cpufreq: Print _PPC changes via cpufreq debug layer enabled with CPU_FREQ_DEBUG Signed-off-by: Thomas Renninger <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> commit b0b23e0ade6aa265d7278e06d50bc10ec81dd174 Author: Len Brown <[EMAIL PROTECTED]> Date: Thu Feb 7 14:42:25 2008 -0500 ACPI: add newline to printk Signed-off-by: Len Brown <[EMAIL PROTECTED]> -- 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/
Re: [PATCH 1/2] kmemcheck v3
On Feb 8, 2008 1:32 AM, Christoph Lameter <[EMAIL PROTECTED]> wrote: > But the slab layer allocates pages < PAGE_SIZE. You need to take a fault > right? So each object would need its own page? No. We allocate a shadow page for each data page which we then use as a per-byte "bitmap." For every tracked _page_ we take the page fault always. -- 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/
Re: [PATCH 1/2] kmemcheck v3
Pekka Enberg wrote: No. We need to not track the whole page to avoid recursive faults. So for kmemcheck we absolutely do need cache_cache but we can, of course, hide that under a alloc_cache() function that only uses the extra cache when CONFIG_KMEMCHECK is enabled? Btw, one option is to have a new _page flag_ so that we no longer need to look inside struct kmem_cache in the page fault handler. Pekka -- 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/
Re: [PATCH 1/2] kmemcheck v3
Hi Christoph, Christoph Lameter wrote: SLABs can be excepted from tracking? Yes. __GFP_NOTRACK can be used to suppress tracking of objects (but we still take the page fault for each access). That is required for things like DMA filled pages that are never initialized by the CPU. SLAB_NOTRACK is for not tracking a whole *cache* so that we _don't_ take the page fault. This is needed for kmemcheck implementation (to avoid recursive page faults for memory accessed by the page fault handler). So it breaks recursion. But this adds a new cache that is rarely used. There will be only about 50-100 kmem_cache objects in the system. I thought you could control the tracking on an per object level? Would not a kmalloc with __GFP_NOTRACK work? No. We need to not track the whole page to avoid recursive faults. So for kmemcheck we absolutely do need cache_cache but we can, of course, hide that under a alloc_cache() function that only uses the extra cache when CONFIG_KMEMCHECK is enabled? -- 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/
[PATCH] ide-cd: replace ntohs with generic byteorder macro be16_to_cpu
commit d41c6bc739e7ea7880f7f5983a9694f2e0214d92
Author: Borislav Petkov <[EMAIL PROTECTED]>
Date: Fri Feb 8 07:25:44 2008 +0100
ide-cd: replace ntohs with generic byteorder macro be16_to_cpu
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index 5e42c19..354c91d 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -1555,7 +1555,7 @@ int ide_cd_read_toc(ide_drive_t *drive, struct
request_sense *sense)
if (stat)
return stat;
- toc->hdr.toc_length = ntohs (toc->hdr.toc_length);
+ toc->hdr.toc_length = be16_to_cpu(toc->hdr.toc_length);
if (info->cd_flags & IDE_CD_FLAG_TOCTRACKS_AS_BCD) {
toc->hdr.first_track = BCD2BIN(toc->hdr.first_track);
--
Regards/Gruß,
Boris.
--
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/
Re: [PATCH] isdn: fix section mismatch warning in enpci_card_msg
From: Sam Ravnborg <[EMAIL PROTECTED]> Date: Fri, 8 Feb 2008 06:58:33 +0100 > Hi David - did you apply only this > or all 5 patches? > I can resend if you prefer with Karsten's ack included. Only this one, I don't have the others so feel free to send thos. > PS. Do you usual take isdn patches? Lately that has been the case. -- 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/
Re: [PATCH] isdn: fix section mismatch warning in enpci_card_msg
On Thu, Feb 07, 2008 at 06:20:40PM -0800, David Miller wrote: > From: Sam Ravnborg <[EMAIL PROTECTED]> > Date: Fri, 1 Feb 2008 14:42:42 +0100 > > > Fix following warnings: > > WARNING: drivers/isdn/hisax/built-in.o(.text+0x3cf50): Section mismatch in > > reference from the function enpci_card_msg() to the function > > .devinit.text:Amd7930_init() > > WARNING: drivers/isdn/hisax/built-in.o(.text+0x3cf85): Section mismatch in > > reference from the function enpci_card_msg() to the function > > .devinit.text:Amd7930_init() > > > > enpci_card_msg() can be called outside __devinit context > > referenced function should not be annotated __devinit. > > > > Remove annotation of Amd7930_init to fix this. > > > > Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> > > Applied, thanks. Hi David - did you apply only this or all 5 patches? I can resend if you prefer with Karsten's ack included. PS. Do you usual take isdn patches? Sam -- 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/
Re: UBI: add mtd_num sysfs attribute
On Thu, Feb 07, 2008 at 07:07:40PM +, Linux Kernel Mailing List wrote: > Gitweb: > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b6b76ba466bbd47397efad0fdaeaa5ebf7d462c7 > Commit: b6b76ba466bbd47397efad0fdaeaa5ebf7d462c7 > Parent: d1f3dd6cc00f5bf744118fb2820ecdf09a1f4b73 > Author: Artem Bityutskiy <[EMAIL PROTECTED]> > AuthorDate: Wed Dec 26 13:46:46 2007 +0200 > Committer: Artem Bityutskiy <[EMAIL PROTECTED]> > CommitDate: Wed Dec 26 19:15:17 2007 +0200 > > UBI: add mtd_num sysfs attribute > > Expose number or the underlying MTD device in sysfs. Can you please add this information to Documentation/ABI/ so that people know what is going on here? thanks, greg k-h -- 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/
Re: ACPI_WMI: worst config description of all times
On Thursday 07 February 2008 21:02, Carlos Corbacho wrote: > On Friday 08 February 2008 01:38:01 Ray Lee wrote: > > That's clear to me (whereas the original wasn't), though I would > > still argue for this driver being select'ed by the drivers that > > require it. As you note, other laptop specific drivers do so, and > > Linus has come down in favor of that as well in the past, so you have > > a friend in high places :-). > > I have some other patches lined up to do so. Unless I hear some arguments > against it, or some better alternatives, I'll put them together with this > and get Len to apply them to the ACPI tree (and then hopefully push back > out before the -rc1 release). done. cheers, -Len >From 4a507d93fac78ecd37d18343c57c564f6a126f01 Mon Sep 17 00:00:00 2001 From: Len Brown <[EMAIL PROTECTED]> Date: Fri, 8 Feb 2008 00:37:16 -0500 Subject: [PATCH] acer-wmi, tc1100-wmi: select ACPI_WMI Organization: Intel Open Source Technology Center It is safe for these Kconfig entries to use select because they select ACPI_WMI, which already has its dependencies satisfied. This makes Kconfig more user friendly, since the user selects the driver they want and the dependency is met for them. Otherwise, the user would have to find and enable ACPI_WMI to make enabling these drivers possible. Signed-off-by: Len Brown <[EMAIL PROTECTED]> --- drivers/misc/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 218c65a..e19343e 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -97,9 +97,9 @@ config ACER_WMI depends on X86 depends on EXPERIMENTAL depends on ACPI - depends on ACPI_WMI depends on LEDS_CLASS depends on BACKLIGHT_CLASS_DEVICE + select ACPI_WMI ---help--- This is a driver for newer Acer (and Wistron) laptops. It adds wireless radio and bluetooth control, and on some laptops, @@ -146,7 +146,7 @@ config TC1100_WMI tristate "HP Compaq TC1100 Tablet WMI Extras" depends on X86 && !X86_64 depends on ACPI - depends on ACPI_WMI + select ACPI_WMI ---help--- This is a driver for the WMI extensions (wireless and bluetooth power control) of the HP Compaq TC1100 tablet. -- 1.5.4.34.g053d9 -- 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/
Re: [PATCH] Add IPv6 support to TCP SYN cookies
Updated to incorporate Eric's suggestion of using a per cpu buffer
rather than allocating on the stack. Just a two line change, but will
resend in it's entirety.
Signed-off-by: Glenn Griffin <[EMAIL PROTECTED]>
---
include/net/tcp.h|8 ++
net/ipv4/syncookies.c|7 +-
net/ipv4/tcp_input.c |1 +
net/ipv4/tcp_minisocks.c |2 +
net/ipv4/tcp_output.c|1 +
net/ipv6/Makefile|1 +
net/ipv6/syncookies.c| 267 ++
net/ipv6/tcp_ipv6.c | 77 ++
8 files changed, 338 insertions(+), 26 deletions(-)
create mode 100644 net/ipv6/syncookies.c
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 7de4ea3..c428ec7 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
@@ -434,11 +435,17 @@ extern inttcp_disconnect(struct
sock *sk, int flags);
extern voidtcp_unhash(struct sock *sk);
/* From syncookies.c */
+extern __u32 syncookie_secret[2][16-3+SHA_DIGEST_WORDS];
extern struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb,
struct ip_options *opt);
extern __u32 cookie_v4_init_sequence(struct sock *sk, struct sk_buff *skb,
__u16 *mss);
+/* From net/ipv6/syncookies.c */
+extern struct sock *cookie_v6_check(struct sock *sk, struct sk_buff *skb);
+extern __u32 cookie_v6_init_sequence(struct sock *sk, struct sk_buff *skb,
+__u16 *mss);
+
/* tcp_output.c */
extern void __tcp_push_pending_frames(struct sock *sk, unsigned int cur_mss,
@@ -1332,6 +1339,7 @@ extern int tcp_proc_register(struct tcp_seq_afinfo
*afinfo);
extern void tcp_proc_unregister(struct tcp_seq_afinfo *afinfo);
extern struct request_sock_ops tcp_request_sock_ops;
+extern struct request_sock_ops tcp6_request_sock_ops;
extern int tcp_v4_destroy_sock(struct sock *sk);
diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c
index f470fe4..cc6637b 100644
--- a/net/ipv4/syncookies.c
+++ b/net/ipv4/syncookies.c
@@ -10,8 +10,6 @@
* 2 of the License, or (at your option) any later version.
*
* $Id: syncookies.c,v 1.18 2002/02/01 22:01:04 davem Exp $
- *
- * Missing: IPv6 support.
*/
#include
@@ -23,14 +21,15 @@
extern int sysctl_tcp_syncookies;
-static __u32 syncookie_secret[2][16-3+SHA_DIGEST_WORDS];
+__u32 syncookie_secret[2][16-3+SHA_DIGEST_WORDS];
+EXPORT_SYMBOL(syncookie_secret);
static __init int init_syncookies(void)
{
get_random_bytes(syncookie_secret, sizeof(syncookie_secret));
return 0;
}
-module_init(init_syncookies);
+__initcall(init_syncookies);
#define COOKIEBITS 24 /* Upper bits store count */
#define COOKIEMASK (((__u32)1 << COOKIEBITS) - 1)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 19c449f..93e128c 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5326,6 +5326,7 @@ discard:
EXPORT_SYMBOL(sysctl_tcp_ecn);
EXPORT_SYMBOL(sysctl_tcp_reordering);
+EXPORT_SYMBOL(sysctl_tcp_adv_win_scale);
EXPORT_SYMBOL(tcp_parse_options);
EXPORT_SYMBOL(tcp_rcv_established);
EXPORT_SYMBOL(tcp_rcv_state_process);
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index b61b768..0f494cd 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -35,6 +35,8 @@
#endif
int sysctl_tcp_syncookies __read_mostly = SYNC_INIT;
+EXPORT_SYMBOL(sysctl_tcp_syncookies);
+
int sysctl_tcp_abort_on_overflow __read_mostly;
struct inet_timewait_death_row tcp_death_row = {
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index ed750f9..cbfef8b 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2560,6 +2560,7 @@ void tcp_send_probe0(struct sock *sk)
}
}
+EXPORT_SYMBOL(tcp_select_initial_window);
EXPORT_SYMBOL(tcp_connect);
EXPORT_SYMBOL(tcp_make_synack);
EXPORT_SYMBOL(tcp_simple_retransmit);
diff --git a/net/ipv6/Makefile b/net/ipv6/Makefile
index 24f3aa0..ae14617 100644
--- a/net/ipv6/Makefile
+++ b/net/ipv6/Makefile
@@ -16,6 +16,7 @@ ipv6-$(CONFIG_XFRM) += xfrm6_policy.o xfrm6_state.o
xfrm6_input.o \
ipv6-$(CONFIG_NETFILTER) += netfilter.o
ipv6-$(CONFIG_IPV6_MULTIPLE_TABLES) += fib6_rules.o
ipv6-$(CONFIG_PROC_FS) += proc.o
+ipv6-$(CONFIG_SYN_COOKIES) += syncookies.o
ipv6-objs += $(ipv6-y)
diff --git a/net/ipv6/syncookies.c b/net/ipv6/syncookies.c
new file mode 100644
index 000..063dade
--- /dev/null
+++ b/net/ipv6/syncookies.c
@@ -0,0 +1,267 @@
+/*
+ * IPv6 Syncookies implementation for the Linux kernel
+ *
+ * Authors:
+ * Glenn Griffin <[EMAIL PROTECTED]>
+ *
+ * Based on IPv4 implementation by Andi Kleen
+ * linux/net/ipv4/syncookies.c
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free
RE: [PATCH 0/7] blk_end_request: full I/O completion handler
Hi, Thanks for the information! We would like to know when does the 2.6.25 kernel will be available at kernel.org. Thanks, Chandrakala -Original Message- From: Jens Axboe [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 05, 2008 4:09 PM To: S, Chandrakala (STSD) Cc: Kiyoshi Ueda; linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Miller, Mike (OS Dev); [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PATCH 0/7] blk_end_request: full I/O completion handler On Tue, Feb 05 2008, S, Chandrakala (STSD) wrote: > Hello, > > We would like to know in which kernel version these patches are > available. They were merged after 2.6.24 was released, so they will show up in the 2.6.25 kernel. -- Jens Axboe -- 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/
Re: [-mm PATCH] sysdev_unregister() should call kobject_del()
On Thu, Feb 07, 2008 at 09:08:42PM -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, Badari Pulavarty wrote: > > > > > Hi Greg, > > > > > > > > > > While playing with hotplug memory remove on 2.6.24-mm1, I > > > > > noticed that /sysfs directory entries are not getting removed. > > > > > > > > > > sysdev_unregister() used to call kobject_unregister(). > > > > > But in 2.6.24-mm1, its only dropping the ref. It should > > > > > call kobject_del() to remove the object. Correct ? > > > > > > > > > > With this change, the directories are getting removed > > > > > correctly. Comments ? > > > > > > > > Ick, no, this shouldn't be needed, someone else must be holding a > > > > reference to the kobject device somewhere. See the kobject documenation > > > > for more info. > > > > > > > > I'll try to see where we grab 2 references... > > > > > > I will take a closer look then. I was taking easy way out :( > > > > Hm, I don't see anything obvious in the sys.c core. What code is > > controlling these objects that you are creating and removing from the > > system? > > add_memory_block()/register_memory() is creating sysfs entries > for the memory blocks. > > I am trying to make use of remove_memory_block() to clean up > sysfs entries. BTW, remove_memory_block() is never tested > before, since we don't support memory remove yet. So how are you testing the sysdev removal logic then if you can't remove memory? Oh, one thing, remove the link in unregister_memory, before you call sysdev_unregister(). You are trying to get the name of a kobject, and the whole object, that has just been blown away, not nice... Which makes me believe your statement about this never being tested before :) thanks, greg k-h -- 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/
Re: DMI: add-type-41
On Fri, Jan 25, 2008 at 09:19:11PM +0100, Wim Van Sebroeck wrote: > Hi All, > > Would appreciate feedback on this patch. > > Thanks in advance, > Wim. > > commit 4956e4e5e77b5a8f87bcfe6127ef17a406edf94b > Author: Wim Van Sebroeck <[EMAIL PROTECTED]> > Date: Mon Dec 31 17:21:33 2007 + > > [PATCH] SMBIOS/DMI - add type 41 = Onboard Devices Extended Information Is there something in the kernel that will consume this data, or is it being exported in /sys/class/dmi/id somehow? There will be one table entry per device (Dell PowerEdge x9xx servers with recent BIOS do so). FWIW, my biosdevname app consumes this data, using dmidecode from userspace. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- 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/
Re: 2.6.24-git15 Keyboard Issue?
Thomas - I believe that the following is the output you are looking for - sorry for the delay - between doctors and grandkids I was ready for a few pain pills and a long nap. I suspect you often feel the same way after dealing with some who post here. Thank you for your support Chris [0.00] Linux version 2.6.24-git15-ch2 ([EMAIL PROTECTED]) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #3 SMP PREEMPT Thu Feb 7 22:00:10 CST 2008 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009f400 (usable) [0.00] BIOS-e820: 0009f400 - 000a (reserved) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - 7fff (usable) [0.00] BIOS-e820: 7fff - 7fff3000 (ACPI NVS) [0.00] BIOS-e820: 7fff3000 - 8000 (ACPI data) [0.00] BIOS-e820: e000 - f000 (reserved) [0.00] BIOS-e820: fec0 - 0001 (reserved) [0.00] 1151MB HIGHMEM available. [0.00] 896MB LOWMEM available. [0.00] Scan SMP from c000 for 1024 bytes. [0.00] Scan SMP from c009fc00 for 1024 bytes. [0.00] Scan SMP from c00f for 65536 bytes. [0.00] found SMP MP-table at [c00f5380] 000f5380 [0.00] Entering add_active_range(0, 0, 524272) 0 entries of 256 used [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] Normal 4096 -> 229376 [0.00] HighMem229376 -> 524272 [0.00] Movable zone start PFN for each node [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 -> 524272 [0.00] On node 0 totalpages: 524272 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 4064 pages, LIFO batch:0 [0.00] Normal zone: 1760 pages used for memmap [0.00] Normal zone: 223520 pages, LIFO batch:31 [0.00] HighMem zone: 2303 pages used for memmap [0.00] HighMem zone: 292593 pages, LIFO batch:31 [0.00] Movable zone: 0 pages used for memmap [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000F9260, 0014 (r0 Nvidia) [0.00] ACPI: RSDT 7FFF3040, 0030 (r1 Nvidia AWRDACPI 42302E31 AWRD 0) [0.00] ACPI: FACP 7FFF30C0, 0074 (r1 Nvidia AWRDACPI 42302E31 AWRD 0) [0.00] ACPI: DSDT 7FFF3180, 63C4 (r1 NVIDIA AWRDACPI 1000 MSFT 10E) [0.00] ACPI: FACS 7FFF, 0040 [0.00] ACPI: MCFG 7FFF9680, 003C (r1 Nvidia AWRDACPI 42302E31 AWRD 0) [0.00] ACPI: APIC 7FFF95C0, 0072 (r1 Nvidia AWRDACPI 42302E31 AWRD 0) [0.00] Nvidia board detected. Ignoring ACPI timer override. [0.00] If you got timer trouble try acpi_use_timer_override [0.00] ACPI: PM-Timer IO Port: 0x4008 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] Processor #0 15:11 APIC version 16 [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) [0.00] Processor #1 15:11 APIC version 16 [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [0.00] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) [0.00] ACPI: IRQ9 used by override. [0.00] ACPI: IRQ14 used by override. [0.00] ACPI: IRQ15 used by override. [0.00] Enabling APIC mode: Flat. Using 1 I/O APICs [0.00] Using ACPI (MADT) for SMP configuration information [0.00] Allocating PCI resources starting at 8800 (gap: 8000:6000) [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 520177 [0.00] Kernel command line: root=UUID=4dc2e6b0-c980-418b-8ad0-98358e7ec47d ro quiet splash nohpet [0.00] mapped APIC to b000 (fee0) [0.00] mapped IOAPIC to a000 (fec0) [0.00] Enabling fast FPU save and restore... done. [0.00] Enabling unmasked SIMD FPU exception support... done. [0.00] Initializing CPU#0 [0.00] PID hash table entries: 4096 (order: 12, 16384 bytes) [0.00] Detected 2412.392 MHz processor. [0.004000] spurious 8259A interrupt: IRQ7. [0.004000] Console: colour VGA+ 80x25 [0.004000] console [tty0] enabled [0.004000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.004000] Inode-cache hash table entries:
Re: C++ in linux kernel
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 the 'new' keyword. > What could the problem be? under using gcc, new operator use malloc by default. but linux doesn't have malloc. Could you create custom allocater? > What kind of runtime support is needed ( arm linux kernel)? Is a > patch available for it? may be nothing. - kosaki -- 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/
Re: [stable] [patch 00/73] 2.6.23-stable review
On Wed, Feb 06, 2008 at 03:50:15PM -0800, Greg KH wrote: > This is the start of the stable review cycle for the 2.6.23.15 release. > There are 73 patches in this series, all will be posted as a response to > this one. If anyone has any issues with these being applied, please let > us know. If anyone is a maintainer of the proper subsystem, and wants > to add a Signed-off-by: line to the patch, please respond with it. Rolled up patch can be found at: kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.23.15-rc1.gz thanks, greg k-h -- 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/
Re: ACPI_WMI: worst config description of all times
good description, Carlos. applied. thanks, -Len On Thursday 07 February 2008 20:19, Carlos Corbacho wrote: > On Friday 08 February 2008 00:12:24 Ray Lee wrote: > > On Feb 7, 2008 3:51 PM, Carlos Corbacho <[EMAIL PROTECTED]> wrote: > > > On Thursday 07 February 2008 23:33:54 Ray Lee wrote: > > > > Do you have list of hardware/platforms that require this feature to > > > > get the hardware to work? (acer abc123, tcm1100 xyz) > > > > > > I have a very long list of Acer laptops that are supported - which is far > > > too long, and changes on far too much of a regular basis to put in there. > > > > > > Perhaps adding something like "This driver is also a required dependency > > > to build the firmware specific drivers needed for many laptops, including > > > Acer and HP machines"? > > Would this be acceptable then? > > -Carlos > --- > ACPI: WMI: Improve Kconfig entry > > From: Carlos Corbacho <[EMAIL PROTECTED]> > > As Pavel Machek has pointed out, the Kconfig entry for WMI is pretty > non-descriptive. > > Rewrite it so that it explains what ACPI-WMI is, and why anyone > would want to enable it. > > Many thanks to Ray Lee for ideas on this. > > Signed-off-by: Carlos Corbacho <[EMAIL PROTECTED]> > CC: Pavel Machek <[EMAIL PROTECTED]> > CC: Ray Lee <[EMAIL PROTECTED]> > CC: Len Brown <[EMAIL PROTECTED]> > --- > > drivers/acpi/Kconfig | 19 +++ > 1 files changed, 15 insertions(+), 4 deletions(-) > > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig > index b7fbf16..ea763ef 100644 > --- a/drivers/acpi/Kconfig > +++ b/drivers/acpi/Kconfig > @@ -207,11 +207,22 @@ config ACPI_WMI > depends on EXPERIMENTAL > depends on X86 > help > - This driver adds support for the ACPI-WMI mapper device (PNP0C14) > - found on some systems. > + This driver adds support for the ACPI-WMI (Windows Management > + Instrumentation) mapper device (PNP0C14) found on some systems. > > - NOTE: You will need another driver or userspace application on top of > - this to actually use anything defined in the ACPI-WMI mapper. > + ACPI-WMI is a proprietary extension to ACPI to expose parts of the > + ACPI firmware to userspace - this is done through various vendor > + defined methods and data blocks in a PNP0C14 device, which are then > + made available for userspace to call. > + > + The implementation of this in Linux currently only exposes this to > + other kernel space drivers. > + > + This driver is a required dependency to build the firmware specific > + drivers needed on many machines, including Acer and HP laptops. > + > + It is safe to enable this driver even if your DSDT doesn't define > + any ACPI-WMI devices. > > config ACPI_ASUS > tristate "ASUS/Medion Laptop Extras" > -- > 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/ > -- 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/
Re: [stable] [patch 00/45] 2.6.24-stable review
On Thu, Feb 07, 2008 at 12:45:49PM -0800, Greg KH wrote: > This is the start of the stable review cycle for the 2.6.24.1 release. > There are 45 patches in this series, all will be posted as a response to > this one. If anyone has any issues with these being applied, please let > us know. If anyone is a maintainer of the proper subsystem, and wants > to add a Signed-off-by: line to the patch, please respond with it. Rolled up patch can be found at: kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.24.1-rc1.gz thanks, greg k-h -- 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/
Re: blackfin compile error
On Feb 6, 2008 2:12 PM, Robin Getz <[EMAIL PROTECTED]> wrote:
> On Wed 6 Feb 2008 11:23, Matt Mackall pondered:
> > On Wed, 2008-02-06 at 17:18 +0200, Adrian Bunk wrote:
> > > Commit 698dd4ba6b12e34e1e432c944c01478c0b2cd773 broke blackfin:
> > >
> > > <-- snip -->
> > >
> > > ...
> > > CC mm/vmscan.o
> > > In file included from
> > > /home/bunk/linux/kernel-2.6/git/linux-2.6/mm/vmscan.c:44:
> > > /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h: In
> > > function 'is_swap_pte':
> > > /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h:48:
> > > error: implicit declaration of function 'pte_none'
> > > /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h:48:
> > > error: implicit declaration of function 'pte_present'
> > > make[2]: *** [mm/vmscan.o] Error 1
> >
> > This suggests that no one's tried to compile -mm on Blackfin since
> > before September, I think.
>
> Or any other nommu arch's either, since looking at the include files, FRV
> (when configured as noMMU) and m68knommu does not include it either...
>
> > Is there somewhere more appropriate to move it? I can't find one.
> > Failing that, we can wrap it in CONFIG_MMU, I suppose.
>
> Or just add to the the following:
>
> ./include/asm-blackfin
> ./include/asm-frv/ (only when configured as !MMU)
> ./include/asm-h8300
> ./include/asm-m68knommu
> ./include/asm-v850
>
> Others seem to have it in include/asm-x/pgtable.h as #define, inline
> function, or extern.
looks like only MMU code currently uses the function, but to keep
things nice, we may want something like:
static inline int is_swap_pte(pte_t pte)
{
#ifdef CONFIG_MMU
return !pte_none(pte) && !pte_present(pte) && !pte_file(pte);
#else
return 0;
#endif
}
the header is also lacking an #include at the top ...
-mike
--
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/
Re: [PATCH] Add IPv6 support to TCP SYN cookies
> Or maybe use percpu storage for that... That seems like a good approach. I'll incorporate it into my v6 patch, and send out an update. Thanks. > I am not sure if cookie_hash() is always called with preemption disabled. > (If not, we have to use get_cpu_var()/put_cpu_var()) cookie_hash is always called within NET_RX_SOFTIRQ context so I believe preemption will always be disabled by __do_softirq(). So there shouldn't be a need to use get_cpu_var/put_cpu_var, somebody correct me if I'm wrong. --Glenn -- 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/
[LINUX-KERNEL] C++ in linux kernel
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 the 'new' keyword. What could the problem be? What kind of runtime support is needed ( arm linux kernel)? Is a patch available for it? Thanks, Rohit -- 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/
Re: [-mm PATCH] sysdev_unregister() should call kobject_del()
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, Badari Pulavarty wrote: > > > > Hi Greg, > > > > > > > > While playing with hotplug memory remove on 2.6.24-mm1, I > > > > noticed that /sysfs directory entries are not getting removed. > > > > > > > > sysdev_unregister() used to call kobject_unregister(). > > > > But in 2.6.24-mm1, its only dropping the ref. It should > > > > call kobject_del() to remove the object. Correct ? > > > > > > > > With this change, the directories are getting removed > > > > correctly. Comments ? > > > > > > Ick, no, this shouldn't be needed, someone else must be holding a > > > reference to the kobject device somewhere. See the kobject documenation > > > for more info. > > > > > > I'll try to see where we grab 2 references... > > > > I will take a closer look then. I was taking easy way out :( > > Hm, I don't see anything obvious in the sys.c core. What code is > controlling these objects that you are creating and removing from the > system? add_memory_block()/register_memory() is creating sysfs entries for the memory blocks. I am trying to make use of remove_memory_block() to clean up sysfs entries. BTW, remove_memory_block() is never tested before, since we don't support memory remove yet. Thanks, Badari -- 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/
[PATCH 2/2] x86: regparm(3) is mandatory, no need to annotate
Functions in ptrace.c and signal_32.c were defined with __attribute(regparm(3))
which is unnecessary now that X86_32 must compile this way.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
arch/x86/kernel/ptrace.c|1 -
arch/x86/kernel/signal_32.c |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 702c33e..2e785d5 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1426,7 +1426,6 @@ void send_sigtrap(struct task_struct *tsk, struct pt_regs
*regs, int error_code)
/* notification of system call entry/exit
* - triggered by current->work.syscall_trace
*/
-__attribute__((regparm(3)))
int do_syscall_trace(struct pt_regs *regs, int entryexit)
{
int is_sysemu = test_thread_flag(TIF_SYSCALL_EMU);
diff --git a/arch/x86/kernel/signal_32.c b/arch/x86/kernel/signal_32.c
index c1f4ff7..a99529e 100644
--- a/arch/x86/kernel/signal_32.c
+++ b/arch/x86/kernel/signal_32.c
@@ -654,7 +654,6 @@ static void do_signal(struct pt_regs *regs)
* notification of userspace execution resumption
* - triggered by the TIF_WORK_MASK flags
*/
-__attribute__((regparm(3)))
void do_notify_resume(struct pt_regs *regs, void *_unused,
__u32 thread_info_flags)
{
--
1.5.4.1219.g65b9
--
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/
[PATCH] kbuild: silence CHK/UPD messages according to $(quiet)
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]> --- init/Makefile |4 +++- scripts/Kbuild.include |8 ++-- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/init/Makefile b/init/Makefile index 633392f..c5f157c 100644 --- a/init/Makefile +++ b/init/Makefile @@ -27,7 +27,9 @@ $(obj)/version.o: include/linux/compile.h # mkcompile_h will make sure to only update the # actual file if its content has changed. + quiet_chk_compile.h = echo ' CHK $@' +silent_chk_compile.h = : include/linux/compile.h: FORCE - @echo ' CHK $@' + @$($(quiet)chk_compile.h) $(Q)$(CONFIG_SHELL) $(srctree)/scripts/mkcompile_h $@ \ "$(UTS_MACHINE)" "$(CONFIG_SMP)" "$(CONFIG_PREEMPT)" "$(CC) $(KBUILD_CFLAGS)" diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include index b96ea8d..da3559e 100644 --- a/scripts/Kbuild.include +++ b/scripts/Kbuild.include @@ -39,15 +39,19 @@ escsq = $(subst $(squote),'\$(squote)',$1) # - If they are equal no change, and no timestamp update # - stdin is piped in from the first prerequisite ($<) so one has # to specify a valid file as first prerequisite (often the kbuild file) + quiet_chk_filechk = echo ' CHK $@' +silent_chk_filechk = : + quiet_upd_filechk = echo ' UPD $@' +silent_upd_filechk = : define filechk $(Q)set -e; \ - echo ' CHK $@';\ + $($(quiet)chk_filechk); \ mkdir -p $(dir $@); \ $(filechk_$(1)) < $< > [EMAIL PROTECTED]; \ if [ -r $@ ] && cmp -s $@ [EMAIL PROTECTED]; then \ rm -f [EMAIL PROTECTED];\ else\ - echo ' UPD $@';\ + $($(quiet)upd_filechk); \ mv -f [EMAIL PROTECTED] $@; \ fi endef -- 1.5.4 -- 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/
[PATCH 1/2] x86: make X86_32 pt_regs members unsigned long
Similar to X86_64, move the 32 bit pt_regs to be unsigned long.
Adopt the X86_64-style of casting orig_ax to long in the signal.c
if statements when checking for >=0.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
arch/x86/kernel/signal_32.c |4 ++--
include/asm-x86/ptrace.h|9 ++---
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/signal_32.c b/arch/x86/kernel/signal_32.c
index 7718395..c1f4ff7 100644
--- a/arch/x86/kernel/signal_32.c
+++ b/arch/x86/kernel/signal_32.c
@@ -527,7 +527,7 @@ handle_signal(unsigned long sig, siginfo_t *info, struct
k_sigaction *ka,
int ret;
/* Are we from a system call? */
- if (regs->orig_ax >= 0) {
+ if ((long)regs->orig_ax >= 0) {
/* If so, check system call restarting.. */
switch (regs->ax) {
case -ERESTART_RESTARTBLOCK:
@@ -625,7 +625,7 @@ static void do_signal(struct pt_regs *regs)
}
/* Did we come from a system call? */
- if (regs->orig_ax >= 0) {
+ if ((long)regs->orig_ax >= 0) {
/* Restart the system call - no handlers present */
switch (regs->ax) {
case -ERESTARTNOHAND:
diff --git a/include/asm-x86/ptrace.h b/include/asm-x86/ptrace.h
index 708337a..bc44246 100644
--- a/include/asm-x86/ptrace.h
+++ b/include/asm-x86/ptrace.h
@@ -42,12 +42,12 @@ struct pt_regs {
unsigned long si;
unsigned long di;
unsigned long bp;
- long ax;
+ unsigned long ax;
unsigned long ds;
unsigned long es;
unsigned long fs;
/* int gs; */
- long orig_ax;
+ unsigned long orig_ax;
unsigned long ip;
unsigned long cs;
unsigned long flags;
@@ -145,7 +145,10 @@ extern void send_sigtrap(struct task_struct *tsk, struct
pt_regs *regs, int erro
void signal_fault(struct pt_regs *regs, void __user *frame, char *where);
#endif
-#define regs_return_value(regs) ((regs)->ax)
+static inline unsigned long regs_return_value(struct pt_regs *regs)
+{
+ return regs->ax;
+}
/*
* user_mode_vm(regs) determines whether a register set came from user mode.
--
1.5.4.1219.g65b9
--
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/
Re: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Thu, Feb 07, 2008 at 07:11:33PM -0800, Linus Torvalds wrote: > > > On Thu, 7 Feb 2008, Andrew Morton wrote: > > > > Sob. Can we please merge "Convert SG from nopage to fault"? > > Heh. I just took it directly then. > > I think it's more of a VM patch than a SCSI patch anyway, so I don't think > you really should even have tried to push it through the SCSI tree. > > It's not like we ever do the low-level FS changes for VFS issues through > the FS maintainers anyway (ie you sent me all those iget/read_inode things > directly rather than trying to go through each filesystem). I don't think > this is any different, really. Yes. For ->faul Nick should just have sent on the whole batch after giving fs/driver people enough time to review it. -- 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/
Re: [-mm PATCH] sysdev_unregister() should call kobject_del()
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, Badari Pulavarty wrote: > > > Hi Greg, > > > > > > While playing with hotplug memory remove on 2.6.24-mm1, I > > > noticed that /sysfs directory entries are not getting removed. > > > > > > sysdev_unregister() used to call kobject_unregister(). > > > But in 2.6.24-mm1, its only dropping the ref. It should > > > call kobject_del() to remove the object. Correct ? > > > > > > With this change, the directories are getting removed > > > correctly. Comments ? > > > > Ick, no, this shouldn't be needed, someone else must be holding a > > reference to the kobject device somewhere. See the kobject documenation > > for more info. > > > > I'll try to see where we grab 2 references... > > I will take a closer look then. I was taking easy way out :( Hm, I don't see anything obvious in the sys.c core. What code is controlling these objects that you are creating and removing from the system? thanks, greg k-h -- 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/
Re: [git pull] x86 arch updates for v2.6.25
On Mon, Feb 04, 2008 at 08:11:03PM -0800, Phil Oester wrote: > On Mon, Feb 04, 2008 at 07:27:53PM -0800, Linus Torvalds wrote: > > kgdb? Not so interesting. We have many more hard problems happening at > > user sites, not in developer hands. > > FWIW, I'm not a fulltime developer by any means, but on occasion > I have fixed a few bugs in the netfilter area of the kernel. > And in almost all cases, I used kgdb in my debugging and testing > of fixes. > > In doing so, it was a bit of a PITA to find/patch kgdb into the > kernel, and having it as a configurable option would have saved > me some time and effort and made the process much smoother. > > So perhaps someone else out there would find it similarly useful, > and the extra time it takes to find/patch/compile kgdb in is > precluding them from participating? Why would we ever want to do > that? Just as a note I find it extremly useful in some case to be able to run gdb on a kernel. As said by Andrew it's less the tradition debugging but more to get a picture of what's going on. But kgdb traditionally was more than just a simple gdb stub and contained hooks all over the place for additional functionality. I don't think all this is a good idea and I'd be against it. I'd be really happy to see a common gdb stub with small arch support that allows attaching gdb to the kernel through various transports. Maybe someone is up to do just that? Even the full blown kgdb with all the hooks would benefit from having the gdb stub already in, so maybe I could motivate some kgdb developers to do that work? -- 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/
Re: [PATCH] sata_mv: fix loop with last port
Yinghai Lu wrote:
[PATCH] sata_mv: fix loop with last port
commit f351b2d638c3cb0b95adde3549b7bfaf3f991dfa
sata_mv: Support SoC controllers
cause panic:
scsi 4:0:0:0: Direct-Access ATA HITACHI HDS7225S V44O PQ: 0 ANSI: 5
sd 4:0:0:0: [sde] 488390625 512-byte hardware sectors (250056 MB)
sd 4:0:0:0: [sde] Write Protect is off
sd 4:0:0:0: [sde] Mode Sense: 00 3a 00 00
sd 4:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
sd 4:0:0:0: [sde] 488390625 512-byte hardware sectors (250056 MB)
sd 4:0:0:0: [sde] Write Protect is off
sd 4:0:0:0: [sde] Mode Sense: 00 3a 00 00
sd 4:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
sde:<1>BUG: unable to handle kernel NULL pointer dereference at
001a
IP: [] mv_interrupt+0x21c/0x4cc
PGD 0
Oops: [1] SMP
CPU 3
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.24-smp-08636-g0afc2ed-dirty #26
RIP: 0010:[] [] mv_interrupt+0x21c/0x4cc
RSP: :8102050bbec8 EFLAGS: 00010297
RAX: 0008 RBX: RCX: 0003
RDX: 8000 RSI: 0286 RDI: 8102035180e0
RBP: 0001 R08: 0003 R09: 8102036613e0
R10: 0002 R11: 8061474c R12: 8102035bf828
R13: 0008 R14: 81020348ece8 R15: c20002cb2000
FS: () GS:810405025700() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 001a CR3: 00201000 CR4: 06e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process swapper (pid: 0, threadinfo 810405094000, task 8102050b28c0)
Stack: 0001000c 000204220400 00110002 81020348eda8
0001 8102035f2cc0
0018 80269ee8
Call Trace:
[] ? handle_IRQ_event+0x25/0x53
[] ? handle_fasteoi_irq+0x90/0xc8
[] ? do_IRQ+0xf1/0x15f
[] ? default_idle+0x0/0x55
[] ? ret_from_intr+0x0/0xa
[] ? lapic_next_event+0x0/0xa
[] ? default_idle+0x31/0x55
[] ? default_idle+0x2c/0x55
[] ? default_idle+0x0/0x55
[] ? cpu_idle+0x92/0xb8
Code: 41 14 85 c0 89 44 24 14 0f 84 9d 02 00 00 f7 d0 01 d6 41 89 d5 89 41 14 8b 41
14 89 34 24 e9 7e 02 00 00 49 63 c5 49 8b 5c c6 48 43 1a 80 4c 8b a3 20 37
00 00 0f 85 62 02 00 00 31 c9 41 83
RIP [] mv_interrupt+0x21c/0x4cc
RSP
CR2: 001a
---[ end trace 2583b5f7a5350584 ]---
Kernel panic - not syncing: Aiee, killing interrupt handler!
last_port already include port0 base.
this patch change use last_port directly, and move pp assignment later.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
..
Yup, obvious bug fixes, thanks.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/ata/sata_mv.c
===
--- linux-2.6.orig/drivers/ata/sata_mv.c
+++ linux-2.6/drivers/ata/sata_mv.c
@@ -1716,14 +1716,16 @@ static void mv_host_intr(struct ata_host
VPRINTK("ENTER, hc%u relevant=0x%08x HC IRQ cause=0x%08x\n",
hc, relevant, hc_irq_cause);
- for (port = port0; port < port0 + last_port; port++) {
+ for (port = port0; port < last_port; port++) {
struct ata_port *ap = host->ports[port];
- struct mv_port_priv *pp = ap->private_data;
+ struct mv_port_priv *pp;
int have_err_bits, hard_port, shift;
if ((!ap) || (ap->flags & ATA_FLAG_DISABLED))
continue;
+ pp = ap->private_data;
+
shift = port << 1;/* (port * 2) */
if (port >= MV_PORTS_PER_HC) {
shift++;/* skip bit 8 in the HC Main IRQ reg */
--
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/
Re: [GIT] Please pull 2 NFS client fixes
On Thu, 2008-02-07 at 18:48 -0800, Andrew Morton wrote:
> On Thu, 07 Feb 2008 20:07:21 -0500 Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
> > commit 5d47a35600270e7115061cb1320ee60ae9bcb6b8
> > Author: Trond Myklebust <[EMAIL PROTECTED]>
> > Date: Thu Feb 7 17:24:07 2008 -0500
> >
> > NFS: Fix a potential file corruption issue when writing
> >
> > If the inode is flagged as having an invalid mapping, then we can't
> > rely on
> > the PageUptodate() flag. Ensure that we don't use the
> > "anti-fragmentation"
> > write optimisation in nfs_updatepage(), since that will cause NFS to
> > write
> > out areas of the page that are no longer guaranteed to be up to date.
> >
> > A potential corruption could occur in the following scenario:
> >
> > client 1client 2
> > === ===
> > fd=open("f",O_CREAT|O_WRONLY,0644);
> > write(fd,"fubar\n",6); // cache last
> > page
> > close(fd);
> > fd=open("f",O_WRONLY|O_APPEND);
> > write(fd,"foo\n",4);
> > close(fd);
> >
> > fd=open("f",O_WRONLY|O_APPEND);
> > write(fd,"bar\n",4);
> > close(fd);
> > -
> > The bug may lead to the file "f" reading 'fubar\n\0\0\0\nbar\n' because
> > client 2 does not update the cached page after re-opening the file for
> > write. Instead it keeps it marked as PageUptodate() until someone calls
> > invaldate_inode_pages2() (typically by calling read()).
>
> Is this one worth feeding back into 2.6.24.x? (for various values of "4"?)
Definitely, and probably back into 2.6.23.x, 2.6.22.x,... too.
Cheers
Trond
--
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/
Re: The ext3 way of journalling
On Jan 9, 2008 12:07 AM, Tuomo Valkonen <[EMAIL PROTECTED]> wrote: > One should always indicate the version of software when complaining. Well, > > $ uname -a > Linux noi 2.6.14 #1 PREEMPT Sun Oct 30 20:18:48 EET 2005 i686 GNU/Linux > > I've tried upgrading, and failed: the megatonne monolith with a gazillion > hidden options (and totally worthless make oldconfig) is impossible to > compile these days, and the distros' stock kernel are utter and total crap > that load drivers in wrong order etc., and are difficult to configure > (demanding crap that demands udev to edit their initrds). Not to even > speak of the udev-demanding scsi-mapping insanity of SATA etc. devices > these days. > somebody has been reading the Unix Haters Handbook... I like that book too. In a way it a very good guideline for unix developers. > I've had it with Linux. It's no longer for power users. It's so complex > that it's only for idiot users that are content with the shoddy defaults, > and (paid) developers. > > -- > Tuomo > I said that 2 weeks ago. And after trying out alternatives im back to linux. But i bought the minix 3 book... -- Lay low and nourish in obscurity -- 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/
Re: [patch 13/45] USB: sierra: add support for Onda H600/Zte MF330datacard to USB Driver for Sierra Wireless
On Thu, Feb 07, 2008 at 06:21:55PM -0800, Kevin Lloyd wrote: > > 2.6.24-stable review patch. If anyone has any objections, please let > us > > know. > > > > -- > > From: Bruno Redondi <[EMAIL PROTECTED]> > > > > Added support for Onda H600/Zte MF330 GPRS/UMTS/HSDPA datacard > > Per our earlier discussion we probably don't want to have this one in > the Sierra driver. For now, yes, we should mirror what is going to be in the 2.6.25 kernel release. I see the split happening for 2.6.26. So I say leave this for now, it adds support for users of these devices. thanks, greg k-h -- 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/
Re: [PATCH] USB: mark USB drivers as being GPL only
Marcel Holtmann wrote: > Hi David, > > > I think you're missing my point: as long as the license stays the way > it is now, you can never distribute proprietary code unless you've > consulted a lawyer and even then you run the risk of being sued for > infringement if the copyright holder thinks what you have is derived > work. > > Yes I can, if the proprietary code is not linked with GPL code (and the proprietary code is original). Loadable modules are not linked. This is a very clear-cut case. >>> that is not clear-cut case. You link at run-time. Otherwise the module >>> would do nothing. >>> >> That's why it's allowed. The module isn't linked when it's distributed, >> and the author doesn't do or cause the linking; the user does. And the >> user never distributes in the linked state. Distribution is key to GPL. >> > > so how do you build this module that is not linked without using the > Linux kernel. You could hand code in assembler, using Microsoft's assembler under Windows. You could compile from C, using GCC on FreeBSD. But that's immaterial. A module which is an original, non-derivative work, is, well, original and non-derivative. Do you say that it must be otherwise? Why would that be? -- 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/
Re: [PATCH] knfsd: Remove NLM_HOST_MAX and associated logic.
On Fri, Feb 08, 2008 at 01:03:37PM +1100, NeilBrown wrote: > > Lockd caches information about hosts that have recently held locks it > expedite the taking of further locks. Applied, thanks!--b. > > It periodically discards this information for hosts that have not been > used for a few minutes. > > lockd currently has a value NLM_HOST_MAX, and changes the 'garbage > collection' behaviour when the number of hosts exceeds this threshold. > > However it's behaviour in strange an likely not what was intended. > When the number of hosts exceeds the max, it scans *less* often (every > 2 minutes vs every minute) and allows unused host information to > remain around longer (5 minutes instead of 2). > > Having this limit is of dubious value anyway, and we have not > suffered from the code not getting the limit right, so remove the > limit altogether. We go with the larger values (discard 5 minute old > hosts every 2 minutes) as that is probably safer. > > Maybe the periodic garbage collection should be replace to with > 'shrinker' handler so we just respond to memory pressure > > Acked-by: Jeff Layton <[EMAIL PROTECTED]> > Signed-off-by: Neil Brown <[EMAIL PROTECTED]> > > ### Diffstat output > ./fs/lockd/host.c |9 +++-- > 1 file changed, 3 insertions(+), 6 deletions(-) > > diff .prev/fs/lockd/host.c ./fs/lockd/host.c > --- .prev/fs/lockd/host.c 2008-02-07 14:20:54.0 +1100 > +++ ./fs/lockd/host.c 2008-02-08 12:54:28.0 +1100 > @@ -19,12 +19,11 @@ > > > #define NLMDBG_FACILITY NLMDBG_HOSTCACHE > -#define NLM_HOST_MAX 64 > #define NLM_HOST_NRHASH 32 > #define NLM_ADDRHASH(addr) (ntohl(addr) & (NLM_HOST_NRHASH-1)) > #define NLM_HOST_REBIND (60 * HZ) > -#define NLM_HOST_EXPIRE ((nrhosts > NLM_HOST_MAX)? 300 * HZ : > 120 * HZ) > -#define NLM_HOST_COLLECT ((nrhosts > NLM_HOST_MAX)? 120 * HZ : 60 * HZ) > +#define NLM_HOST_EXPIRE (300 * HZ) > +#define NLM_HOST_COLLECT (120 * HZ) > > static struct hlist_head nlm_hosts[NLM_HOST_NRHASH]; > static unsigned long next_gc; > @@ -142,9 +141,7 @@ nlm_lookup_host(int server, const struct > INIT_LIST_HEAD(>h_granted); > INIT_LIST_HEAD(>h_reclaim); > > - if (++nrhosts > NLM_HOST_MAX) > - next_gc = 0; > - > + nrhosts++; > out: > mutex_unlock(_host_mutex); > return host; > - > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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/
Re: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Thu, 07 Feb 2008 19:37:07 -0600 James Bottomley <[EMAIL PROTECTED]> wrote: > > On Thu, 2008-02-07 at 18:56 -0600, James Bottomley wrote: > > Quite a bit of this is fixing things broken previously (the advansys fix > > is still pending resolution, but I'll send it as an -rc fix when we have > > it). There's the final elimination of all drivers that are esp based > > but don't use the scsi_esp core (that's mostly m68k and alpha). Plus > > the usual bunch of driver updates and the addition of a new enclosure > > services driver and the corresponding ULD. > > OK, the advansys fix came in. I've added it to the patch. > > James > > > > >From f983323fea178352ed3b69c70561a13825a3ce59 Mon Sep 17 00:00:00 2001 > From: FUJITA Tomonori <[EMAIL PROTECTED]> > Date: Fri, 8 Feb 2008 09:50:08 +0900 > Subject: [SCSI] advansys: fix overrun_buf aligned bug Seems that it was a bit late, Linus pulled scsi-misc before the patch was added. -- 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/
Re: [PATCH] sysctl: allow embedded targets to disable sysctl_check.c
On Thu, 7 Feb 2008 14:38:58 +0100 Holger Schurig <[EMAIL PROTECTED]> wrote: > Disable sysctl_check.c for embedded targets. This saves about about 11 kB > in .text and another 11 kB in .data on a PXA255 embedded platform. > Nice improvement. But iirc sysctl_check was overtly a temporary thing. Eric, was that the intention? > > --- linux.orig/init/Kconfig > +++ linux/init/Kconfig > @@ -475,6 +475,17 @@ > > If unsure say Y here. > > +config SYSCTL_SYSCALL_CHECK > + bool "Sysctl checks" if EMBEDDED > + depends on SYSCTL_SYSCALL > + default y > + ---help--- > + sys_sysctl uses binary paths that have been found challenging > + to properly maintain and use. This enables checks that help > + you to keep things correct. > + > + If unsure say Y here. > + -- 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/
Re: [patch 10/18] sg: nopage
For the patch shown below:
Signed-off-by: Douglas Gilbert <[EMAIL PROTECTED]>
[EMAIL PROTECTED] wrote:
Convert SG from nopage to fault.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org
---
drivers/scsi/sg.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
Index: linux-2.6/drivers/scsi/sg.c
===
--- linux-2.6.orig/drivers/scsi/sg.c
+++ linux-2.6/drivers/scsi/sg.c
@@ -1144,23 +1144,22 @@ sg_fasync(int fd, struct file *filp, int
return (retval < 0) ? retval : 0;
}
-static struct page *
-sg_vma_nopage(struct vm_area_struct *vma, unsigned long addr, int *type)
+static int
+sg_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
Sg_fd *sfp;
- struct page *page = NOPAGE_SIGBUS;
unsigned long offset, len, sa;
Sg_scatter_hold *rsv_schp;
struct scatterlist *sg;
int k;
if ((NULL == vma) || (!(sfp = (Sg_fd *) vma->vm_private_data)))
- return page;
+ return VM_FAULT_SIGBUS;
rsv_schp = >reserve;
- offset = addr - vma->vm_start;
+ offset = vmf->pgoff << PAGE_SHIFT;
if (offset >= rsv_schp->bufflen)
- return page;
- SCSI_LOG_TIMEOUT(3, printk("sg_vma_nopage: offset=%lu, scatg=%d\n",
+ return VM_FAULT_SIGBUS;
+ SCSI_LOG_TIMEOUT(3, printk("sg_vma_fault: offset=%lu, scatg=%d\n",
offset, rsv_schp->k_use_sg));
sg = rsv_schp->buffer;
sa = vma->vm_start;
@@ -1169,21 +1168,21 @@ sg_vma_nopage(struct vm_area_struct *vma
len = vma->vm_end - sa;
len = (len < sg->length) ? len : sg->length;
if (offset < len) {
+ struct page *page;
page = virt_to_page(page_address(sg_page(sg)) + offset);
get_page(page); /* increment page count */
- break;
+ vmf->page = page;
+ return 0; /* success */
}
sa += len;
offset -= len;
}
- if (type)
- *type = VM_FAULT_MINOR;
- return page;
+ return VM_FAULT_SIGBUS;
}
static struct vm_operations_struct sg_mmap_vm_ops = {
- .nopage = sg_vma_nopage,
+ .fault = sg_vma_fault,
};
static int
--
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/
Re: [git pull] device-mapper update for 2.6.25
On Thu, Feb 07, 2008 at 07:04:47PM -0800, Andrew Morton wrote: > On Fri, 8 Feb 2008 02:45:32 + Alasdair G Kergon <[EMAIL PROTECTED]> wrote: > > > dm: move deferred bio flushing to workqueue > > To my unpracticed eye this one looks fairly fundamental. Unfortunately the > changelog: > > Add a single-thread workqueue for each mapped device and move flushing > of the lists of pushback and deferred bios to this new workqueue. > > tells us nothing of the reasons for this change. (It should have done so!) > > It _looks_ pretty unscalable. Perhaps these deferred BIOs don't happen > very often? Indeed - it's a rare occurrence - happens when the dm device is suspended/resumed which usually means it was being reconfigured by something in userspace. It's the first patch of a series that will provide barrier support (slated for 2.6.26). The appearance of all these workqueues in dm goes back to this old change: md-dm-reduce-stack-usage-with-stacked-block-devices.patch Alasdair -- [EMAIL PROTECTED] -- 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/
Re: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Thu, 07 Feb 2008 21:16:43 -0600 James Bottomley <[EMAIL PROTECTED]> wrote: > On Thu, 2008-02-07 at 18:46 -0800, Andrew Morton wrote: > > On Thu, 07 Feb 2008 18:56:46 -0600 James Bottomley <[EMAIL PROTECTED]> > > wrote: > > > > > Quite a bit of this is fixing things broken previously (the advansys fix > > > is still pending resolution, but I'll send it as an -rc fix when we have > > > it). There's the final elimination of all drivers that are esp based > > > but don't use the scsi_esp core (that's mostly m68k and alpha). Plus > > > the usual bunch of driver updates and the addition of a new enclosure > > > services driver and the corresponding ULD. > > > > Sob. Can we please merge "Convert SG from nopage to fault"? It has been > > sent three times, the first time was Dec 5 last year and it has thus far > > received the lead balloon treatment. Despite my explicit request for > > consideration last time I sent it > > > > If there is no movement here then I have to carry the moderately intrusive > > mm-remove-nopage.patch for another N months and we need to watch out for > > new ->nopage implementations popping up etc. > > I agree ... I've pinged Doug privately, this is publicly. > Unfortunately, it is an intrusive change and needs testing .. I just > don't have the tools that do this for SG. > I keep on forgetting that sg==dougg. In fact scsi is the area in which I have the most who-maintains-what trouble. I just don't believe what MAINTAINERS says about scsi drivers and I tend to resort to git-whatchanged to find out who's really doing stuff. The number of [EMAIL PROTECTED] makes my head spin and I tend to cc as many as I can get my hands on. IOW: some care and attention to the ./MAINTAINERS file would really help here. -- 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/
Re: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Thu, 2008-02-07 at 18:46 -0800, Andrew Morton wrote: > On Thu, 07 Feb 2008 18:56:46 -0600 James Bottomley <[EMAIL PROTECTED]> wrote: > > > Quite a bit of this is fixing things broken previously (the advansys fix > > is still pending resolution, but I'll send it as an -rc fix when we have > > it). There's the final elimination of all drivers that are esp based > > but don't use the scsi_esp core (that's mostly m68k and alpha). Plus > > the usual bunch of driver updates and the addition of a new enclosure > > services driver and the corresponding ULD. > > Sob. Can we please merge "Convert SG from nopage to fault"? It has been > sent three times, the first time was Dec 5 last year and it has thus far > received the lead balloon treatment. Despite my explicit request for > consideration last time I sent it > > If there is no movement here then I have to carry the moderately intrusive > mm-remove-nopage.patch for another N months and we need to watch out for > new ->nopage implementations popping up etc. I agree ... I've pinged Doug privately, this is publicly. Unfortunately, it is an intrusive change and needs testing .. I just don't have the tools that do this for SG. James -- 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/
Re: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Thu, 7 Feb 2008, Andrew Morton wrote: > > Sob. Can we please merge "Convert SG from nopage to fault"? Heh. I just took it directly then. I think it's more of a VM patch than a SCSI patch anyway, so I don't think you really should even have tried to push it through the SCSI tree. It's not like we ever do the low-level FS changes for VFS issues through the FS maintainers anyway (ie you sent me all those iget/read_inode things directly rather than trying to go through each filesystem). I don't think this is any different, really. Linus -- 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/
Re: [git pull] device-mapper update for 2.6.25
On Fri, 8 Feb 2008 02:45:32 + Alasdair G Kergon <[EMAIL PROTECTED]> wrote: > dm: move deferred bio flushing to workqueue To my unpracticed eye this one looks fairly fundamental. Unfortunately the changelog: Add a single-thread workqueue for each mapped device and move flushing of the lists of pushback and deferred bios to this new workqueue. tells us nothing of the reasons for this change. (It should have done so!) It _looks_ pretty unscalable. Perhaps these deferred BIOs don't happen very often? -- 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/
[GIT PATCH] hwmon updates against v2.6.24 (~git17)
Hi Linus: Please pull from: git://lm-sensors.org/kernel/mhoffman/hwmon-2.6.git release You'll get two new drivers and cleanups all over the place. The addition of individual alarm sysfs files to all drivers continues. All of these patches made it into the most recent -mm, at least. Thanks & regards, Documentation/hwmon/ads7828 | 36 ++ Documentation/hwmon/it87|2 +- Documentation/hwmon/lm78|4 +- Documentation/hwmon/lm87| 11 +- Documentation/hwmon/userspace-tools |2 +- Documentation/hwmon/w83627ehf |5 +- Documentation/hwmon/w83627hf|3 +- Documentation/hwmon/w83781d | 22 +- Documentation/hwmon/w83l786ng | 54 +++ Documentation/i2c/busses/i2c-piix4 |2 +- drivers/firmware/dmi_scan.c | 62 ++- drivers/hwmon/Kconfig | 30 +- drivers/hwmon/Makefile |2 + drivers/hwmon/abituguru3.c |1 + drivers/hwmon/adm1021.c |1 - drivers/hwmon/adm1025.c | 393 + drivers/hwmon/adm1026.c | 632 +++ drivers/hwmon/adm1031.c | 501 ++--- drivers/hwmon/adm9240.c | 27 ++- drivers/hwmon/ads7828.c | 297 + drivers/hwmon/adt7470.c | 100 - drivers/hwmon/asb100.c | 395 - drivers/hwmon/dme1737.c | 23 +- drivers/hwmon/ds1621.c |1 - drivers/hwmon/f71805f.c |6 +- drivers/hwmon/f71882fg.c|6 +- drivers/hwmon/fscher.c |1 - drivers/hwmon/fschmd.c | 94 - drivers/hwmon/fscpos.c |1 - drivers/hwmon/gl518sm.c | 269 drivers/hwmon/gl520sm.c | 648 +--- drivers/hwmon/it87.c| 88 - drivers/hwmon/lm75.c|1 - drivers/hwmon/lm77.c| 20 +- drivers/hwmon/lm78.c|7 +- drivers/hwmon/lm80.c| 328 +++--- drivers/hwmon/lm83.c|1 - drivers/hwmon/lm85.c| 64 +++- drivers/hwmon/lm87.c| 29 +- drivers/hwmon/lm90.c| 27 +- drivers/hwmon/lm92.c|1 - drivers/hwmon/pc87360.c |6 +- drivers/hwmon/pc87427.c |6 +- drivers/hwmon/smsc47b397.c |6 +- drivers/hwmon/smsc47m1.c|6 +- drivers/hwmon/smsc47m192.c |3 +- drivers/hwmon/vt1211.c |8 +- drivers/hwmon/vt8231.c |2 +- drivers/hwmon/w83627ehf.c | 29 +- drivers/hwmon/w83627hf.c| 225 --- drivers/hwmon/w83781d.c | 49 +-- drivers/hwmon/w83791d.c |6 +- drivers/hwmon/w83793.c | 13 +- drivers/hwmon/w83l785ts.c |1 - drivers/hwmon/w83l786ng.c | 821 +++ drivers/i2c/chips/eeprom.c |1 - drivers/i2c/chips/pcf8574.c |1 - drivers/i2c/chips/pcf8591.c |1 - include/linux/dmi.h |3 + include/linux/i2c-id.h | 36 -- 60 files changed, 3689 insertions(+), 1731 deletions(-) create mode 100644 Documentation/hwmon/ads7828 create mode 100644 Documentation/hwmon/w83l786ng create mode 100644 drivers/hwmon/ads7828.c create mode 100644 drivers/hwmon/w83l786ng.c Darrick J. Wong (1): hwmon: (adt7470) Support per-sensor alarm files Hans de Goede (1): hwmon: (fschmd) Read voltage scaling factors from BIOS DMI Jean Delvare (49): dmi: Let drivers walk the DMI table hwmon: (lm78/w83781d) Probe fewer I2C addresses hwmon: (lm87) Add support for the Analog Devices ADM1024 hwmon: (adm1025) Use dynamic sysfs callbacks hwmon: (adm1025) Add individual alarm files hwmon: (adm1025) Various cleanups hwmon: (fschmd) Discard non-ASCII characters hwmon: (gl518sm) Various cleanups hwmon: (gl518sm) Don't create sysfs files for missing features hwmon: (gl518sm) Refactor fan functions hwmon: (gl518sm) Add individual alarm and beep files hwmon: (gl518sm) Report error on invalid fan div value hwmon: (gl518sm) Fix the reported fan speed hwmon: (lm90) Use generic i2c reads during detection hwmon: (gl520sm) Various cleanups hwmon: (gl520sm) Put register addresses in arrays hwmon: (gl520sm) De-macro the sysfs callbacks hwmon: (gl520sm) Add individual alarm and beep files hwmon: Update the lm-sensors website address hwmon: Let the user override the detected Super-I/O device ID hwmon: (it87) Discard a dead e-mail address hwmon: (it87) Add individual alarm files hwmon: (adm1026) Add individual alarm files hwmon: (adm1026) Whitespace cleanups
Re: [PATCH] USB: mark USB drivers as being GPL only
Alan Cox wrote: >> It would not be improper to say that "such and such a lawyer said this >> and that." I'm not proposing that you breach their copyright in their >> > > It would be highly improper given these were business discussions > involving companies using Linux. Then you should never have brought it up. Since you never really said what any lawyer told you, let's just forget that you did bring it up. -- 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/
Re: [PATCH] USB: mark USB drivers as being GPL only
Hans-Jürgen Koch wrote: > The license says that derivative work has to be GPL. Naturally, every > sensible and practically usable license has gray areas. We know that > and we live with that. But if there's room for interpretation, it's > perfectly OK and helpful, if the copyright holder states what his > interpretation is. If you use an EXPORT_SYMBOL_GPL symbol in non-GPL > code, you know that the owner of the work doesn't agree with you > license-wise. How can an author form the opinion that another work is derivative, when it hasn't even necessarily been written yet? EXPORT_SYMBOL_GPL is no statement of the author's beliefs. It's an algorithm of restriction, and it affects original, non-derivative works. >> It requires software that is *distributed* as part of a GPL >> work to itself be GPL. At time of distribution, a kernel module is >> neither using nor linked to the kernel. >> > > Oh, come on! You cannot turn a derived work into an original work just > by distributing them seperately. That's not what I said. From the start, I've made clear that I'm talking of original, non-derivative works. You said that mere linking makes that non-derivative work derivative: > Using a symbol from a library means linking to it, and that creates a > derived work. Why should it be different when using kernel symbols? This is wrong for the reasons I stated. -- 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/
Re: [GIT] Please pull 2 NFS client fixes
On Thu, 07 Feb 2008 20:07:21 -0500 Trond Myklebust <[EMAIL PROTECTED]> wrote:
> commit 5d47a35600270e7115061cb1320ee60ae9bcb6b8
> Author: Trond Myklebust <[EMAIL PROTECTED]>
> Date: Thu Feb 7 17:24:07 2008 -0500
>
> NFS: Fix a potential file corruption issue when writing
>
> If the inode is flagged as having an invalid mapping, then we can't rely
> on
> the PageUptodate() flag. Ensure that we don't use the "anti-fragmentation"
> write optimisation in nfs_updatepage(), since that will cause NFS to write
> out areas of the page that are no longer guaranteed to be up to date.
>
> A potential corruption could occur in the following scenario:
>
> client 1 client 2
> === ===
> fd=open("f",O_CREAT|O_WRONLY,0644);
> write(fd,"fubar\n",6); // cache last page
> close(fd);
> fd=open("f",O_WRONLY|O_APPEND);
> write(fd,"foo\n",4);
> close(fd);
>
> fd=open("f",O_WRONLY|O_APPEND);
> write(fd,"bar\n",4);
> close(fd);
> -
> The bug may lead to the file "f" reading 'fubar\n\0\0\0\nbar\n' because
> client 2 does not update the cached page after re-opening the file for
> write. Instead it keeps it marked as PageUptodate() until someone calls
> invaldate_inode_pages2() (typically by calling read()).
Is this one worth feeding back into 2.6.24.x? (for various values of "4"?)
--
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/
[git pull] device-mapper update for 2.6.25
Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/agk/linux-2.6-dm.git to get the following device-mapper update for 2.6.25: Alasdair G Kergon (5): dm: mark function lists static dm ioctl: remove lock_kernel dm: targets no longer experimental dm mpath: add missing static dm crypt: move queue functions Andrew Morton (3): dm snapshot: use uninitialized_var dm: table use uninitialized_var dm ioctl: use uninitialized_var Brian Wood (2): dm: stripe trigger event on failure dm: stripe enhanced status return Daniel Walker (1): dm: convert suspend_lock semaphore to mutex Jonathan Brassow (6): dm log: auto load modules dm raid1: handle write failures dm raid1: handle recovery failures dm raid1: fix EIO after log failure dm raid1: handle read failures dm raid1: report fault status Jun'ichi Nomura (1): dm: table remove unused total Milan Broz (23): dm: add missing memory barrier to dm_suspend dm ioctl: move compat code dm: tidy alloc_dev labels dm: refactor deferred bio_list processing dm: tidy dm_suspend dm: split dm_suspend io_lock hold into two dm: refactor dm_suspend completion wait dm crypt: move convert_context inside dm_crypt_io dm crypt: remove unnecessary crypt_context write parm dm crypt: move error setting outside crypt_dec_pending dm crypt: tidy crypt_endio dm crypt: adjust io processing functions dm crypt: store sector mapping in dm_crypt_io dm crypt: abstract crypt_write_done dm crypt: introduce crypt_write_io_loop dm crypt: tidy io ref counting dm crypt: extract scatterlist processing dm crypt: add async request mempool dm crypt: add completion for async dm crypt: prepare async callback fn dm crypt: use async crypto dm: move deferred bio flushing to workqueue dm snapshot: combine consecutive exceptions in memory Paul Jimenez (1): dm: table use list_for_each Robert P. J. Day (1): dm snapshot: use rounddown_pow_of_two Vasily Averin (1): dm: table remove unused variable drivers/md/Kconfig | 24 +- drivers/md/dm-crypt.c | 486 +++-- drivers/md/dm-exception-store.c |2 +- drivers/md/dm-ioctl.c | 32 ++- drivers/md/dm-log.c | 51 +++- drivers/md/dm-mpath.c |2 +- drivers/md/dm-raid1.c | 664 +- drivers/md/dm-snap.c| 95 -- drivers/md/dm-snap.h| 50 +++- drivers/md/dm-stripe.c | 105 ++- drivers/md/dm-table.c | 20 +- drivers/md/dm.c | 238 +-- fs/compat_ioctl.c | 34 -- include/linux/device-mapper.h | 18 +- include/linux/dm-ioctl.h| 34 +-- 15 files changed, 1372 insertions(+), 483 deletions(-) Alasdair -- [EMAIL PROTECTED] -- 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/
Re: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Thu, 07 Feb 2008 18:56:46 -0600 James Bottomley <[EMAIL PROTECTED]> wrote:
> Quite a bit of this is fixing things broken previously (the advansys fix
> is still pending resolution, but I'll send it as an -rc fix when we have
> it). There's the final elimination of all drivers that are esp based
> but don't use the scsi_esp core (that's mostly m68k and alpha). Plus
> the usual bunch of driver updates and the addition of a new enclosure
> services driver and the corresponding ULD.
Sob. Can we please merge "Convert SG from nopage to fault"? It has been
sent three times, the first time was Dec 5 last year and it has thus far
received the lead balloon treatment. Despite my explicit request for
consideration last time I sent it
If there is no movement here then I have to carry the moderately intrusive
mm-remove-nopage.patch for another N months and we need to watch out for
new ->nopage implementations popping up etc.
From: Nick Piggin <[EMAIL PROTECTED]>
Convert SG from nopage to fault.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Cc: Douglas Gilbert <[EMAIL PROTECTED]>
Cc: James Bottomley <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/scsi/sg.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff -puN drivers/scsi/sg.c~sg-nopage drivers/scsi/sg.c
--- a/drivers/scsi/sg.c~sg-nopage
+++ a/drivers/scsi/sg.c
@@ -1160,23 +1160,22 @@ sg_fasync(int fd, struct file *filp, int
return (retval < 0) ? retval : 0;
}
-static struct page *
-sg_vma_nopage(struct vm_area_struct *vma, unsigned long addr, int *type)
+static int
+sg_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
Sg_fd *sfp;
- struct page *page = NOPAGE_SIGBUS;
unsigned long offset, len, sa;
Sg_scatter_hold *rsv_schp;
struct scatterlist *sg;
int k;
if ((NULL == vma) || (!(sfp = (Sg_fd *) vma->vm_private_data)))
- return page;
+ return VM_FAULT_SIGBUS;
rsv_schp = >reserve;
- offset = addr - vma->vm_start;
+ offset = vmf->pgoff << PAGE_SHIFT;
if (offset >= rsv_schp->bufflen)
- return page;
- SCSI_LOG_TIMEOUT(3, printk("sg_vma_nopage: offset=%lu, scatg=%d\n",
+ return VM_FAULT_SIGBUS;
+ SCSI_LOG_TIMEOUT(3, printk("sg_vma_fault: offset=%lu, scatg=%d\n",
offset, rsv_schp->k_use_sg));
sg = rsv_schp->buffer;
sa = vma->vm_start;
@@ -1185,21 +1184,21 @@ sg_vma_nopage(struct vm_area_struct *vma
len = vma->vm_end - sa;
len = (len < sg->length) ? len : sg->length;
if (offset < len) {
+ struct page *page;
page = virt_to_page(page_address(sg_page(sg)) + offset);
get_page(page); /* increment page count */
- break;
+ vmf->page = page;
+ return 0; /* success */
}
sa += len;
offset -= len;
}
- if (type)
- *type = VM_FAULT_MINOR;
- return page;
+ return VM_FAULT_SIGBUS;
}
static struct vm_operations_struct sg_mmap_vm_ops = {
- .nopage = sg_vma_nopage,
+ .fault = sg_vma_fault,
};
static int
_
--
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/
Module loading/unloading and "The Stop Machine"
Hi Rusty, I was hopping you could answer a couple of questions about module loading/unloading and the stop machine. There was a recent discussion on LKML about CPU isolation patches I'm working on. One of the patches makes stop machine ignore the isolated CPUs. People of course had questions about that. So I started looking into more details and got this silly, crazy idea that maybe we do not need the stop machine any more :) As far as I can tell the stop machine is basically a safety net in case some locking and recounting mechanisms aren't bullet proof. In other words if a subsystem can actually handle registration/unregistration in a robust way, module loader/unloader does not necessarily have to halt entire machine in order to load/unload a module that belongs to that subsystem. I may of course be completely wrong on that. The problem with the stop machine is that it's a very very big gun :). In a sense that it totally kills all the latencies and stuff since the entire machine gets halted while module is being (un)loaded. Which is a major issue for any realtime apps. Specifically for CPU isolation the issue is that high-priority rt user-space thread prevents stop machine threads from running and entire box just hangs waiting for it. I'm kind of surprised that folks who use monster boxes with over 100 CPUs have not complained. It's must be a huge hit for those machines to halt the entire thing. It seems that over the last few years most subsystems got much better at locking and refcounting. And I'm hopping that we can avoid halting the entire machine these days. For CPU isolation in particular the solution is simple. We can just ignore isolated CPUs. What I'm trying to figure out is how safe it is and whether we can avoid full halt altogether. So. Here is what I tried today on my Core2 Duo laptop > --- a/kernel/stop_machine.c > +++ b/kernel/stop_machine.c > @@ -204,11 +204,14 @@ int stop_machine_run(int (*fn)(void *), void *data, > unsigned int cpu) > > /* No CPUs can come up or down during this. */ > lock_cpu_hotplug(); > +/* > p = __stop_machine_run(fn, data, cpu); > if (!IS_ERR(p)) > ret = kthread_stop(p); > else > ret = PTR_ERR(p); > +*/ > + ret = fn(data); > unlock_cpu_hotplug(); > > return ret; ie Completely disabled stop machine. It just loads/unloads modules without full halt. I then ran three scripts: while true; do /sbin/modprobe -r uhci_hcd /sbin/modprobe uhci_hcd sleep 10 done while true; do /sbin/modprobe -r tg3 /sbin/modprobe tg3 sleep 2 done while true; do /usr/sbin/tcpdump -i eth0 done The machine has a bunch of USB devices connected to it. The two most interesting are a Bluetooth dongle and a USB mouse. By loading/unloading UHCI driver we're touching Sysfs, USB stack, Bluetooth stack, HID layer, Input layer. The X is running and is using that USB mouse. The Bluetooth services are running too. By loading/unloading TG3 driver we're touching sysfs, network stack (a bunch of layers). The machine is running NetworkManager and tcpdumping on the eth0 which is registered by TG3. This is a pretty good stress test in general let alone the disabled stop machine. I left all that running for the whole day while doing normal day to day things. Compiling a bunch of things, emails, office apps, etc. That's where I'm writing this email from :). It's still running all that :) So the question is do we still need stop machine ? I must be missing something obvious. But things seem to be working pretty well without it. I certainly feel much better about at least ignoring isolated CPUs during stop machine execution. Which btw I've doing for a couple of years now on a wide range of the machines where people are inserting modules left and right. What do you think ? Thanx Max -- 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/
Re: [PATCH] Change pci_raw_ops to pci_raw_read/write
On Thu, Feb 07, 2008 at 11:36:18AM -0500, Tony Camuso wrote: > Arjan van de Ven wrote: >> On Thu, 07 Feb 2008 10:54:05 -0500 >> Tony Camuso <[EMAIL PROTECTED]> wrote: >>> Matthew, >>> >>> Perhaps I missed it, but did you address Yinghai's concerns? >>> >>> Yinghai Lu wrote: On Jan 28, 2008 7:03 PM, Matthew Wilcox <[EMAIL PROTECTED]> wrote: > -int pci_conf1_write(unsigned int seg, unsigned int bus, > +static int pci_conf1_write(unsigned int seg, unsigned int bus, >unsigned int devfn, int reg, int len, > u32 value) any reason to change pci_conf1_read/write to static? >> nothing should use these directly. So static is the right answer ;) > > Agreed. Thanks, Arjan. > > Matthew, > What about the ATA_RAM addition to Kconfig? Was it accidental, > or intended? If intended, how is it related? AFAICT, it looks accidental. I can't see how it's related. He should be back online next week and can answer for himself. hth, grant -- 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/
[GIT PULL] XFS update for 2.6.25
Please pull from the for-linus branch: git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus This will update the following files: fs/xfs/Makefile-linux-2.6 |1 - fs/xfs/linux-2.6/spin.h| 45 --- fs/xfs/linux-2.6/xfs_aops.c| 43 ++- fs/xfs/linux-2.6/xfs_buf.c | 57 +--- fs/xfs/linux-2.6/xfs_buf.h |1 - fs/xfs/linux-2.6/xfs_export.c | 25 +- fs/xfs/linux-2.6/xfs_file.c|3 +- fs/xfs/linux-2.6/xfs_globals.c |3 +- fs/xfs/linux-2.6/xfs_ioctl.c | 86 ++--- fs/xfs/linux-2.6/xfs_ioctl32.c |9 +- fs/xfs/linux-2.6/xfs_iops.c| 170 +++-- fs/xfs/linux-2.6/xfs_linux.h | 34 +-- fs/xfs/linux-2.6/xfs_lrw.c | 122 +++ fs/xfs/linux-2.6/xfs_lrw.h | 16 +- fs/xfs/linux-2.6/xfs_super.c | 572 +++-- fs/xfs/linux-2.6/xfs_vnode.c | 117 +++ fs/xfs/linux-2.6/xfs_vnode.h | 62 ++-- fs/xfs/quota/xfs_dquot.c | 12 +- fs/xfs/quota/xfs_dquot.h |5 - fs/xfs/quota/xfs_dquot_item.c | 27 +- fs/xfs/quota/xfs_qm.c | 14 +- fs/xfs/quota/xfs_qm.h |6 +- fs/xfs/quota/xfs_qm_syscalls.c | 19 +- fs/xfs/support/debug.c |7 +- fs/xfs/support/ktrace.c|8 +- fs/xfs/support/ktrace.h|3 - fs/xfs/support/uuid.c |2 +- fs/xfs/xfs.h |2 +- fs/xfs/xfs_acl.c | 30 +-- fs/xfs/xfs_acl.h |2 - fs/xfs/xfs_ag.h|2 +- fs/xfs/xfs_alloc.c | 19 +- fs/xfs/xfs_attr.c |2 +- fs/xfs/xfs_attr_leaf.c |8 +- fs/xfs/xfs_bit.c | 103 -- fs/xfs/xfs_bit.h | 27 ++- fs/xfs/xfs_bmap.c | 22 +- fs/xfs/xfs_bmap.h |2 + fs/xfs/xfs_bmap_btree.c|3 +- fs/xfs/xfs_btree.h |2 + fs/xfs/xfs_buf_item.c | 10 +- fs/xfs/xfs_buf_item.h |2 + fs/xfs/xfs_da_btree.c | 13 +- fs/xfs/xfs_da_btree.h |1 + fs/xfs/xfs_dfrag.c | 84 ++--- fs/xfs/xfs_dinode.h| 82 ++--- fs/xfs/xfs_dir2.c |3 +- fs/xfs/xfs_error.c | 31 -- fs/xfs/xfs_error.h |2 + fs/xfs/xfs_extfree_item.c | 21 +- fs/xfs/xfs_filestream.c|2 +- fs/xfs/xfs_fs.h| 10 +- fs/xfs/xfs_fsops.c | 13 +- fs/xfs/xfs_ialloc_btree.h |2 - fs/xfs/xfs_iget.c | 185 -- fs/xfs/xfs_inode.c | 225 +++- fs/xfs/xfs_inode.h | 98 ++--- fs/xfs/xfs_inode_item.c| 26 +- fs/xfs/xfs_iocore.c| 119 -- fs/xfs/xfs_iomap.c | 212 ++-- fs/xfs/xfs_iomap.h |5 +- fs/xfs/xfs_itable.c| 12 +- fs/xfs/xfs_log.c | 416 ++--- fs/xfs/xfs_log.h |3 +- fs/xfs/xfs_log_priv.h | 96 ++--- fs/xfs/xfs_log_recover.c | 197 +-- fs/xfs/xfs_mount.c | 344 ++ fs/xfs/xfs_mount.h | 127 +-- fs/xfs/xfs_mru_cache.c | 54 ++-- fs/xfs/xfs_qmops.c |7 +- fs/xfs/xfs_rename.c|9 +- fs/xfs/xfs_rtalloc.c | 19 +- fs/xfs/xfs_rtalloc.h |2 - fs/xfs/xfs_rw.h| 12 +- fs/xfs/xfs_trans.c |7 +- fs/xfs/xfs_trans.h |7 +- fs/xfs/xfs_trans_ail.c | 340 +++-- fs/xfs/xfs_trans_item.c|1 + fs/xfs/xfs_trans_priv.h| 13 +- fs/xfs/xfs_utils.c | 11 +- fs/xfs/xfs_utils.h |2 - fs/xfs/xfs_vfsops.c| 793 ++-- fs/xfs/xfs_vfsops.h|9 +- fs/xfs/xfs_vnodeops.c | 165 +++-- fs/xfs/xfs_vnodeops.h |2 - 85 files changed, 2303 insertions(+), 3184 deletions(-) delete mode 100644 fs/xfs/linux-2.6/spin.h delete mode 100644 fs/xfs/xfs_iocore.c through these commits: commit de2eeea609b55e8c3994133a565b39edef69 Author: Lachlan McIlroy <[EMAIL PROTECTED]> Date: Wed Feb 6 13:37:56 2008 +1100 [XFS] add __init/__exit mark to specific init/cleanup functions SGI-PV: 971186 SGI-Modid: xfs-linux-melb:xfs-kern:30459a Signed-off-by: Lachlan McIlroy <[EMAIL PROTECTED]> Signed-off-by: Denis Cheng <[EMAIL PROTECTED]> commit 450790a2c51e6d9d47ed30dbdcf486656b8e186f Author: David Chinner <[EMAIL PROTECTED]> Date: Wed Feb 6 13:37:40 2008 +1100 [XFS] Fix oops in xfs_file_readdir() When xfs_file_readdir() exactly fills a buffer, it can move it's index past the end of the buffer and dereference it even though the result of the dereference is never used. On some platforms this causes an oops. SGI-PV: 976923 SGI-Modid: xfs-linux-melb:xfs-kern:30458a Signed-off-by: David Chinner <[EMAIL PROTECTED]>
RE: [patch 13/45] USB: sierra: add support for Onda H600/Zte MF330datacard to USB Driver for Sierra Wireless
> 2.6.24-stable review patch. If anyone has any objections, please let us > know. > > -- > From: Bruno Redondi <[EMAIL PROTECTED]> > > Added support for Onda H600/Zte MF330 GPRS/UMTS/HSDPA datacard Per our earlier discussion we probably don't want to have this one in the Sierra driver. -- 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/
[PATCH] Fix FRV cmpxchg_local
Fix the FRV cmpxchg_local by breaking the following header dependency loop :
linux/kernel.h -> linux/bitops.h -> asm-frv/bitops.h -> asm-frv/atomic.h
-> asm-frv/system.h ->
asm-generic/cmpxchg_local.h -> typecheck() defined in linux/kernel.h
and
linux/kernel.h -> linux/bitops.h -> asm-frv/bitops.h -> asm-frv/atomic.h ->
asm-generic/cmpxchg_local.h -> typecheck() defined in linux/kernel.h
In order to fix this :
- Move the atomic_test_and_ *_mask inlines from asm-frv/atomic.h (why are they
there at all anyway ? They are not touching atomic_t variables!) to
asm-frv/bitops.h.
Also fix a build issue with cmpxchg : it does not cast to (unsigned long *)
like other architectures, to deal with it in the cmpxchg_local macro.
FRV builds fine with this patch.
Thanks to Adrian Bunk <[EMAIL PROTECTED]> for spotting this bug.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: Adrian Bunk <[EMAIL PROTECTED]>
---
include/asm-frv/atomic.h | 81 -
include/asm-frv/bitops.h | 83 +--
include/asm-frv/system.h |3 +
3 files changed, 83 insertions(+), 84 deletions(-)
Index: linux-2.6-lttng/include/asm-frv/atomic.h
===
--- linux-2.6-lttng.orig/include/asm-frv/atomic.h 2008-02-07
17:29:09.0 -0500
+++ linux-2.6-lttng/include/asm-frv/atomic.h2008-02-07 17:32:05.0
-0500
@@ -125,87 +125,6 @@
#define atomic_dec_and_test(v) (atomic_sub_return(1, (v)) == 0)
#define atomic_inc_and_test(v) (atomic_add_return(1, (v)) == 0)
-#ifndef CONFIG_FRV_OUTOFLINE_ATOMIC_OPS
-static inline
-unsigned long atomic_test_and_ANDNOT_mask(unsigned long mask, volatile
unsigned long *v)
-{
- unsigned long old, tmp;
-
- asm volatile(
- "0: \n"
- " orccgr0,gr0,gr0,icc3\n" /* set
ICC3.Z */
- " ckeqicc3,cc7\n"
- " ld.p%M0,%1 \n" /*
LD.P/ORCR are atomic */
- " orcrcc7,cc7,cc3 \n" /* set
CC3 to true */
- " and%I3 %1,%3,%2\n"
- " cst.p %2,%M0 ,cc3,#1 \n" /* if
store happens... */
- " corcc gr29,gr29,gr0 ,cc3,#1 \n" /* ...
clear ICC3.Z */
- " beq icc3,#0,0b \n"
- : "+U"(*v), "="(old), "=r"(tmp)
- : "NPr"(~mask)
- : "memory", "cc7", "cc3", "icc3"
- );
-
- return old;
-}
-
-static inline
-unsigned long atomic_test_and_OR_mask(unsigned long mask, volatile unsigned
long *v)
-{
- unsigned long old, tmp;
-
- asm volatile(
- "0: \n"
- " orccgr0,gr0,gr0,icc3\n" /* set
ICC3.Z */
- " ckeqicc3,cc7\n"
- " ld.p%M0,%1 \n" /*
LD.P/ORCR are atomic */
- " orcrcc7,cc7,cc3 \n" /* set
CC3 to true */
- " or%I3 %1,%3,%2\n"
- " cst.p %2,%M0 ,cc3,#1 \n" /* if
store happens... */
- " corcc gr29,gr29,gr0 ,cc3,#1 \n" /* ...
clear ICC3.Z */
- " beq icc3,#0,0b \n"
- : "+U"(*v), "="(old), "=r"(tmp)
- : "NPr"(mask)
- : "memory", "cc7", "cc3", "icc3"
- );
-
- return old;
-}
-
-static inline
-unsigned long atomic_test_and_XOR_mask(unsigned long mask, volatile unsigned
long *v)
-{
- unsigned long old, tmp;
-
- asm volatile(
- "0: \n"
- " orccgr0,gr0,gr0,icc3\n" /* set
ICC3.Z */
- " ckeqicc3,cc7\n"
- " ld.p%M0,%1 \n" /*
LD.P/ORCR are atomic */
- " orcrcc7,cc7,cc3 \n" /* set
CC3 to true */
- " xor%I3 %1,%3,%2\n"
- " cst.p %2,%M0 ,cc3,#1 \n" /* if
store happens... */
- " corcc gr29,gr29,gr0 ,cc3,#1 \n" /* ...
clear ICC3.Z */
- " beq icc3,#0,0b \n"
- : "+U"(*v), "="(old), "=r"(tmp)
- : "NPr"(mask)
- : "memory", "cc7", "cc3", "icc3"
- );
-
- return old;
-}
-
-#else
-
-extern unsigned long
Re: + smack-unlabeled-outgoing-ambient-packets.patch added to -mm tree
On Thursday 07 February 2008 9:15:19 pm David Miller wrote: > From: Paul Moore <[EMAIL PROTECTED]> > Date: Thu, 7 Feb 2008 20:54:56 -0500 > > > I have no idea what was causing the mail problem, probably somebody > > in our IT department playing around with some new knobs, oh well. I > > resubscribed this afternoon with both fingers crossed. > > In the future please contact [EMAIL PROTECTED] when you > notice you have been unsubscribed so we can work on fixing the > issue. > > Blind resubscriptions are severely frowned upon, we remove you for > good reason and if the problem isn't solved you'll just soil up my > inbox further with bounces Both points noted for future reference. While the end result is the same, I can promise you my actions are not maliciously stupid, just ignorantly stupid ;) -- paul moore linux security @ hp -- 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/
Re: [PATCH] isdn: fix section mismatch warning in enpci_card_msg
From: Sam Ravnborg <[EMAIL PROTECTED]> Date: Fri, 1 Feb 2008 14:42:42 +0100 > Fix following warnings: > WARNING: drivers/isdn/hisax/built-in.o(.text+0x3cf50): Section mismatch in > reference from the function enpci_card_msg() to the function > .devinit.text:Amd7930_init() > WARNING: drivers/isdn/hisax/built-in.o(.text+0x3cf85): Section mismatch in > reference from the function enpci_card_msg() to the function > .devinit.text:Amd7930_init() > > enpci_card_msg() can be called outside __devinit context > referenced function should not be annotated __devinit. > > Remove annotation of Amd7930_init to fix this. > > Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> Applied, thanks. -- 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/
Re: + smack-unlabeled-outgoing-ambient-packets.patch added to -mm tree
From: Paul Moore <[EMAIL PROTECTED]> Date: Thu, 7 Feb 2008 20:54:56 -0500 > I have no idea what was causing the mail problem, probably somebody > in our IT department playing around with some new knobs, oh well. I > resubscribed this afternoon with both fingers crossed. In the future please contact [EMAIL PROTECTED] when you notice you have been unsubscribed so we can work on fixing the issue. Blind resubscriptions are severely frowned upon, we remove you for good reason and if the problem isn't solved you'll just soil up my inbox further with bounces -- 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/
[git pull] more SLUB updates for 2.6.25
are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/christoph/vm.git slub-linus (includes the cmpxchg_local fastpath since the cmpxchg_local work by Matheiu is in now, and the non atomic unlock by Nick. Verified that this is not doing any harm after some other patches had been removed. cmpxchg_local fastpath was stripped of support for CONFIG_PREEMPT since that uglified the code and did not seem to work right. We will be able to handle preempt much better in the future with some upcoming patches) Christoph Lameter (4): SLUB: Deal with annoying gcc warning on kfree() SLUB: Use unique end pointer for each slab page. SLUB: Alternate fast paths using cmpxchg_local SLUB: Support for performance statistics Ingo Molnar (1): SLUB: fix checkpatch warnings Nick Piggin (1): Use non atomic unlock Documentation/vm/slabinfo.c | 149 ++-- arch/x86/Kconfig|4 + include/linux/mm_types.h|5 +- include/linux/slub_def.h| 23 +++ lib/Kconfig.debug | 13 ++ mm/slub.c | 326 --- 6 files changed, 457 insertions(+), 63 deletions(-) -- 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/
Re: [PATCH] [IPV6] Minor cleanup: remove unused definitions in net/ip6_fib.h
From: "Rami Rosen" <[EMAIL PROTECTED]> Date: Thu, 7 Feb 2008 18:23:58 +0200 > Hi, > > This patch removes some unused definitions and one method typedef > declaration (f_pnode) > in include/net/ip6_fib.h, as they are not used in the kernel. > > Signed-off-by: Rami Rosen <[EMAIL PROTECTED]> Applied, thanks. -- 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/
Re: [PATCH] [IPV6] Minor clenup: remove two unused definitions in net/ip6_route.h
From: "Rami Rosen" <[EMAIL PROTECTED]> Date: Thu, 7 Feb 2008 17:58:07 +0200 > Remove IP6_RT_PRIO_FW and IP6_RT_FLOW_MASK definitions in > include/net/ip6_route.h, as they are not used in the kernel. > > Signed-off-by: Rami Rosen <[EMAIL PROTECTED]> Applied. If you grep for "fc_metric" in the tree you'll see some explicit uses of the magic constant "1024" which probably should be replaced with IP6_RT_PRIO_USER. If you could verify that and cook up a patch if correct, I'd appreciate it. Thanks. -- 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/
Re: ACPI_WMI: worst config description of all times
On Friday 08 February 2008 01:38:01 Ray Lee wrote: > That's clear to me (whereas the original wasn't), though I would > still argue for this driver being select'ed by the drivers that > require it. As you note, other laptop specific drivers do so, and > Linus has come down in favor of that as well in the past, so you have > a friend in high places :-). I have some other patches lined up to do so. Unless I hear some arguments against it, or some better alternatives, I'll put them together with this and get Len to apply them to the ACPI tree (and then hopefully push back out before the -rc1 release). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
[PATCH] knfsd: Remove NLM_HOST_MAX and associated logic.
Lockd caches information about hosts that have recently held locks it expedite the taking of further locks. It periodically discards this information for hosts that have not been used for a few minutes. lockd currently has a value NLM_HOST_MAX, and changes the 'garbage collection' behaviour when the number of hosts exceeds this threshold. However it's behaviour in strange an likely not what was intended. When the number of hosts exceeds the max, it scans *less* often (every 2 minutes vs every minute) and allows unused host information to remain around longer (5 minutes instead of 2). Having this limit is of dubious value anyway, and we have not suffered from the code not getting the limit right, so remove the limit altogether. We go with the larger values (discard 5 minute old hosts every 2 minutes) as that is probably safer. Maybe the periodic garbage collection should be replace to with 'shrinker' handler so we just respond to memory pressure Acked-by: Jeff Layton <[EMAIL PROTECTED]> Signed-off-by: Neil Brown <[EMAIL PROTECTED]> ### Diffstat output ./fs/lockd/host.c |9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff .prev/fs/lockd/host.c ./fs/lockd/host.c --- .prev/fs/lockd/host.c 2008-02-07 14:20:54.0 +1100 +++ ./fs/lockd/host.c 2008-02-08 12:54:28.0 +1100 @@ -19,12 +19,11 @@ #define NLMDBG_FACILITYNLMDBG_HOSTCACHE -#define NLM_HOST_MAX 64 #define NLM_HOST_NRHASH32 #define NLM_ADDRHASH(addr) (ntohl(addr) & (NLM_HOST_NRHASH-1)) #define NLM_HOST_REBIND(60 * HZ) -#define NLM_HOST_EXPIRE((nrhosts > NLM_HOST_MAX)? 300 * HZ : 120 * HZ) -#define NLM_HOST_COLLECT ((nrhosts > NLM_HOST_MAX)? 120 * HZ : 60 * HZ) +#define NLM_HOST_EXPIRE(300 * HZ) +#define NLM_HOST_COLLECT (120 * HZ) static struct hlist_head nlm_hosts[NLM_HOST_NRHASH]; static unsigned long next_gc; @@ -142,9 +141,7 @@ nlm_lookup_host(int server, const struct INIT_LIST_HEAD(>h_granted); INIT_LIST_HEAD(>h_reclaim); - if (++nrhosts > NLM_HOST_MAX) - next_gc = 0; - + nrhosts++; out: mutex_unlock(_host_mutex); return host; -- 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/
Re: + smack-unlabeled-outgoing-ambient-packets.patch added to -mm tree
On Thursday 07 February 2008 8:34:02 pm David Miller wrote: > From: Paul Moore <[EMAIL PROTECTED]> > Date: Thu, 7 Feb 2008 15:14:34 -0500 > > > My apologies, those mailing list postings there haven't hit my inbox yet. > > I had to remove you a few days ago, see my other reply to > Andrew. > > You are back on the lists now, so I hope that bounce problem > has been solved. Yeah, that discussion with Andrew made me look a bit deeper at my mail folders and I realized the last message I received from any of the vger.kernel.org mailing lists was late Tuesday night ... I thought Wednesday was awfully quiet :/ I have no idea what was causing the mail problem, probably somebody in our IT department playing around with some new knobs, oh well. I resubscribed this afternoon with both fingers crossed. -- paul moore linux security @ hp -- 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/
Re: Kernel Panic in MPT SAS on 2.6.24 (and 2.6.23.14, 2.6.23.9)
Just noticed that Eric's address was wrong, so resend with corrected Cc. Eric, my intial report was http://lkml.org/lkml/2008/2/6/300 > Am Thursday, den 7 February hub Krzysztof Oledzki folgendes in die Tasten: > > Hi! > > > >While installing my new firewall I got the following kernel panic in > > >the MPT SAS driver which I need for the disks. > > > >The first kernel I bootet was 2.6.23.14 which did panic so I tried a > > >2.6.24 which panics, too. Our usual FAI kernel (2.6.23.9) is also > > >affected. > > > Could you please try 2.6.22-stable? > > Yes it works :-/ > > I've put some things which on the web which might be helpful: > > dmesg http://files.rfc2324.org/mptsas_panic/2.6.22-dmesg > lspci -v http://files.rfc2324.org/mptsas_panic/2.6.22-lspci-v > .config http://files.rfc2324.org/mptsas_panic/2.6.22-config > > I'll search for the last working kernel and try to break it down to a > commit tommorow when I can get a serial console or direct access. > The Java driven console redirection is everything else than fulfilling :-( > > > It looks *very* similar to my problem: > > > http://bugzilla.kernel.org/show_bug.cgi?id=9909 > > It seems to be the same controller: > > 01:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068E > PCI-Express Fusion-MPT SAS (rev 08) > Subsystem: Dell Unknown device 1f10 > Flags: bus master, fast devsel, latency 0, IRQ 16 > I/O ports at ec00 [size=256] > Memory at fc8fc000 (64-bit, non-prefetchable) [size=16K] > Memory at fc8e (64-bit, non-prefetchable) [size=64K] > Expansion ROM at fc90 [disabled] [size=1M] > Capabilities: [50] Power Management version 2 > Capabilities: [68] Express Endpoint IRQ 0 > Capabilities: [98] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 > Enable- > Capabilities: [b0] MSI-X: Enable- Mask- TabSize=1 > > Stay tuned. > > Ciao > Max -- Follow the white penguin. -- 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/
Re: ACPI_WMI: worst config description of all times
On Feb 7, 2008 5:19 PM, Carlos Corbacho <[EMAIL PROTECTED]> wrote: > On Friday 08 February 2008 00:12:24 Ray Lee wrote: > > On Feb 7, 2008 3:51 PM, Carlos Corbacho <[EMAIL PROTECTED]> wrote: > > > On Thursday 07 February 2008 23:33:54 Ray Lee wrote: > > > > Do you have list of hardware/platforms that require this feature to > > > > get the hardware to work? (acer abc123, tcm1100 xyz) > > > > > > I have a very long list of Acer laptops that are supported - which is far > > > too long, and changes on far too much of a regular basis to put in there. > > > > > > Perhaps adding something like "This driver is also a required dependency > > > to build the firmware specific drivers needed for many laptops, including > > > Acer and HP machines"? > > Would this be acceptable then? > > -Carlos > --- > ACPI: WMI: Improve Kconfig entry > > From: Carlos Corbacho <[EMAIL PROTECTED]> > > As Pavel Machek has pointed out, the Kconfig entry for WMI is pretty > non-descriptive. > > Rewrite it so that it explains what ACPI-WMI is, and why anyone > would want to enable it. > > Many thanks to Ray Lee for ideas on this. > > Signed-off-by: Carlos Corbacho <[EMAIL PROTECTED]> > CC: Pavel Machek <[EMAIL PROTECTED]> > CC: Ray Lee <[EMAIL PROTECTED]> > CC: Len Brown <[EMAIL PROTECTED]> > --- > > drivers/acpi/Kconfig | 19 +++ > 1 files changed, 15 insertions(+), 4 deletions(-) > > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig > index b7fbf16..ea763ef 100644 > --- a/drivers/acpi/Kconfig > +++ b/drivers/acpi/Kconfig > @@ -207,11 +207,22 @@ config ACPI_WMI > depends on EXPERIMENTAL > depends on X86 > help > - This driver adds support for the ACPI-WMI mapper device (PNP0C14) > - found on some systems. > + This driver adds support for the ACPI-WMI (Windows Management > + Instrumentation) mapper device (PNP0C14) found on some systems. > > - NOTE: You will need another driver or userspace application on top > of > - this to actually use anything defined in the ACPI-WMI mapper. > + ACPI-WMI is a proprietary extension to ACPI to expose parts of the > + ACPI firmware to userspace - this is done through various vendor > + defined methods and data blocks in a PNP0C14 device, which are then > + made available for userspace to call. > + > + The implementation of this in Linux currently only exposes this to > + other kernel space drivers. > + > + This driver is a required dependency to build the firmware specific > + drivers needed on many machines, including Acer and HP laptops. > + > + It is safe to enable this driver even if your DSDT doesn't define > + any ACPI-WMI devices. > > config ACPI_ASUS > tristate "ASUS/Medion Laptop Extras" > That's clear to me (whereas the original wasn't), though I would still argue for this driver being select'ed by the drivers that require it. As you note, other laptop specific drivers do so, and Linus has come down in favor of that as well in the past, so you have a friend in high places :-). -- 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/
Re: [stable] [patch 00/45] 2.6.24-stable review
On Fri, Feb 08, 2008 at 12:24:57PM +1100, David Chinner wrote: > On Thu, Feb 07, 2008 at 05:12:30PM -0800, Greg KH wrote: > > On Fri, Feb 08, 2008 at 11:44:30AM +1100, David Chinner wrote: > > > Greg, > > > > > > Is there any reason why the XFS patch I sent to the stable list a > > > couple of days ago is not included in this series? > > > > > > http://oss.sgi.com/archives/xfs/2008-02/msg00027.html > > > > > > We've had multiple reports of it, and multiple confirmations that > > > the patch in the link above fixes the problem. > > > > I didn't think it was in Linus's tree yet. Is it? > > Not yet - it's in the pipeline. I'll see if that can be sped > up (someone else usually takes care of the pushes to Linus). Then we did our job right and didn't take it :) Please resend it after it gets into Linus's tree, not before, I'm really tired of checking for these things constantly... thanks, greg k-h -- 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/
Re: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Thu, 2008-02-07 at 18:56 -0600, James Bottomley wrote:
> Quite a bit of this is fixing things broken previously (the advansys fix
> is still pending resolution, but I'll send it as an -rc fix when we have
> it). There's the final elimination of all drivers that are esp based
> but don't use the scsi_esp core (that's mostly m68k and alpha). Plus
> the usual bunch of driver updates and the addition of a new enclosure
> services driver and the corresponding ULD.
OK, the advansys fix came in. I've added it to the patch.
James
>From f983323fea178352ed3b69c70561a13825a3ce59 Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Date: Fri, 8 Feb 2008 09:50:08 +0900
Subject: [SCSI] advansys: fix overrun_buf aligned bug
struct asc_dvc_var needs overrun buffer to be placed on an 8 byte
boundary. advansys defines struct asc_dvc_var:
struct asc_dvc_var {
...
uchar overrun_buf[ASC_OVERRUN_BSIZE] __aligned(8);
The problem is that struct asc_dvc_var is placed on
shost->hostdata. So if the hostdata is not on an 8 byte boundary, the
advansys crashes. The hostdata is placed on a sizeof(unsigned long)
boundary so the 8 byte boundary is not garanteed with x86_32.
With 2.6.23 and 2.6.24, the hostdata is on an 8 byte boundary by
chance, but with the current git, it's not.
This patch removes overrun_buf static array and use kzalloc.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
---
drivers/scsi/advansys.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
index ccef891..3c2d688 100644
--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -566,7 +566,7 @@ typedef struct asc_dvc_var {
ASC_SCSI_BIT_ID_TYPE unit_not_ready;
ASC_SCSI_BIT_ID_TYPE queue_full_or_busy;
ASC_SCSI_BIT_ID_TYPE start_motor;
- uchar overrun_buf[ASC_OVERRUN_BSIZE] __aligned(8);
+ uchar *overrun_buf;
dma_addr_t overrun_dma;
uchar scsi_reset_wait;
uchar chip_no;
@@ -13833,6 +13833,12 @@ static int __devinit advansys_board_found(struct
Scsi_Host *shost,
*/
if (ASC_NARROW_BOARD(boardp)) {
ASC_DBG(2, "AscInitAsc1000Driver()\n");
+
+ asc_dvc_varp->overrun_buf = kzalloc(ASC_OVERRUN_BSIZE,
GFP_KERNEL);
+ if (!asc_dvc_varp->overrun_buf) {
+ ret = -ENOMEM;
+ goto err_free_wide_mem;
+ }
warn_code = AscInitAsc1000Driver(asc_dvc_varp);
if (warn_code || asc_dvc_varp->err_code) {
@@ -13840,8 +13846,10 @@ static int __devinit advansys_board_found(struct
Scsi_Host *shost,
"warn 0x%x, error 0x%x\n",
asc_dvc_varp->init_state, warn_code,
asc_dvc_varp->err_code);
- if (asc_dvc_varp->err_code)
+ if (asc_dvc_varp->err_code) {
ret = -ENODEV;
+ kfree(asc_dvc_varp->overrun_buf);
+ }
}
} else {
if (advansys_wide_init_chip(shost))
@@ -13894,6 +13902,7 @@ static int advansys_release(struct Scsi_Host *shost)
dma_unmap_single(board->dev,
board->dvc_var.asc_dvc_var.overrun_dma,
ASC_OVERRUN_BSIZE, DMA_FROM_DEVICE);
+ kfree(board->dvc_var.asc_dvc_var.overrun_buf);
} else {
iounmap(board->ioremap_addr);
advansys_wide_free_mem(board);
--
1.5.3.8
--
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/
Re: + smack-unlabeled-outgoing-ambient-packets.patch added to -mm tree
From: Paul Moore <[EMAIL PROTECTED]> Date: Thu, 7 Feb 2008 15:14:34 -0500 > My apologies, those mailing list postings there haven't hit my inbox yet. I had to remove you a few days ago, see my other reply to Andrew. You are back on the lists now, so I hope that bounce problem has been solved. -- 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/
Re: frv cmpxchg_local compile error
* Adrian Bunk ([EMAIL PROTECTED]) wrote: > Commit 14e0cb3c60b89c4a2512852ffc18601c72314a0f broke frv compilation: > > <-- snip --> > > ... > CC arch/frv/kernel/asm-offsets.s > In file included from include/asm/system.h:271, > from include/asm/bitops.h:19, > from include/linux/bitops.h:17, > from include/linux/kernel.h:15, > from include/linux/sched.h:52, > from arch/frv/kernel/asm-offsets.c:7: > include/asm-generic/cmpxchg-local.h: In function '__cmpxchg_local_generic': > include/asm-generic/cmpxchg-local.h:23: error: implicit declaration of > function 'typecheck' Isn't typecheck() supposed to be defined in kernel.h which is included _everywhere_ ? Hrm, I see, dependency from kernel.h on bitops.h on asm/bitops.h on asm/system.h. > include/asm-generic/cmpxchg-local.h:23: error: expected expression before > 'unsigned' > include/asm-generic/cmpxchg-local.h:23: error: expected expression before > 'unsigned' > include/asm-generic/cmpxchg-local.h:44: error: expected expression before > 'unsigned' > include/asm-generic/cmpxchg-local.h: In function '__cmpxchg64_local_generic': > include/asm-generic/cmpxchg-local.h:57: error: expected expression before > 'unsigned' > include/asm-generic/cmpxchg-local.h:57: error: expected expression before > 'unsigned' > include/asm-generic/cmpxchg-local.h:61: error: expected expression before > 'unsigned' > In file included from include/asm/bitops.h:19, > from include/linux/bitops.h:17, > from include/linux/kernel.h:15, > from include/linux/sched.h:52, > from arch/frv/kernel/asm-offsets.c:7: > include/asm/system.h: In function '__cmpxchg_local': > include/asm/system.h:279: error: variable or field '__xg_orig' declared void > include/asm/system.h:279: error: variable or field '__xg_test' declared void > include/asm/system.h:279: error: variable or field '__xg_new' declared void > include/asm/system.h:279: error: void value not ignored as it ought to be > make[1]: *** [arch/frv/kernel/asm-offsets.s] Error 1 > > <-- snip --> > > > An architecture specific patch that breaks the one architecture it > touches at the first file being compiled is even for kernel standards > unusually bad... > I did this cmpxchg_local patchset to support Christoph Lameter's slub performance improvement work. It implies touching every kernel architecture. Each architecture is touched by a different patch. And no, I did not happen to have an FRV toolchain handy. Sorry. I'll dig into this. Mathieu > > cu > Adrian > > -- > >"Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. >"Only a promise," Lao Er said. >Pearl S. Buck - Dragon Seed > -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -- 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/
Re: [stable] [patch 00/45] 2.6.24-stable review
On Thu, Feb 07, 2008 at 06:50:34PM -0500, Chuck Ebbert wrote: > On 02/07/2008 03:45 PM, Greg KH wrote: > > This is the start of the stable review cycle for the 2.6.24.1 release. > > There are 45 patches in this series, all will be posted as a response to > > this one. If anyone has any issues with these being applied, please let > > us know. If anyone is a maintainer of the proper subsystem, and wants > > to add a Signed-off-by: line to the patch, please respond with it. > > > > These patches are sent out with a number of different people on the Cc: > > line. If you wish to be a reviewer, please email [EMAIL PROTECTED] to > > add your name to the list. If you want to be off the reviewer list, > > also email us. > > > > Responses should be made by Friday, Feb 8 2008, 21:00:00 [EMAIL PROTECTED] > > Anything received after that time might be too late. > > > > thanks, > > > > the -stable release team > > Is there an -rc1 patch somewhere on kernel.org? (and also for 2.6.23?) Ugh, no, I didn't create one, sorry. I'll get to that after dinner... thanks, greg k-h -- 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/
Re: + smack-unlabeled-outgoing-ambient-packets.patch added to -mm tree
From: Andrew Morton <[EMAIL PROTECTED]> Date: Thu, 7 Feb 2008 12:04:59 -0800 > It was on linux-kernel and netdev. I've restored those cc's. Perhaps Paul missed it because his email address was bouncing with "user unknown" errors a few days ago so he got removed from all the mailing lists @ vger :-) -- 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/
Re: [patch] block layer: kmemcheck fixes
On Thu, 7 Feb 2008, David Miller wrote: > > Maybe cpus these days have so much store bandwith that doing > things like the above is OK, but I doubt it :-) I seriously doubt the same is true for the IO requests (which are different anyway, and tend to happen at a much lower frequency than high-speed networking). I also suspect that your timings were very hardware-dependent in the first place (and yes, the long-term effect is likely working against that "optimization"), and depend a lot on just how sparse the initialization can to be. Linus -- 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/
Re: MM kernels 2.6.24-rc*-mm*, 2.6.24-mm1: gnome-terminal stuck in tty_poll
On Thu, 07 Feb 2008 21:24:47 +0100 Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > On Thu, 2008-02-07 at 20:49 +0100, Peter Zijlstra wrote: > > On Wed, 2008-02-06 at 18:23 -0800, Andrew Morton wrote: > > > On Wed, 06 Feb 2008 20:10:50 -0600 "J. K. Cliburn" > > > <[EMAIL PROTECTED]> wrote: > > > > > > > Zan Lynx wrote: > > > > > > > > > gnome-terminal gets stuck. > > > > > > > > I began seeing this very thing around 2.6.24 time. (Fedora 8, > > > > vanilla kernel.) I could usually cause the gnome terminal to > > > > hang if I rapidly resized the window while executing make > > > > check-headers. > > Weird, .24 proper doesn't have that patch. Yeah, my reference to "around 2.6.24 time" was simply a gross demarcation along the passage of time rather than an indictment of 2.6.24 itself. I began noticing gnome-terminal hangs during kernel builds a couple of weeks ago, but I ignored them, thinking it'd be fixed with a Fedora package update. When that didn't happen, I began looking for the culprit in the kernel in earnest this past Saturday. > What exact fedora kernel was that (so I can look at it). I didn't use a Fedora kernel; I bisected Linus' git current as of Saturday Feb 2, using 2.6.24 as the "good" side of the bisect. It took the better part of two days to whittle down the throng, but by Sunday night I'd settled on the 37bb6cb4 hrtimer commit. My last act before going to bed that night was to reset the bisect, revert the commit, and rebuild. I couldn't get gnome-terminal to hang using that rebuilt kernel. The next morning I went out of town for a couple of days, only to return to find my workstation dead after some weather-related power outages. I just got it back online tonight. > Which is even weirder, because the provided trace indicates > schedule_timeout() The trace isn't from me; it's from Zan. He's running -mm, I'm not, if that makes a difference. > > Call Trace: > [schedule_timeout+149/208] schedule_timeout+0x95/0xd0 > [] schedule_timeout+0x95/0xd0 > [tty_poll+145/160] tty_poll+0x91/0xa0 > [] tty_poll+0x91/0xa0 > [do_sys_poll+617/880] do_sys_poll+0x269/0x370 > [] do_sys_poll+0x269/0x370 > [__pollwait+0/304] __pollwait+0x0/0x130 > [] __pollwait+0x0/0x130 Now that my computer is back on the air again, I'll be happy to help track this down. Just tell me what to do. Jay -- 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/
Re: [stable] [patch 00/45] 2.6.24-stable review
On Thu, Feb 07, 2008 at 05:12:30PM -0800, Greg KH wrote: > On Fri, Feb 08, 2008 at 11:44:30AM +1100, David Chinner wrote: > > Greg, > > > > Is there any reason why the XFS patch I sent to the stable list a > > couple of days ago is not included in this series? > > > > http://oss.sgi.com/archives/xfs/2008-02/msg00027.html > > > > We've had multiple reports of it, and multiple confirmations that > > the patch in the link above fixes the problem. > > I didn't think it was in Linus's tree yet. Is it? Not yet - it's in the pipeline. I'll see if that can be sped up (someone else usually takes care of the pushes to Linus). Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group -- 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/
Re: [-mm PATCH] sysdev_unregister() should call kobject_del()
On Thu, 2008-02-07 at 16:38 -0800, Greg KH wrote: > On Thu, Feb 07, 2008 at 03:56:58PM -0800, Badari Pulavarty wrote: > > Hi Greg, > > > > While playing with hotplug memory remove on 2.6.24-mm1, I > > noticed that /sysfs directory entries are not getting removed. > > > > sysdev_unregister() used to call kobject_unregister(). > > But in 2.6.24-mm1, its only dropping the ref. It should > > call kobject_del() to remove the object. Correct ? > > > > With this change, the directories are getting removed > > correctly. Comments ? > > Ick, no, this shouldn't be needed, someone else must be holding a > reference to the kobject device somewhere. See the kobject documenation > for more info. > > I'll try to see where we grab 2 references... I will take a closer look then. I was taking easy way out :( Thanks, Badari -- 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/
Re: [patch] block layer: kmemcheck fixes
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Thu, 7 Feb 2008 09:42:56 -0800 (PST) > Can we please just stop doing these one-by-one assignments, and just do > something like > > memset(rq, 0, sizeof(*rq)); > rq->q = q; > rq->ref_count = 1; > INIT_HLIST_NODE(>hash); > RB_CLEAR_NODE(>rb_node); > > instead? > > The memset() is likely faster and smaller than one-by-one assignments > anyway, even if the one-by-ones can avoid initializing some field or there > ends up being a double initialization.. The problem is store buffer compression. At least a few years ago this made a huge difference in sk_buff initialization in the networking. Maybe cpus these days have so much store bandwith that doing things like the above is OK, but I doubt it :-) -- 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/
Re: Kernel Panic in MPT SAS on 2.6.24 (and 2.6.23.14, 2.6.23.9)
Am Thursday, den 7 February hub Krzysztof Oledzki folgendes in die Tasten: Hi! > >While installing my new firewall I got the following kernel panic in > >the MPT SAS driver which I need for the disks. > >The first kernel I bootet was 2.6.23.14 which did panic so I tried a > >2.6.24 which panics, too. Our usual FAI kernel (2.6.23.9) is also > >affected. > Could you please try 2.6.22-stable? Yes it works :-/ I've put some things which on the web which might be helpful: dmesg http://files.rfc2324.org/mptsas_panic/2.6.22-dmesg lspci -vhttp://files.rfc2324.org/mptsas_panic/2.6.22-lspci-v .config http://files.rfc2324.org/mptsas_panic/2.6.22-config I'll search for the last working kernel and try to break it down to a commit tommorow when I can get a serial console or direct access. The Java driven console redirection is everything else than fulfilling :-( > It looks *very* similar to my problem: > http://bugzilla.kernel.org/show_bug.cgi?id=9909 It seems to be the same controller: 01:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068E PCI-Express Fusion-MPT SAS (rev 08) Subsystem: Dell Unknown device 1f10 Flags: bus master, fast devsel, latency 0, IRQ 16 I/O ports at ec00 [size=256] Memory at fc8fc000 (64-bit, non-prefetchable) [size=16K] Memory at fc8e (64-bit, non-prefetchable) [size=64K] Expansion ROM at fc90 [disabled] [size=1M] Capabilities: [50] Power Management version 2 Capabilities: [68] Express Endpoint IRQ 0 Capabilities: [98] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [b0] MSI-X: Enable- Mask- TabSize=1 Stay tuned. Ciao Max -- Follow the white penguin. -- 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/
Re: ACPI_WMI: worst config description of all times
On Friday 08 February 2008 00:12:24 Ray Lee wrote: > On Feb 7, 2008 3:51 PM, Carlos Corbacho <[EMAIL PROTECTED]> wrote: > > On Thursday 07 February 2008 23:33:54 Ray Lee wrote: > > > Do you have list of hardware/platforms that require this feature to > > > get the hardware to work? (acer abc123, tcm1100 xyz) > > > > I have a very long list of Acer laptops that are supported - which is far > > too long, and changes on far too much of a regular basis to put in there. > > > > Perhaps adding something like "This driver is also a required dependency > > to build the firmware specific drivers needed for many laptops, including > > Acer and HP machines"? Would this be acceptable then? -Carlos --- ACPI: WMI: Improve Kconfig entry From: Carlos Corbacho <[EMAIL PROTECTED]> As Pavel Machek has pointed out, the Kconfig entry for WMI is pretty non-descriptive. Rewrite it so that it explains what ACPI-WMI is, and why anyone would want to enable it. Many thanks to Ray Lee for ideas on this. Signed-off-by: Carlos Corbacho <[EMAIL PROTECTED]> CC: Pavel Machek <[EMAIL PROTECTED]> CC: Ray Lee <[EMAIL PROTECTED]> CC: Len Brown <[EMAIL PROTECTED]> --- drivers/acpi/Kconfig | 19 +++ 1 files changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index b7fbf16..ea763ef 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -207,11 +207,22 @@ config ACPI_WMI depends on EXPERIMENTAL depends on X86 help - This driver adds support for the ACPI-WMI mapper device (PNP0C14) - found on some systems. + This driver adds support for the ACPI-WMI (Windows Management + Instrumentation) mapper device (PNP0C14) found on some systems. - NOTE: You will need another driver or userspace application on top of - this to actually use anything defined in the ACPI-WMI mapper. + ACPI-WMI is a proprietary extension to ACPI to expose parts of the + ACPI firmware to userspace - this is done through various vendor + defined methods and data blocks in a PNP0C14 device, which are then + made available for userspace to call. + + The implementation of this in Linux currently only exposes this to + other kernel space drivers. + + This driver is a required dependency to build the firmware specific + drivers needed on many machines, including Acer and HP laptops. + + It is safe to enable this driver even if your DSDT doesn't define + any ACPI-WMI devices. config ACPI_ASUS tristate "ASUS/Medion Laptop Extras" -- 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/
Re: [stable] [patch 00/45] 2.6.24-stable review
On Fri, Feb 08, 2008 at 11:44:30AM +1100, David Chinner wrote: > Greg, > > Is there any reason why the XFS patch I sent to the stable list a > couple of days ago is not included in this series? > > http://oss.sgi.com/archives/xfs/2008-02/msg00027.html > > We've had multiple reports of it, and multiple confirmations that > the patch in the link above fixes the problem. I didn't think it was in Linus's tree yet. Is it? thanks, greg k-h -- 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/
Re: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Thu, 2008-02-07 at 19:07 -0600, James Bottomley wrote: > On Thu, 2008-02-07 at 17:04 -0800, Harvey Harrison wrote: > > On Thu, 2008-02-07 at 18:56 -0600, James Bottomley wrote: > > > Quite a bit of this is fixing things broken previously (the advansys fix > > > is still pending resolution, but I'll send it as an -rc fix when we have > > > it). There's the final elimination of all drivers that are esp based > > > but don't use the scsi_esp core (that's mostly m68k and alpha). Plus > > > the usual bunch of driver updates and the addition of a new enclosure > > > services driver and the corresponding ULD. > > > > > > The patch is available from: > > > > > > > I'm going to guess that this is the entry in feature-removal.txt > > that need an update then: > > > > --- > > > > What: old NCR53C9x driver > > When: October 2007 > > Why:Replaced by the much better esp_scsi driver. Actual low-level > > driver can be ported over almost trivially. > > Who:David Miller <[EMAIL PROTECTED]> > > Christoph Hellwig <[EMAIL PROTECTED]> > > Not immediately ... I anticipate a few "where'd my driver go?" type > questions from m68k for which this provides a useful reference to point > to ... > > James > > Well, if not removed, how about updated: What: old NCR53C9x driver When: Removed Feb 2008 Why:Replaced by the much better esp_scsi driver. Actual low-level driver can be ported over almost trivially. Who:James Bottomley <[EMAIL PROTECTED]> Cheers, Harvey -- 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/
Re: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Thu, 2008-02-07 at 17:04 -0800, Harvey Harrison wrote: > On Thu, 2008-02-07 at 18:56 -0600, James Bottomley wrote: > > Quite a bit of this is fixing things broken previously (the advansys fix > > is still pending resolution, but I'll send it as an -rc fix when we have > > it). There's the final elimination of all drivers that are esp based > > but don't use the scsi_esp core (that's mostly m68k and alpha). Plus > > the usual bunch of driver updates and the addition of a new enclosure > > services driver and the corresponding ULD. > > > > The patch is available from: > > > > I'm going to guess that this is the entry in feature-removal.txt > that need an update then: > > --- > > What: old NCR53C9x driver > When: October 2007 > Why: Replaced by the much better esp_scsi driver. Actual low-level > driver can be ported over almost trivially. > Who: David Miller <[EMAIL PROTECTED]> > Christoph Hellwig <[EMAIL PROTECTED]> Not immediately ... I anticipate a few "where'd my driver go?" type questions from m68k for which this provides a useful reference to point to ... James -- 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/
[GIT] Please pull 2 NFS client fixes
Hi Linus,
Please pull from the "master" branch of the repository at
git pull git://git.linux-nfs.org/pub/linux/nfs-2.6.git
This will update the following files through the appended changesets.
Cheers,
Trond
fs/Kconfig |7 ++-
fs/nfs/write.c | 20 +---
2 files changed, 19 insertions(+), 8 deletions(-)
commit 3211e4eb5834924dd5beac8956c0bc0bfb755c37
Author: James Lentini <[EMAIL PROTECTED]>
Date: Mon Jan 28 12:09:28 2008 -0500
SUNRPC xptrdma: simplify build configuration
Trond and Bruce,
This is a patch for 2.6.25. This is the same version that was sent out
on December 12 for review (no comments to date).
To simplify the RPC/RDMA client and server build configuration, make
SUNRPC_XPRT_RDMA a hidden config option that continues to depend on
SUNRPC and INFINIBAND. The value of SUNRPC_XPRT_RDMA will be:
- N if either SUNRPC or INFINIBAND are N
- M if both SUNRPC and INFINIBAND are on (M or Y) and at least one is M
- Y if both SUNRPC and INFINIBAND are Y
In 2.6.25, all of the RPC/RDMA related files are grouped in
net/sunrpc/xprtrdma and the net/sunrpc/xprtrdma/Makefile builds both
the client and server RPC/RDMA support using this config option.
Signed-off-by: James Lentini <[EMAIL PROTECTED]>
Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
commit 5d47a35600270e7115061cb1320ee60ae9bcb6b8
Author: Trond Myklebust <[EMAIL PROTECTED]>
Date: Thu Feb 7 17:24:07 2008 -0500
NFS: Fix a potential file corruption issue when writing
If the inode is flagged as having an invalid mapping, then we can't rely on
the PageUptodate() flag. Ensure that we don't use the "anti-fragmentation"
write optimisation in nfs_updatepage(), since that will cause NFS to write
out areas of the page that are no longer guaranteed to be up to date.
A potential corruption could occur in the following scenario:
client 1client 2
=== ===
fd=open("f",O_CREAT|O_WRONLY,0644);
write(fd,"fubar\n",6); // cache last page
close(fd);
fd=open("f",O_WRONLY|O_APPEND);
write(fd,"foo\n",4);
close(fd);
fd=open("f",O_WRONLY|O_APPEND);
write(fd,"bar\n",4);
close(fd);
-
The bug may lead to the file "f" reading 'fubar\n\0\0\0\nbar\n' because
client 2 does not update the cached page after re-opening the file for
write. Instead it keeps it marked as PageUptodate() until someone calls
invaldate_inode_pages2() (typically by calling read()).
Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
diff --git a/fs/Kconfig b/fs/Kconfig
index 3bf6ace..d731282 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -1778,12 +1778,9 @@ config SUNRPC_GSS
tristate
config SUNRPC_XPRT_RDMA
- tristate "RDMA transport for sunrpc (EXPERIMENTAL)"
+ tristate
depends on SUNRPC && INFINIBAND && EXPERIMENTAL
- default m
- help
- Adds a client RPC transport for supporting kernel NFS over RDMA
- mounts, including Infiniband and iWARP. Experimental.
+ default SUNRPC && INFINIBAND
config SUNRPC_BIND34
bool "Support for rpcbind versions 3 & 4 (EXPERIMENTAL)"
diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index b144b19..f55c437 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -697,6 +697,17 @@ int nfs_flush_incompatible(struct file *file, struct page
*page)
}
/*
+ * If the page cache is marked as unsafe or invalid, then we can't rely on
+ * the PageUptodate() flag. In this case, we will need to turn off
+ * write optimisations that depend on the page contents being correct.
+ */
+static int nfs_write_pageuptodate(struct page *page, struct inode *inode)
+{
+ return PageUptodate(page) &&
+ !(NFS_I(inode)->cache_validity &
(NFS_INO_REVAL_PAGECACHE|NFS_INO_INVALID_DATA));
+}
+
+/*
* Update and possibly write a cached page of an NFS file.
*
* XXX: Keep an eye on generic_file_read to make sure it doesn't do bad
@@ -717,10 +728,13 @@ int nfs_updatepage(struct file *file, struct page *page,
(long long)(page_offset(page) +offset));
/* If we're not using byte range locks, and we know the page
-* is entirely in cache, it may be more efficient to avoid
-* fragmenting write requests.
+* is up to date, it may be more efficient to extend the write
+* to cover the entire page in order to avoid fragmentation
+* inefficiencies.
*/
- if (PageUptodate(page) && inode->i_flock == NULL && !(file->f_mode &
O_SYNC)) {
+ if (nfs_write_pageuptodate(page, inode) &&
+ inode->i_flock == NULL &&
+
[PATCH] x86: Simplify cpu_idle_wait
Earlier commit 40d6a146629b98d8e322b6f9332b182c7cbff3df
added smp_call_function in cpu_idle_wait() to kick cpus that are in tickless
idle. Looking at cpu_idle_wait code at that time, code seemed to be
over-engineered for a case which is rarely used (while changing idle handler).
Below is a simplified version of cpu_idle_wait, which just makes
a dummy smp_call_function to all cpus, to make them come out of old idle handler
and start using the new idle handler. It eliminates code in the idle loop
to handle cpu_idle_wait.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.25-rc/arch/x86/kernel/process_32.c
===
--- linux-2.6.25-rc.orig/arch/x86/kernel/process_32.c
+++ linux-2.6.25-rc/arch/x86/kernel/process_32.c
@@ -82,7 +82,6 @@ unsigned long thread_saved_pc(struct tas
*/
void (*pm_idle)(void);
EXPORT_SYMBOL(pm_idle);
-static DEFINE_PER_CPU(unsigned int, cpu_idle_state);
void disable_hlt(void)
{
@@ -181,9 +180,6 @@ void cpu_idle(void)
while (!need_resched()) {
void (*idle)(void);
- if (__get_cpu_var(cpu_idle_state))
- __get_cpu_var(cpu_idle_state) = 0;
-
check_pgt_cache();
rmb();
idle = pm_idle;
@@ -208,40 +204,19 @@ static void do_nothing(void *unused)
{
}
+/*
+ * cpu_idle_wait - Used to ensure that all the CPUs discard old value of
+ * pm_idle and update to new pm_idle value. Required while changing pm_idle
+ * handler on SMP systems.
+ *
+ * Caller must have changed pm_idle to the new value before the call. Old
+ * pm_idle value will not be used by any CPU after the return of this function.
+ */
void cpu_idle_wait(void)
{
- unsigned int cpu, this_cpu = get_cpu();
- cpumask_t map, tmp = current->cpus_allowed;
-
- set_cpus_allowed(current, cpumask_of_cpu(this_cpu));
- put_cpu();
-
- cpus_clear(map);
- for_each_online_cpu(cpu) {
- per_cpu(cpu_idle_state, cpu) = 1;
- cpu_set(cpu, map);
- }
-
- __get_cpu_var(cpu_idle_state) = 0;
-
- wmb();
- do {
- ssleep(1);
- for_each_online_cpu(cpu) {
- if (cpu_isset(cpu, map) && !per_cpu(cpu_idle_state,
cpu))
- cpu_clear(cpu, map);
- }
- cpus_and(map, map, cpu_online_map);
- /*
-* We waited 1 sec, if a CPU still did not call idle
-* it may be because it is in idle and not waking up
-* because it has nothing to do.
-* Give all the remaining CPUS a kick.
-*/
- smp_call_function_mask(map, do_nothing, 0, 0);
- } while (!cpus_empty(map));
-
- set_cpus_allowed(current, tmp);
+ smp_mb();
+ /* kick all the CPUs so that they exit out of pm_idle */
+ smp_call_function(do_nothing, NULL, 0, 0);
}
EXPORT_SYMBOL_GPL(cpu_idle_wait);
Index: linux-2.6.25-rc/arch/x86/kernel/process_64.c
===
--- linux-2.6.25-rc.orig/arch/x86/kernel/process_64.c
+++ linux-2.6.25-rc/arch/x86/kernel/process_64.c
@@ -64,7 +64,6 @@ EXPORT_SYMBOL(boot_option_idle_override)
*/
void (*pm_idle)(void);
EXPORT_SYMBOL(pm_idle);
-static DEFINE_PER_CPU(unsigned int, cpu_idle_state);
static ATOMIC_NOTIFIER_HEAD(idle_notifier);
@@ -139,41 +138,19 @@ static void do_nothing(void *unused)
{
}
+/*
+ * cpu_idle_wait - Used to ensure that all the CPUs discard old value of
+ * pm_idle and update to new pm_idle value. Required while changing pm_idle
+ * handler on SMP systems.
+ *
+ * Caller must have changed pm_idle to the new value before the call. Old
+ * pm_idle value will not be used by any CPU after the return of this function.
+ */
void cpu_idle_wait(void)
{
- unsigned int cpu, this_cpu = get_cpu();
- cpumask_t map, tmp = current->cpus_allowed;
-
- set_cpus_allowed(current, cpumask_of_cpu(this_cpu));
- put_cpu();
-
- cpus_clear(map);
- for_each_online_cpu(cpu) {
- per_cpu(cpu_idle_state, cpu) = 1;
- cpu_set(cpu, map);
- }
-
- __get_cpu_var(cpu_idle_state) = 0;
-
- wmb();
- do {
- ssleep(1);
- for_each_online_cpu(cpu) {
- if (cpu_isset(cpu, map) &&
- !per_cpu(cpu_idle_state, cpu))
- cpu_clear(cpu, map);
- }
- cpus_and(map, map, cpu_online_map);
- /*
-* We waited 1 sec, if a CPU still did not call idle
-* it may be because it is in idle and not waking up
-* because it has nothing to do.
-* Give all the remaining CPUS a kick.
-*/
-
Re: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Thu, 2008-02-07 at 18:56 -0600, James Bottomley wrote: > Quite a bit of this is fixing things broken previously (the advansys fix > is still pending resolution, but I'll send it as an -rc fix when we have > it). There's the final elimination of all drivers that are esp based > but don't use the scsi_esp core (that's mostly m68k and alpha). Plus > the usual bunch of driver updates and the addition of a new enclosure > services driver and the corresponding ULD. > > The patch is available from: > I'm going to guess that this is the entry in feature-removal.txt that need an update then: --- What: old NCR53C9x driver When: October 2007 Why:Replaced by the much better esp_scsi driver. Actual low-level driver can be ported over almost trivially. Who:David Miller <[EMAIL PROTECTED]> Christoph Hellwig <[EMAIL PROTECTED]> Cheers, Harvey -- 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/
