CONFIG_DEBUG_RODATA prevents kprobes from working on 2.6.22-rc2
The recent changes in the 2.6.22-rc2 kernel to the write protection of read only data enable by CONFIG_DEBUG_RODATA prevents kprobes from working. At least on the on i386 and x86_64 machine the mark_rodata_ro() function marks memory starting from _text as read only. Thus, when kprobes attempts to write a break point into a location in the kernel it faults. There is a description of the problem at: http://sources.redhat.com/bugzilla/show_bug.cgi?id=4531 Shouldn't mark_rodata_ro be less agressive when CONFIG_KPROBES is enabled? Or should kprobes temporarily change the page to be writeable, set the break point, and then return the page to read only? -Will - 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 PATCH] file as directory
I hope to get some breathing space next week, then I'll get back to VFS work. Great. I'd rather do that one myself, Sure, don't want to rob you of any fun stuff ;) Miklos - 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] [scsi] Remove __GFP_DMA
On Wed, 23 May 2007, James Bottomley wrote: I'll defer to Mark on this one. However, please remember that you can't just blindly remove GFP_DMA ... there are some cards which require it. Aacraid is one example ... it has a set of cards that can only DMA to 31 bits. For them, the GFP_DMA is necessary: The allocation in question is a scatterlist, which must be within the device DMA mask. a question i asked a while back, and still haven't seen an answer for -- given this in include/linux/gfp.h: #define GFP_DMA __GFP_DMA is there a qualitative difference between these two macros? is there *supposed* to be? if there isn't, one would think that just one variation would be sufficient. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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] Crash on modpost, addend_386_rel()
On Wed, 23 May 2007 18:23:17 +0300, Mika_Penttilä [EMAIL PROTECTED] wrote: So with mips64 you are lucky because the relocation symbol is .init.text and hence addend matches (has to match) symbol's offset. I can't find any spec where it is stated that addend == address, maybe it's in mips64 abi or something. It is quite normal to have addend of 0. The RELA part was added for other archs first (actually at that time it was broken on MIPS64 due to it's unusual layout). So it would be irrelevant to MIPS64 ABI. Unfortunately I do not know details, just tried to hack mips/mips64 stuff. --- Atsushi Nemoto - 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] Fix crash with irqpoll due to the IRQF_IRQPOLL flag
On Tue, 22 May 2007, Bernhard Walle wrote:
o System crashes if booted with irqpoll command line option.
o Problem happens because Inside note_interrupt() we are accessing
desc-action-flag without taking the desc-lock. While accessing it
somebody goes ahead and unregisters the irq handler hence desc-action
is NULL. By the time note_interrupt() checks it, it crashes.
I absolutely _detest_ patches that make already complex and unreadable
code even more so. Especially conditionals. Please don't do that.
If you need a variable for a conditional, make it be an implicit one from
an inline function, and aim for making it readable.
So how about instead writing it out as a nice self-explanatory inline
function? I can almost guarantee that this generates no worse code, and it
also makes it easy to explain things like we don't bother with the lock,
because we don't care enough.
Untested, but I think the point of the patch is obvious. Anybody want to
test it, send it back to me, and fix the bug while making the code more
readable?
I think we should instate a hard new rule:
- if a bugfix doesn't make the code more readable, it's not a bugfix at
all.
There was a reason for the bug in the first place, and that reason is
likely that the code was hard to think about. So making it even _harder_
to think about isn't really fixing the deeper problem!
Linus
---
kernel/irq/spurious.c | 46 +-
1 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/kernel/irq/spurious.c b/kernel/irq/spurious.c
index b0d81aa..bd9e272 100644
--- a/kernel/irq/spurious.c
+++ b/kernel/irq/spurious.c
@@ -135,6 +135,39 @@ report_bad_irq(unsigned int irq, struct irq_desc *desc,
irqreturn_t action_ret)
}
}
+static inline int try_misrouted_irq(unsigned int irq, struct irq_desc *desc,
irqreturn_t action_ret)
+{
+ struct irqaction *action;
+
+ if (!irqfixup)
+ return 0;
+
+ /* We didn't actually handle the IRQ - see if it was misrouted? */
+ if (action_ret == IRQ_NONE)
+ return 1;
+
+ /*
+* But for 'irqfixup == 2' we also do it for handled interrupts if
+* they are marked as IRQF_IRQPOLL (or for irq zero, which is the
+* traditional PC timer interrupt.. Legacy)
+*/
+ if (irqfixup 2)
+ return 0;
+
+ if (!irq)
+ return 1;
+
+ /*
+* Since we don't get the descriptor lock, action can
+* change under us. We don't really care, but we don't
+* want to follow a NULL pointer. So tell the compiler to
+* just load it once by using a barrier.
+*/
+ action = desc-action;
+ barrier();
+ return action (action-flags IRQF_IRQPOLL);
+}
+
void note_interrupt(unsigned int irq, struct irq_desc *desc,
irqreturn_t action_ret)
{
@@ -144,15 +177,10 @@ void note_interrupt(unsigned int irq, struct irq_desc
*desc,
report_bad_irq(irq, desc, action_ret);
}
- if (unlikely(irqfixup)) {
- /* Don't punish working computers */
- if ((irqfixup == 2 ((irq == 0) ||
- (desc-action-flags IRQF_IRQPOLL))) ||
- action_ret == IRQ_NONE) {
- int ok = misrouted_irq(irq);
- if (action_ret == IRQ_NONE)
- desc-irqs_unhandled -= ok;
- }
+ if (unlikely(try_misrouted_irq(irq, desc, action_ret))) {
+ int ok = misrouted_irq(irq);
+ if (action_ret == IRQ_NONE)
+ desc-irqs_unhandled -= ok;
}
desc-irq_count++;
-
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.22-rc2-mm1
On Wed, 23 May 2007 14:01:09 +0200 Gabriel C [EMAIL PROTECTED] wrote: Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/ I get this on boot : [ 0.333581] BUG: at include/linux/slub_def.h:83 kmalloc_index() [ 0.333587] [c0104eb7] show_trace_log_lvl+0x1a/0x2f [ 0.333601] [c0105a76] show_trace+0x12/0x14 [ 0.333606] [c0105a8e] dump_stack+0x16/0x18 [ 0.333611] [c0170d1c] get_slab+0x48/0x138 [ 0.333621] [c0170e8d] __kmalloc+0x11/0x66 [ 0.333626] [c0283c66] get_modalias+0x5e/0xee [ 0.333635] [c0283d3f] dmi_dev_uevent+0x2a/0x3f [ 0.333641] [c0241a7b] dev_uevent+0x1ad/0x1da [ 0.333650] [c01d11fe] kobject_uevent_env+0x200/0x3ff [ 0.333658] [c01d1407] kobject_uevent+0xa/0xf [ 0.333664] [c02416fc] device_add+0x283/0x440 [ 0.333669] [c02418cb] device_register+0x12/0x15 [ 0.333675] [c0424558] dmi_id_init+0x256/0x26c [ 0.333684] [c0409516] kernel_init+0x156/0x2c1 [ 0.333692] [c0104b33] kernel_thread_helper+0x7/0x10 [ 0.333698] === http://crazy.dev.frugalware.org/2.6.22-rc2-mm1/config-2.6.22-rc2-mm1 http://crazy.dev.frugalware.org/2.6.22-rc2-mm1/dmesg yup, thanks. David Airlie has said he'll look into this soon. It is a harmless warning. - 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: PCIE
On Wed, May 23, 2007 at 04:15:01PM +0400, Manu Abraham wrote: Hi, Do the PCI Express chipsets also use the same PCI API ? At the Linux kernel driver level, yes, they do. The device specifications are thus for the device that i am looking at: PCI Express interface * Compliant to PCI Express Base Specification 1.0a * The PCI Express circuit supports isochronous data traffic intended for uninterrupted transfer of streaming data like video streaming o x1 PCI Express endpoint (2.5 Gbit/s) o Data and clock recovery from serial stream o Low jitter and BER * Type 0 configuration space header o 64-bit addressing o Single BAR; programmable address range of 17 bits, 18 bits, 19 bits or 20 bits dependent on application requirements * PCI Express capabilities o 128 bytes write packet size and 64 bytes read packet size o MSI support o Software directed power management of four device power states (D0 to D3) o Active state power management of link states o Vendor specific capability for VC1 support; after reset VC1 isochronous capability is disabled I have been trying the said card with a normal PCI style driver, but while booting the kernel (2.6.21.1) i do get a message like this (an Intel DP965LT motherboard with BIOS version: MQ96510J.86A.1612.2006.1227.1513) Also accessing the interrupt registers causes a hard freeze, for which only the RESET button seems to be of any help. Uncompressing Linux .. Ok, booting the kernel. BIOS bug, no explicit IRQ entries, using default mptable. (tell your hw vendor) PCI: Failed to allocate mem resource #6:[EMAIL PROTECTED] for :01:00.0 Any ideas as to what could be wrong ? What type of PCI device is this? What driver is controlling it? What is the output of 'lspci -v' at boot time? 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: 2.6.22-rc2-mm1
On Wed, May 23, 2007 at 12:42:33AM -0700, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/
- A new readahead patch series. This needs serious review and performance
testing please.
- Added Ingo's CFS CPU scheduler
- Xen dom-U support is now in the x86 tree.
WARNING: arch/i386/mach-generic/built-in.o(.data+0xc4): Section mismatch:
reference to .init.text: (between 'apic_bigsmp' and 'cpu.4905')
This appears to be resolvable by removing all the __init and __initdata
qualifiers from arch/i386/mach-generic/bigsmp.c
Signed-off-by: William Irwin [EMAIL PROTECTED]
Index: mm-2.6.22-rc2/arch/i386/mach-generic/bigsmp.c
===
--- mm-2.6.22-rc2.orig/arch/i386/mach-generic/bigsmp.c 2007-05-23
08:53:25.122485613 -0700
+++ mm-2.6.22-rc2/arch/i386/mach-generic/bigsmp.c 2007-05-23
09:06:21.998757269 -0700
@@ -21,7 +21,7 @@
static int dmi_bigsmp; /* can be set by dmi scanners */
-static __init int hp_ht_bigsmp(struct dmi_system_id *d)
+static int hp_ht_bigsmp(struct dmi_system_id *d)
{
#ifdef CONFIG_X86_GENERICARCH
printk(KERN_NOTICE %s detected: force use of apic=bigsmp\n, d-ident);
@@ -31,7 +31,7 @@
}
-static struct dmi_system_id __initdata bigsmp_dmi_table[] = {
+static struct dmi_system_id bigsmp_dmi_table[] = {
{ hp_ht_bigsmp, HP ProLiant DL760 G2, {
DMI_MATCH(DMI_BIOS_VENDOR, HP),
DMI_MATCH(DMI_BIOS_VERSION, P44-),
@@ -45,7 +45,7 @@
};
-static int __init probe_bigsmp(void)
+static int probe_bigsmp(void)
{
if (def_to_bigsmp)
dmi_bigsmp = 1;
-
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.22-rc1-mm1 cifs_mount oops
On Wed, 23 May 2007 08:28:47 -0500 Steven French [EMAIL PROTECTED] wrote:
Yes - this patch looks better.
I also am not sure whether the send_sig is still necessary to wake up a
thread blocked in tcp recv_msg (only do a wake_up_process vs. doing a
send_sig(SIGKILL) )
Unless someone knows for sure whether the send_sig is redundant, I would
like to merge Shaggy's version of the patch
young dave [EMAIL PROTECTED] wrote on 05/23/2007 03:37:04 AM:
Hi,
Sorry for the wrong patch in my last post.
How about save the tsk then call kthread_stop like this:
diff -udr linux/fs/cifs/connect.c linux.new/fs/cifs/connect.c
--- linux/fs/cifs/connect.c 2007-05-23 10:59:13.0 +
+++ linux.new/fs/cifs/connect.c 2007-05-23 16:33:54.0 +
@@ -2069,8 +2069,9 @@
srvTcp-tcpStatus = CifsExiting;
spin_unlock(GlobalMid_Lock);
if (srvTcp-tsk) {
+ struct task_struct * tsk = srvTcp-tsk;
send_sig(SIGKILL,srvTcp-tsk,1);
- kthread_stop(srvTcp-tsk);
+ kthread_stop(tsk);
}
}
/* If find_unc succeeded then rc == 0 so we can not end
*/
Regards
dave
Shaggy's suggested patch seems slightly better:
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 216fb62..b6e2158 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2069,8 +2069,12 @@ cifs_mount(struct super_block *sb, struct
cifs_sb_info *cifs_sb,
srvTcp-tcpStatus =
CifsExiting;
spin_unlock(GlobalMid_Lock);
if (srvTcp-tsk) {
+struct
task_struct *tsk;
send_sig(SIGKILL,srvTcp-tsk,1);
- kthread_stop(srvTcp-tsk);
+/*
srvTcp-tsk can be zeroed at any time */
+tsk =
srvTcp-tsk;
+if (tsk)
+ kthread_stop(tsk);
}
}
/* If find_unc succeeded then rc == 0 so
we can not end */
The wordwrapping made that extraordinarily hard to read. Repairing...
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2069,8 +2069,12 @@ cifs_mount(struct super_block *sb, struct cifs_sb_info
*cifs_sb,
srvTcp-tcpStatus = CifsExiting;
spin_unlock(GlobalMid_Lock);
if (srvTcp-tsk) {
struct task_struct *tsk;
send_sig(SIGKILL,srvTcp-tsk,1);
- kthread_stop(srvTcp-tsk);
+ /* srvTcp-tsk can be zeroed at any time */
+ tsk = srvTcp-tsk;
+ if (tsk)
+ kthread_stop(tsk);
}
}
/* If find_unc succeeded then rc == 0 so we can not end */
This can end up running kthread_stop() against an already-exited task.
-
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 -rt] ARM TLB flush fix: don't forget to re-enable preemption
On Wed, 2007-05-23 at 10:22 +0100, Russell King wrote: On Tue, May 22, 2007 at 04:41:36PM -0700, Kevin Hilman wrote: On Tue, 2007-05-22 at 16:25 -0700, Daniel Walker wrote: On Tue, 2007-05-22 at 16:01 -0700, Kevin Hilman wrote: Add a preempt_enable() to flush_tlb_kernel_page() since -rt4 patch adds a preempt_disable but no preempt_enable(). Signed-off-by: Kevin Hilman [EMAIL PROTECTED] --- include/asm-arm/tlbflush.h |1 + 1 file changed, 1 insertion(+) Index: linux-2.6.21/include/asm-arm/tlbflush.h === --- linux-2.6.21.orig/include/asm-arm/tlbflush.h +++ linux-2.6.21/include/asm-arm/tlbflush.h @@ -378,6 +378,7 @@ static inline void local_flush_tlb_kerne asm(mcr p15, 0, %0, c8, c6, 1 : : r (kaddr) : cc); if (tlb_flag(TLB_V6_I_PAGE)) asm(mcr p15, 0, %0, c8, c5, 1 : : r (kaddr) : cc); Aren't these mcr operations atomic? Individually, yes. But the point of the preempt_disable/enable is to make the whole sequence atomic. In which case shouldn't it be at the end of the function so it includes the write buffer handling as well? However, I think I agree with Daniel on this one. I don't see the point of the preempt_disable() here. Note that my patch simply adds an enable to match the disable added by the -rt patch. I'm not sure where the disable originally came from, but there are disable/enable pairs scattered throughout tlbflush.h in the -rt patch. If this one isn't necessary, then the others probably are not either. In most cases there are 2 mcr instructions inside the critical section. One for the dsb() and the other for the actual function. Russell, is there a reason any of these sections should be atomic? Kevin - 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] LZO de/compression support - take 3
On Wed, 23 May 2007 19:51:44 +0530 Nitin Gupta [EMAIL PROTECTED] wrote: On 5/23/07, Michael-Luke Jones [EMAIL PROTECTED] wrote: On 23 May 2007, at 15:03, Nitin Gupta wrote: Perhaps a rename is in order: lzo1x_decompress() = lzo1x_decompress_unsafe() lzo1x_decompress_safe = lzo1x_decompress() Or perhaps make reiserfs use _safe() instead - I think Richard has already submitted patch for same. If someone's already made this mistake once, then it'll happen again. In-kernel memory corruption is no fun. Safe/Secure == Default If I rename 'nonsafe' version as such then it will seem like its a 'broken' implementation which is not the case. If somebody is upto including compression he must be having head to use the right decompress version depending on this scenario :-) wakes up What's unsafe here? If you fed it bad data, the decompressor will scribble on memory or crash the kernel or hang up? If so, it was quite inappropriate that a filesystem be using the unsafe version. I'd agree with the proposed renaming. In fact I'd suggest that the unsafe APIs just be removed - it's hard to imagine a situation in which they're OK to be used in the kernel. - 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: [AppArmor 38/45] AppArmor: Module and LSM hooks
On Tuesday 15 May 2007 11:14, Pavel Machek wrote: Why is this configurable? The maximum length of a pathname is an arbitrary limit: we don't want to allocate arbitrary amounts of of kernel memory for pathnames so we introduce this limit and set it to a reasonable value. In the unlikely case that someone uses insanely long pathnames, this limit can be increased. Andreas - 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] [scsi] Remove __GFP_DMA
On Wed, 2007-05-23 at 11:55 -0400, Robert P. J. Day wrote: On Wed, 23 May 2007, James Bottomley wrote: I'll defer to Mark on this one. However, please remember that you can't just blindly remove GFP_DMA ... there are some cards which require it. Aacraid is one example ... it has a set of cards that can only DMA to 31 bits. For them, the GFP_DMA is necessary: The allocation in question is a scatterlist, which must be within the device DMA mask. a question i asked a while back, and still haven't seen an answer for -- given this in include/linux/gfp.h: #define GFP_DMA __GFP_DMA is there a qualitative difference between these two macros? is there *supposed* to be? if there isn't, one would think that just one variation would be sufficient. __GFP_ are the raw GFP flags ... the GFP_ are combinations of the flags with predefined meanings. There's no convention that you have to use one form or the other when making combinations of the allocation flags. Historically that's lead to things like GFP_ATOMIC | __GFP_DMA (indicating additional DMA zone to the usual atomic flags) and GFP_ATOMIC | GFP_DMA (indicating same thing, but with the defined flags) You can argue that GFP_DMA has a pretty bogus GFP meaning and should never appear on its own, which, to my mind makes the former usage preferable. However, GFP_DMA has been in linux since pretty much the dawn of ISA drivers, so I think it's conventionally well understood. James 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: [PATCH] UDF: possible usage of uninitialized variables
[Jan Kara - Tue, May 22, 2007 at 10:29:38PM +0200]
| A few variables could be used without being explicitly initialized.
| Fixed.
|
| Signed-off-by: Cyrill Gorcunov [EMAIL PROTECTED]
| ---
|
|
| balloc.c |6 +-
| super.c |5 -
| 2 files changed, 9 insertions(+), 2 deletions(-)
|
|
| diff --git a/balloc.c b/balloc.c
| index 4cec910..be37393 100644
| --- a/balloc.c
| +++ b/balloc.c
| @@ -744,7 +744,11 @@ static int udf_table_new_block(struct super_block * sb,
| uint32_t spread = 0x, nspread = 0x;
| uint32_t newblock = 0, adsize;
| uint32_t elen, goal_elen = 0;
| - kernel_lb_addr eloc, goal_eloc;
| + kernel_lb_addr eloc;
| + kernel_lb_addr goal_eloc = {
| + .logicalBlockNum = 0,
| + .partitionReferenceNum = 0,
| + };
| struct extent_position epos, goal_epos;
| int8_t etype;
| As I read the code, I don't think it can happen goal_eloc is used
| unitialized. Also please diff the tree completely, not just the udf
| directory..
|
| diff --git a/super.c b/super.c
| index 9b8644a..068a99c 100644
| --- a/super.c
| +++ b/super.c
| @@ -1358,7 +1358,10 @@ udf_load_partition(struct super_block *sb,
kernel_lb_addr *fileset)
| case UDF_VIRTUAL_MAP15:
| case UDF_VIRTUAL_MAP20:
| {
| - kernel_lb_addr ino;
| + kernel_lb_addr ino = {
| + .logicalBlockNum = 0,
| + .partitionReferenceNum = 0,
| + };
|
| if (!UDF_SB_LASTBLOCK(sb))
| {
| This one seems correct. Thanks for fixing this.
|
| Honza
| --
| Jan Kara [EMAIL PROTECTED]
| SuSE CR Labs
|
Jan, you know I've been messed up. The variables I've touched in my patch
became initialized in any case.
Andrew, just drop my patch (you're right and I was wrong ;).
Thanks you both for comments.
Cyrill
-
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 -rt] ARM TLB flush fix: don't forget to re-enable preemption
On Wed, May 23, 2007 at 09:13:57AM -0700, Kevin Hilman wrote: On Wed, 2007-05-23 at 10:22 +0100, Russell King wrote: In which case shouldn't it be at the end of the function so it includes the write buffer handling as well? However, I think I agree with Daniel on this one. I don't see the point of the preempt_disable() here. Note that my patch simply adds an enable to match the disable added by the -rt patch. I'm not sure where the disable originally came from, but there are disable/enable pairs scattered throughout tlbflush.h in the -rt patch. If this one isn't necessary, then the others probably are not either. In most cases there are 2 mcr instructions inside the critical section. One for the dsb() and the other for the actual function. Russell, is there a reason any of these sections should be atomic? I don't see any reason for them to be - when switching to another process we'll generally do a full TLB flush anyway, so what's the point in making these flushes atomic? Consider: flush_tlb_page() first mcr - invalidates tlb single entry --- context switch, invalidates entire tlb, inc dsb --- something else runs --- context switch, invalidates entire tlb, inc dsb, again --- dsb That context switch is harmless - we end up with the entire TLB being invalidated and a DSB following. Now consider: flush_tlb_page() --- context switch, invalidates entire tlb, inc dsb --- something else runs --- context switch, invalidates entire tlb, inc dsb, again --- preempt_disable() first mcr - invalidates tlb single entry dsb preempt_enable() Any difference? No. Without the preempt disable/enable fiddling? No. flush_tlb_page() preempt_disable() first mcr - invalidates tlb single entry dsb preempt_enable() --- context switch, invalidates entire tlb, inc dsb --- something else runs --- context switch, invalidates entire tlb, inc dsb, again --- Any difference? No. Without the preempt disable/enable fiddling? No. In every case of a preemption occuring in the middle of a tlb operation, the ultimate result is identical irrespective of preempt control sprinkling. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - 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] ARM/ARM26: Enable arbitary speed tty ioctls and split input/output speed
Add the ioctls and values needed for this to the ARM26/ARM32 ports. The
actual code has been in the base kernel for a while and automatically
turns on when a port sets the required defines.
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-arm/ioctls.h
linux-2.6.22-rc1-mm1/include/asm-arm/ioctls.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-arm/ioctls.h 2007-04-30
10:48:14.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-arm/ioctls.h 2007-05-23
16:19:48.010005480 +0100
@@ -46,6 +46,10 @@
#define TIOCSBRK 0x5427 /* BSD compatibility */
#define TIOCCBRK 0x5428 /* BSD compatibility */
#define TIOCGSID 0x5429 /* Return the session ID of FD */
+#define TCGETS2_IOR('T',0x2A, struct termios2)
+#define TCSETS2_IOW('T',0x2B, struct termios2)
+#define TCSETSW2 _IOW('T',0x2C, struct termios2)
+#define TCSETSF2 _IOW('T',0x2D, struct termios2)
#define TIOCGPTN _IOR('T',0x30, unsigned int) /* Get Pty Number (of
pty-mux device) */
#define TIOCSPTLCK _IOW('T',0x31, int) /* Lock/unlock Pty */
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-arm/termbits.h
linux-2.6.22-rc1-mm1/include/asm-arm/termbits.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-arm/termbits.h 2007-04-30
10:48:14.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-arm/termbits.h 2007-05-23
16:23:05.765942008 +0100
@@ -128,6 +128,7 @@
#define HUPCL 0002000
#define CLOCAL 0004000
#define CBAUDEX 001
+#defineBOTHER 001
#defineB57600 0010001
#define B115200 0010002
#define B230400 0010003
@@ -143,10 +144,12 @@
#define B300 0010015
#define B350 0010016
#define B400 0010017
-#define CIBAUD 00200360 /* input baud rate (not used) */
+#define CIBAUD 00200360 /* input baud rate */
#define CMSPAR0100 /* mark or space (stick) parity */
#define CRTSCTS 0200 /* flow control */
+#define IBSHIFT 16
+
/* c_lflag bits */
#define ISIG 001
#define ICANON 002
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-arm/termios.h
linux-2.6.22-rc1-mm1/include/asm-arm/termios.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-arm/termios.h 2007-04-30
11:00:07.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-arm/termios.h 2007-05-23
16:21:34.535811096 +0100
@@ -82,8 +82,10 @@
copy_to_user((termio)-c_cc, (termios)-c_cc, NCC); \
})
-#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios))
-#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios))
+#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios2))
+#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios2))
+#define user_termios_to_kernel_termios_1(k, u) copy_from_user(k, u,
sizeof(struct termios))
+#define kernel_termios_to_user_termios_1(u, k) copy_to_user(u, k,
sizeof(struct termios))
#endif /* __KERNEL__ */
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-arm26/ioctls.h
linux-2.6.22-rc1-mm1/include/asm-arm26/ioctls.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-arm26/ioctls.h 2007-04-30
10:48:14.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-arm26/ioctls.h 2007-05-23
16:22:44.320202256 +0100
@@ -47,6 +47,10 @@
#define TIOCSBRK 0x5427 /* BSD compatibility */
#define TIOCCBRK 0x5428 /* BSD compatibility */
#define TIOCGSID 0x5429 /* Return the session ID of FD */
+#define TCGETS2_IOR('T',0x2A, struct termios2)
+#define TCSETS2_IOW('T',0x2B, struct termios2)
+#define TCSETSW2 _IOW('T',0x2C, struct termios2)
+#define TCSETSF2 _IOW('T',0x2D, struct termios2)
#define TIOCGPTN _IOR('T',0x30, unsigned int) /* Get Pty Number (of
pty-mux device) */
#define TIOCSPTLCK _IOW('T',0x31, int) /* Lock/unlock Pty */
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-arm26/termbits.h
linux-2.6.22-rc1-mm1/include/asm-arm26/termbits.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-arm26/termbits.h 2007-04-30
10:48:14.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-arm26/termbits.h 2007-05-23
16:22:25.575051952 +0100
@@ -128,6 +128,7 @@
#define HUPCL 0002000
#define CLOCAL 0004000
#define CBAUDEX 001
+#define BOTHER 001
#defineB57600 0010001
#define B115200 0010002
#define B230400 0010003
@@ -143,10 +144,12 @@
#define B300 0010015
#define B350 0010016
#define B400 0010017
-#define CIBAUD 00200360 /* input baud rate (not used) */
+#define CIBAUD 00200360
[PATCH] blackfin: Enable arbitary speed serial setting
Add the needed definitions to activate arbitary speed support on the
blackfin platform.
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-blackfin/ioctls.h
linux-2.6.22-rc1-mm1/include/asm-blackfin/ioctls.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-blackfin/ioctls.h 2007-05-18
16:22:03.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-blackfin/ioctls.h 2007-05-23
16:27:40.720142616 +0100
@@ -47,6 +47,10 @@
#define TIOCSBRK 0x5427 /* BSD compatibility */
#define TIOCCBRK 0x5428 /* BSD compatibility */
#define TIOCGSID 0x5429 /* Return the session ID of FD */
+#define TCGETS2_IOR('T',0x2A, struct termios2)
+#define TCSETS2_IOW('T',0x2B, struct termios2)
+#define TCSETSW2 _IOW('T',0x2C, struct termios2)
+#define TCSETSF2 _IOW('T',0x2D, struct termios2)
#define TIOCGPTN _IOR('T',0x30, unsigned int)/* Get Pty Number (of
pty-mux device) */
#define TIOCSPTLCK _IOW('T',0x31, int) /* Lock/unlock Pty */
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-blackfin/termbits.h
linux-2.6.22-rc1-mm1/include/asm-blackfin/termbits.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-blackfin/termbits.h
2007-05-18 16:22:03.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-blackfin/termbits.h2007-05-23
16:27:23.293791824 +0100
@@ -129,6 +129,7 @@
#define HUPCL 0002000
#define CLOCAL 0004000
#define CBAUDEX 001
+#define BOTHER 001
#defineB57600 0010001
#define B115200 0010002
#define B230400 0010003
@@ -144,10 +145,12 @@
#define B300 0010015
#define B350 0010016
#define B400 0010017
-#define CIBAUD 00200360 /* input baud rate (not used) */
+#define CIBAUD 00200360 /* input baud rate */
#define CMSPAR 0100 /* mark or space (stick) parity */
#define CRTSCTS 0200 /* flow control */
+#defineIBSHIFT 16 /* Shift from CBAUD to CIBAUD */
+
/* c_lflag bits */
#define ISIG 001
#define ICANON 002
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-blackfin/termios.h
linux-2.6.22-rc1-mm1/include/asm-blackfin/termios.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-blackfin/termios.h 2007-05-18
16:22:03.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-blackfin/termios.h 2007-05-23
16:28:04.353549792 +0100
@@ -98,8 +98,10 @@
copy_to_user((termio)-c_cc, (termios)-c_cc, NCC); \
})
-#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios))
-#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios))
+#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios2))
+#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios2))
+#define user_termios_to_kernel_termios_1(k, u) copy_from_user(k, u,
sizeof(struct termios))
+#define kernel_termios_to_user_termios_1(u, k) copy_to_user(u, k,
sizeof(struct termios))
#endif /* __KERNEL__ */
-
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] ARM/ARM26: Enable arbitary speed tty ioctls and split input/output speed
On Wed, May 23, 2007 at 05:27:39PM +0100, Alan Cox wrote:
Add the ioctls and values needed for this to the ARM26/ARM32 ports. The
actual code has been in the base kernel for a while and automatically
turns on when a port sets the required defines.
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-arm/ioctls.h
linux-2.6.22-rc1-mm1/include/asm-arm/ioctls.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-arm/ioctls.h 2007-04-30
10:48:14.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-arm/ioctls.h 2007-05-23
16:19:48.010005480 +0100
@@ -46,6 +46,10 @@
#define TIOCSBRK 0x5427 /* BSD compatibility */
#define TIOCCBRK 0x5428 /* BSD compatibility */
#define TIOCGSID 0x5429 /* Return the session ID of FD */
+#define TCGETS2 _IOR('T',0x2A, struct termios2)
+#define TCSETS2 _IOW('T',0x2B, struct termios2)
+#define TCSETSW2 _IOW('T',0x2C, struct termios2)
+#define TCSETSF2 _IOW('T',0x2D, struct termios2)
#define TIOCGPTN _IOR('T',0x30, unsigned int) /* Get Pty Number (of
pty-mux device) */
#define TIOCSPTLCK _IOW('T',0x31, int) /* Lock/unlock Pty */
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-arm/termbits.h
linux-2.6.22-rc1-mm1/include/asm-arm/termbits.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-arm/termbits.h 2007-04-30
10:48:14.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-arm/termbits.h 2007-05-23
16:23:05.765942008 +0100
@@ -128,6 +128,7 @@
#define HUPCL0002000
#define CLOCAL 0004000
#define CBAUDEX 001
+#defineBOTHER 001
#defineB57600 0010001
#define B115200 0010002
#define B230400 0010003
@@ -143,10 +144,12 @@
#define B300 0010015
#define B350 0010016
#define B400 0010017
-#define CIBAUD 00200360 /* input baud rate (not used) */
+#define CIBAUD 00200360 /* input baud rate */
#define CMSPAR0100 /* mark or space (stick) parity
*/
#define CRTSCTS0200 /* flow control */
+#define IBSHIFT 16
+
/* c_lflag bits */
#define ISIG 001
#define ICANON 002
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-arm/termios.h
linux-2.6.22-rc1-mm1/include/asm-arm/termios.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-arm/termios.h2007-04-30
11:00:07.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-arm/termios.h2007-05-23
16:21:34.535811096 +0100
@@ -82,8 +82,10 @@
copy_to_user((termio)-c_cc, (termios)-c_cc, NCC); \
})
-#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios))
-#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k,
sizeof(struct termios))
+#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios2))
+#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k,
sizeof(struct termios2))
+#define user_termios_to_kernel_termios_1(k, u) copy_from_user(k, u,
sizeof(struct termios))
+#define kernel_termios_to_user_termios_1(u, k) copy_to_user(u, k,
sizeof(struct termios))
#endif /* __KERNEL__ */
Alan, thanks for this.
Acked-by: Russell King [EMAIL PROTECTED]
for the above. The ARM26 stuff needs acking by Ian Molton, [EMAIL PROTECTED]
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
-
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] etrax: Enable arbitary speed setting on tty ports
Add the needed constants and bits. The actual code is already in the tty
layer and turned on by the definitions
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-cris/ioctls.h
linux-2.6.22-rc1-mm1/include/asm-cris/ioctls.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-cris/ioctls.h 2007-04-30
10:48:14.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-cris/ioctls.h 2007-05-23
16:29:31.018374736 +0100
@@ -48,6 +48,10 @@
#define TIOCSBRK 0x5427 /* BSD compatibility */
#define TIOCCBRK 0x5428 /* BSD compatibility */
#define TIOCGSID 0x5429 /* Return the session ID of FD */
+#define TCGETS2_IOR('T',0x2A, struct termios2)
+#define TCSETS2_IOW('T',0x2B, struct termios2)
+#define TCSETSW2 _IOW('T',0x2C, struct termios2)
+#define TCSETSF2 _IOW('T',0x2D, struct termios2)
#define TIOCGPTN _IOR('T',0x30, unsigned int) /* Get Pty Number (of
pty-mux device) */
#define TIOCSPTLCK _IOW('T',0x31, int) /* Lock/unlock Pty */
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-cris/termbits.h
linux-2.6.22-rc1-mm1/include/asm-cris/termbits.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-cris/termbits.h2007-04-30
10:48:14.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-cris/termbits.h2007-05-23
16:29:08.727763424 +0100
@@ -155,6 +155,7 @@
#define HUPCL 0002000
#define CLOCAL 0004000
#define CBAUDEX 001
+#define BOTHER 001
#define B57600 0010001
#define B115200 0010002
#define B230400 0010003
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-cris/termios.h
linux-2.6.22-rc1-mm1/include/asm-cris/termios.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-cris/termios.h 2007-04-30
11:00:07.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-cris/termios.h 2007-05-23
16:30:07.115887080 +0100
@@ -81,8 +81,10 @@
copy_to_user((termio)-c_cc, (termios)-c_cc, NCC); \
})
-#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios))
-#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios))
+#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios2))
+#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios2))
+#define user_termios_to_kernel_termios_1(k, u) copy_from_user(k, u,
sizeof(struct termios))
+#define kernel_termios_to_user_termios_1(u, k) copy_to_user(u, k,
sizeof(struct termios))
#endif /* __KERNEL__ */
-
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.22-rc2-mm1
On Wed, May 23, 2007 at 12:42:33AM -0700, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/
- A new readahead patch series. This needs serious review and performance
testing please.
- Added Ingo's CFS CPU scheduler
- Xen dom-U support is now in the x86 tree.
This patch silences the following warning:
WARNING: arch/i386/kernel/built-in.o(.text+0xdba6): Section mismatch: reference
to .init.data:cpu_llc_id (between 'set_cpu_sibling_map' and
'initialize_secondary')
Marking set_cpu_sibling_map() as __cpuinit resolves the section conflict
with the __cpuinitdata cpu_llc_id[] variable.
Signed-off-by: William Irwin [EMAIL PROTECTED]
Index: mm-2.6.22-rc2/arch/i386/kernel/smpboot.c
===
--- mm-2.6.22-rc2.orig/arch/i386/kernel/smpboot.c 2007-05-23
09:15:29.377950632 -0700
+++ mm-2.6.22-rc2/arch/i386/kernel/smpboot.c2007-05-23 09:16:27.089239410
-0700
@@ -308,7 +308,7 @@
/* representing cpus for which sibling maps can be computed */
static cpumask_t cpu_sibling_setup_map;
-void set_cpu_sibling_map(int cpu)
+void __cpuinit set_cpu_sibling_map(int cpu)
{
int i;
struct cpuinfo_x86 *c = cpu_data;
-
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] h8300: Enable arbitary speed tty port setup
Add the needed constants and defines to activate the new tty code on this
platform
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-h8300/ioctls.h
linux-2.6.22-rc1-mm1/include/asm-h8300/ioctls.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-h8300/ioctls.h 2007-04-30
10:48:15.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-h8300/ioctls.h 2007-05-23
16:32:31.437946792 +0100
@@ -47,6 +47,10 @@
#define TIOCSBRK 0x5427 /* BSD compatibility */
#define TIOCCBRK 0x5428 /* BSD compatibility */
#define TIOCGSID 0x5429 /* Return the session ID of FD */
+#define TCGETS2_IOR('T',0x2A, struct termios2)
+#define TCSETS2_IOW('T',0x2B, struct termios2)
+#define TCSETSW2 _IOW('T',0x2C, struct termios2)
+#define TCSETSF2 _IOW('T',0x2D, struct termios2)
#define TIOCGPTN _IOR('T',0x30, unsigned int) /* Get Pty Number (of
pty-mux device) */
#define TIOCSPTLCK _IOW('T',0x31, int) /* Lock/unlock Pty */
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-h8300/termbits.h
linux-2.6.22-rc1-mm1/include/asm-h8300/termbits.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-h8300/termbits.h 2007-04-30
10:48:15.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-h8300/termbits.h 2007-05-23
16:32:14.463527296 +0100
@@ -130,6 +130,7 @@
#define HUPCL 0002000
#define CLOCAL 0004000
#define CBAUDEX 001
+#defineBOTHER 001
#defineB57600 0010001
#define B115200 0010002
#define B230400 0010003
@@ -145,10 +146,12 @@
#define B300 0010015
#define B350 0010016
#define B400 0010017
-#define CIBAUD 00200360 /* input baud rate (not used) */
+#define CIBAUD 00200360 /* input baud rate */
#define CMSPAR 0100 /* mark or space (stick) parity */
#define CRTSCTS 0200 /* flow control */
+#define IBSHIFT 16/* shift from CBAUD to CIBAUD */
+
/* c_lflag bits */
#define ISIG 001
#define ICANON 002
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-h8300/termios.h
linux-2.6.22-rc1-mm1/include/asm-h8300/termios.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-h8300/termios.h2007-04-30
11:00:07.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-h8300/termios.h2007-05-23
16:32:21.409471352 +0100
@@ -82,8 +82,10 @@
copy_to_user((termio)-c_cc, (termios)-c_cc, NCC); \
})
-#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios))
-#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios))
+#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios2))
+#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios2))
+#define user_termios_to_kernel_termios_1(k, u) copy_from_user(k, u,
sizeof(struct termios))
+#define kernel_termios_to_user_termios_1(u, k) copy_to_user(u, k,
sizeof(struct termios))
#endif /* __KERNEL__ */
-
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 3/7] lockdep: lock contention tracking
On Wed, 23 May 2007, Peter Zijlstra wrote: On Wed, 2007-05-23 at 10:40 -0400, Jason Baron wrote: On Wed, 23 May 2007, Peter Zijlstra wrote: Count lock contention events per lock class. Additionally track the first four callsites that resulted in the contention. I think that we need the total number of locking calls, not just the total number of *contended* locking calls, in order to make the data significant. Same for waittime. Yes, this pollutes the fastpath. In the contention case, its one extra addition, and for the waittime, its a call the sched_clock(). I don't think that's too much to pay for much more meaningful data. The holdtime statistics add these numbers. ok, i see what you are saying...however, the 'waittime' statistic as implemented, is only recorded when we don't get the lock immediately. Thus, it's really measuring the waittime when there is lock contention. I understand that in the non-contended case we are only talking a a few cycles, but the fact that the non-contended case is not counted as another waittime of even zero length (so no measurement is required), might skew the stats a bit. For examples, if there was a lock that was almost never contended but one time happened to be contended for a long time, its average wait time would look really high. thanks, -Jason - 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 -rt] ARM TLB flush fix: don't forget to re-enable preemption
On Wed, 2007-05-23 at 09:13 -0700, Kevin Hilman wrote: Note that my patch simply adds an enable to match the disable added by the -rt patch. I'm not sure where the disable originally came from, but there are disable/enable pairs scattered throughout tlbflush.h in the -rt patch. If this one isn't necessary, then the others probably are not either. In most cases there are 2 mcr instructions inside the critical section. One for the dsb() and the other for the actual function. Russell, is there a reason any of these sections should be atomic? Under normal preempt modes those functions would end running with preemption disabled , but with PREEMPT_RT enabled they become preemptive .. I may have been mistaken , but my impression was that one mcr instruction was executed and it was atomic , so there was no need for additional protection there.. If there are two mcr instructions then you could be preempted between the two, which may be unsafe depending on what those instructions are doing .. Daniel - 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] ia64: Arbitary speed tty ioctl support
Add the needed constants and defines to activate this for the IA64
platform.
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-ia64/ioctls.h
linux-2.6.22-rc1-mm1/include/asm-ia64/ioctls.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-ia64/ioctls.h 2007-04-30
10:48:16.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-ia64/ioctls.h 2007-05-23
16:40:00.942611696 +0100
@@ -53,6 +53,10 @@
#define TIOCSBRK 0x5427 /* BSD compatibility */
#define TIOCCBRK 0x5428 /* BSD compatibility */
#define TIOCGSID 0x5429 /* Return the session ID of FD */
+#define TCGETS2_IOR('T',0x2A, struct termios2)
+#define TCSETS2_IOW('T',0x2B, struct termios2)
+#define TCSETSW2 _IOW('T',0x2C, struct termios2)
+#define TCSETSF2 _IOW('T',0x2D, struct termios2)
#define TIOCGPTN _IOR('T',0x30, unsigned int) /* Get Pty Number (of
pty-mux device) */
#define TIOCSPTLCK _IOW('T',0x31, int) /* Lock/unlock Pty */
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-ia64/termbits.h
linux-2.6.22-rc1-mm1/include/asm-ia64/termbits.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-ia64/termbits.h2007-04-30
10:48:16.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-ia64/termbits.h2007-05-23
16:40:25.281911560 +0100
@@ -138,6 +138,7 @@
#define HUPCL 0002000
#define CLOCAL 0004000
#define CBAUDEX 001
+#defineBOTHER 001
#defineB57600 0010001
#define B115200 0010002
#define B230400 0010003
@@ -153,10 +154,12 @@
#define B300 0010015
#define B350 0010016
#define B400 0010017
-#define CIBAUD 00200360 /* input baud rate (not used) */
+#define CIBAUD 00200360 /* input baud rate */
#define CMSPAR 0100 /* mark or space (stick) parity */
#define CRTSCTS 0200 /* flow control */
+#define IBSHIFT16 /* Shift from CBAUD to CIBAUD */
+
/* c_lflag bits */
#define ISIG 001
#define ICANON 002
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-ia64/termios.h
linux-2.6.22-rc1-mm1/include/asm-ia64/termios.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-ia64/termios.h 2007-04-30
11:00:07.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-ia64/termios.h 2007-05-23
16:39:52.016968600 +0100
@@ -87,8 +87,10 @@
copy_to_user((termio)-c_cc, (termios)-c_cc, NCC); \
})
-#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios))
-#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios))
+#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios2))
+#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios2))
+#define user_termios_to_kernel_termios_1(k, u) copy_from_user(k, u,
sizeof(struct termios))
+#define kernel_termios_to_user_termios_1(u, k) copy_to_user(u, k,
sizeof(struct termios))
# endif /* __KERNEL__ */
-
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 5/7] genhd: send async notification on media change
On Tue, 22 May 2007 14:12:11 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 9 May 2007 16:38:35 -0700
Kristen Carlson Accardi [EMAIL PROTECTED] wrote:
Send an uevent to user space to indicate that a media change event has
occurred.
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
Index: 2.6-git/block/genhd.c
===
--- 2.6-git.orig/block/genhd.c
+++ 2.6-git/block/genhd.c
@@ -643,6 +643,27 @@ struct seq_operations diskstats_op = {
.show = diskstats_show
};
+static void media_change_notify_thread(struct work_struct *work)
+{
+ struct gendisk *gd = container_of(work, struct gendisk, async_notify);
+ char event[] = MEDIA_CHANGE=1;
+ char *envp[] = { event, NULL };
+
+ /*
+* set enviroment vars to indicate which event this is for
+* so that user space will know to go check the media status.
+*/
+ kobject_uevent_env(gd-kobj, KOBJ_CHANGE, envp);
+ put_device(gd-driverfs_dev);
+}
+
+void genhd_media_change_notify(struct gendisk *disk)
+{
+ get_device(disk-driverfs_dev);
+ schedule_work(disk-async_notify);
+}
+EXPORT_SYMBOL_GPL(genhd_media_change_notify);
+
struct gendisk *alloc_disk(int minors)
{
return alloc_disk_node(minors, -1);
@@ -672,6 +693,8 @@ struct gendisk *alloc_disk_node(int mino
kobj_set_kset_s(disk,block_subsys);
kobject_init(disk-kobj);
rand_initialize_disk(disk);
+ INIT_WORK(disk-async_notify,
+ media_change_notify_thread);
}
return disk;
Why does this do a schedule_work() rather than calling kobject_uevent_env()
directly?
Because it is called at Interrupt time.
Kristen
-
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] LZO1X de/compression support
Bernd Petrovitsch wrote: The register keyword is and was always from start *at most* a hint to the C compiler to use a register for that variable (similar to inline BTW). So every C compiler is allowed to simply ignore the register for any reason - be it not implemented or the compiler knows better. Trivial reason: Think of a function with 100 register variables. The only useful semantic for register these days is that its illegal to take the address of one. So it might be useful if you want to make sure you have no aliases of a particular variable. J - 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] Crash on modpost, addend_386_rel()
Atsushi Nemoto wrote: On Tue, 22 May 2007 17:48:09 +0300, Mika_Penttilä [EMAIL PROTECTED] wrote: I can't see how this use of r_attend is going to work. find_elf_symbol compares relsym-st_value to Elf_Rela-r_attend. I think it doesn't work for RELA archs and even with this patch for REL. It seems works fine with RELA archs, at least mips64. For example, set_up_list3s is correctly reported. WARNING: mm/built-in.o - Section mismatch: reference to .init.text:set_up_list3s from .text between 'kmem_cache_create' (at offset 0x26358) and 'cache_reap' Here is excerpt from readelf output. Addend value 0x21d8 matches st_value of its target symbol. $ mips64-linux-readelf -sr ../build-sb1250/mm/built-in.o Relocation section '.rela.text' at offset 0x33fe0 contains 5100 entries: Offset Info Type Sym. ValueSym. Name + Addend ... 00026358 00040004 R_MIPS_26 .init.text + 21d8 Type2: R_MIPS_NONE Type3: R_MIPS_NONE ... Symbol table '.symtab' contains 1652 entries: Num:Value Size TypeBind Vis Ndx Name ... 746: 21d8 148 FUNCLOCAL DEFAULT4 set_up_list3s --- Atsushi Nemoto So with mips64 you are lucky because the relocation symbol is .init.text and hence addend matches (has to match) symbol's offset. I can't find any spec where it is stated that addend == address, maybe it's in mips64 abi or something. It is quite normal to have addend of 0. --Mika - 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] m32r: Enable arbitary speed tty rate setting
Add the defines and constants needed for the M32R platform to support the
arbitary speed tty ioctls.
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-m32r/ioctls.h
linux-2.6.22-rc1-mm1/include/asm-m32r/ioctls.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-m32r/ioctls.h 2007-04-30
11:00:07.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-m32r/ioctls.h 2007-05-23
16:33:42.035214376 +0100
@@ -47,6 +47,10 @@
#define TIOCSBRK 0x5427 /* BSD compatibility */
#define TIOCCBRK 0x5428 /* BSD compatibility */
#define TIOCGSID 0x5429 /* Return the session ID of FD */
+#define TCGETS2_IOR('T',0x2A, struct termios2)
+#define TCSETS2_IOW('T',0x2B, struct termios2)
+#define TCSETSW2 _IOW('T',0x2C, struct termios2)
+#define TCSETSF2 _IOW('T',0x2D, struct termios2)
#define TIOCGPTN _IOR('T',0x30, unsigned int) /* Get Pty Number (of
pty-mux device) */
#define TIOCSPTLCK _IOW('T',0x31, int) /* Lock/unlock Pty */
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-m32r/termbits.h
linux-2.6.22-rc1-mm1/include/asm-m32r/termbits.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-m32r/termbits.h2007-04-30
11:00:07.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-m32r/termbits.h2007-05-23
16:33:29.958050384 +0100
@@ -129,6 +129,7 @@
#define HUPCL 0002000
#define CLOCAL 0004000
#define CBAUDEX 001
+#defineBOTHER 001
#defineB57600 0010001
#define B115200 0010002
#define B230400 0010003
@@ -144,11 +145,13 @@
#define B300 0010015
#define B350 0010016
#define B400 0010017
-#define CIBAUD 00200360 /* input baud rate (not used) */
+#define CIBAUD 00200360 /** input baud rate */
#define CTVB 0040 /* VisioBraille Terminal flow control */
#define CMSPAR 0100 /* mark or space (stick) parity */
#define CRTSCTS 0200 /* flow control */
+#defineIBSHIFT 16 /* Shift from CBAUD to CIBAUD */
+
/* c_lflag bits */
#define ISIG 001
#define ICANON 002
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-m32r/termios.h
linux-2.6.22-rc1-mm1/include/asm-m32r/termios.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-m32r/termios.h 2007-04-30
11:00:07.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-m32r/termios.h 2007-05-23
16:33:55.427178488 +0100
@@ -81,8 +81,10 @@
copy_to_user((termio)-c_cc, (termios)-c_cc, NCC); \
})
-#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios))
-#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios))
+#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios2))
+#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios2))
+#define user_termios_to_kernel_termios_1(k, u) copy_from_user(k, u,
sizeof(struct termios))
+#define kernel_termios_to_user_termios_1(u, k) copy_to_user(u, k,
sizeof(struct termios))
#endif /* __KERNEL__ */
-
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 0/2] UML - Two bug fixes for 2.6.22
One of them is really more a workaround for a host bug than a UML bug fix, but it does robustify the early boot checks a bit, and makes UML boot on current FC6, so it's worth going in 2.6.22. The other is a trivial error return fix in the ubd driver. Jeff -- Work email - jdike at linux dot intel dot com - 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] UML - Improve PTRACE_SYSEMU checking
Make the PTRACE_SYSEMU checking more robust. It will make sure that
system call numbers are reported correctly. If there is a problem, it
will disable PTRACE_SYSEMU use and use PTRACE_SYSCALL instead.
Thanks to Balaji G for helping reproduce this problem.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/os-Linux/start_up.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
Index: linux-2.6.21-mm/arch/um/os-Linux/start_up.c
===
--- linux-2.6.21-mm.orig/arch/um/os-Linux/start_up.c2007-05-16
18:23:49.0 -0400
+++ linux-2.6.21-mm/arch/um/os-Linux/start_up.c 2007-05-22 17:47:57.0
-0400
@@ -144,9 +144,7 @@ static int stop_ptraced_child(int pid, v
int exit_with = WEXITSTATUS(status);
if (exit_with == 2)
non_fatal(check_ptrace : child exited with status 2.
- Serious trouble happening! Try updating
- your host skas patch!\nDisabling SYSEMU
- support.);
+ \nDisabling SYSEMU support.\n);
non_fatal(check_ptrace : child exited with exitcode %d, while
expecting %d; status 0x%x\n, exit_with,
exitcode, status);
@@ -209,6 +207,7 @@ __uml_setup(nosysemu, nosysemu_cmd_par
static void __init check_sysemu(void)
{
void *stack;
+ unsigned long regs[MAX_REG_NR];
int pid, n, status, count=0;
non_fatal(Checking syscall emulation patch for ptrace...);
@@ -225,11 +224,20 @@ static void __init check_sysemu(void)
fatal(check_sysemu : expected SIGTRAP, got status = %d,
status);
- n = ptrace(PTRACE_POKEUSR, pid, PT_SYSCALL_RET_OFFSET,
- os_getpid());
- if(n 0)
- fatal_perror(check_sysemu : failed to modify system call
-return);
+ if(ptrace(PTRACE_GETREGS, pid, 0, regs) 0)
+ fatal_perror(check_sysemu : PTRACE_GETREGS failed);
+ if(PT_SYSCALL_NR(regs) != __NR_getpid){
+ non_fatal(check_sysemu got system call number %d,
+ expected %d..., PT_SYSCALL_NR(regs), __NR_getpid);
+ goto fail;
+ }
+
+ n = ptrace(PTRACE_POKEUSR, pid, PT_SYSCALL_RET_OFFSET, os_getpid());
+ if(n 0){
+ non_fatal(check_sysemu : failed to modify system call
+ return);
+ goto fail;
+ }
if (stop_ptraced_child(pid, stack, 0, 0) 0)
goto fail_stopped;
-
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] UML - Fix ubd_add error reporting
ubd_add returns 0 when there could actually be an error to report. Signed-off-by: Jeff Dike [EMAIL PROTECTED] -- arch/um/drivers/ubd_kern.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.21-mm/arch/um/drivers/ubd_kern.c === --- linux-2.6.21-mm.orig/arch/um/drivers/ubd_kern.c 2007-05-22 11:55:48.0 -0400 +++ linux-2.6.21-mm/arch/um/drivers/ubd_kern.c 2007-05-22 12:03:48.0 -0400 @@ -766,7 +766,7 @@ static int ubd_add(int n, char **error_o make_ide_entries(ubd_gendisk[n]-disk_name); out: - return 0; + return err; out_cleanup: blk_cleanup_queue(ubd_dev-queue); - 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] v850: Enable arbitary speed tty ioctls
Adding the defines/macros activates the existing code in the tty layer
and allows this platform to use the arbitary speed ioctl setting layer
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-v850/ioctls.h
linux-2.6.22-rc1-mm1/include/asm-v850/ioctls.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-v850/ioctls.h 2007-04-30
10:48:19.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-v850/ioctls.h 2007-05-23
16:46:16.297549072 +0100
@@ -46,6 +46,10 @@
#define TIOCSBRK 0x5427 /* BSD compatibility */
#define TIOCCBRK 0x5428 /* BSD compatibility */
#define TIOCGSID 0x5429 /* Return the session ID of FD */
+#define TCGETS2_IOR('T',0x2A, struct termios2)
+#define TCSETS2_IOW('T',0x2B, struct termios2)
+#define TCSETSW2 _IOW('T',0x2C, struct termios2)
+#define TCSETSF2 _IOW('T',0x2D, struct termios2)
#define TIOCGPTN _IOR('T',0x30, unsigned int) /* Get Pty Number (of
pty-mux device) */
#define TIOCSPTLCK _IOW('T',0x31, int) /* Lock/unlock Pty */
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-v850/termbits.h
linux-2.6.22-rc1-mm1/include/asm-v850/termbits.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-v850/termbits.h2007-04-30
10:48:19.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-v850/termbits.h2007-05-23
16:45:55.595696232 +0100
@@ -130,6 +130,7 @@
#define HUPCL 0002000
#define CLOCAL 0004000
#define CBAUDEX 001
+#defineBOTHER 001
#defineB57600 0010001
#define B115200 0010002
#define B230400 0010003
@@ -145,10 +146,12 @@
#define B300 0010015
#define B350 0010016
#define B400 0010017
-#define CIBAUD 00200360 /* input baud rate (not used) */
+#define CIBAUD 00200360 /* input baud rate */
#define CMSPAR 0100 /* mark or space (stick) parity */
#define CRTSCTS 0200 /* flow control */
+#defineIBSHIFT 16 /* Shifr from CBAUD to CIBAUD */
+
/* c_lflag bits */
#define ISIG 001
#define ICANON 002
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-v850/termios.h
linux-2.6.22-rc1-mm1/include/asm-v850/termios.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-v850/termios.h 2007-04-30
11:00:07.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-v850/termios.h 2007-05-23
16:46:05.624171672 +0100
@@ -80,8 +80,10 @@
copy_to_user((termio)-c_cc, (termios)-c_cc, NCC); \
})
-#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios))
-#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios))
+#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios2))
+#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios2))
+#define user_termios_to_kernel_termios_1(k, u) copy_from_user(k, u,
sizeof(struct termios))
+#define kernel_termios_to_user_termios_1(u, k) copy_to_user(u, k,
sizeof(struct termios))
#endif /* __KERNEL__ */
-
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] LZO de/compression support - take 3
On Wed, 2007-05-23 at 09:16 -0700, Andrew Morton wrote: On Wed, 23 May 2007 19:51:44 +0530 Nitin Gupta [EMAIL PROTECTED] wrote: On 5/23/07, Michael-Luke Jones [EMAIL PROTECTED] wrote: If I rename 'nonsafe' version as such then it will seem like its a 'broken' implementation which is not the case. If somebody is upto including compression he must be having head to use the right decompress version depending on this scenario :-) wakes up What's unsafe here? If you fed it bad data, the decompressor will scribble on memory or crash the kernel or hang up? It can scribble on memory it shouldn't. If so, it was quite inappropriate that a filesystem be using the unsafe version. Yes, I'll give you a patch to change the resier4 code in -mm then (if its not already been changed). I'd agree with the proposed renaming. In fact I'd suggest that the unsafe APIs just be removed - it's hard to imagine a situation in which they're OK to be used in the kernel. The compressed cache code might be one exception since it does the compression itself and shouldn't get corrupted. If it does get corrupted, you have bigger problems. I'll provide a patch to update the LZO code in -mm to add unsafe to the name. Cheers, Richard - 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] Xtensa: Enable arbitary tty speed setting ioctls
Adding the defines/constants activates the existing code in the tty layer
and allows arbitary tty speeds to be requested on this platform
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-xtensa/ioctls.h
linux-2.6.22-rc1-mm1/include/asm-xtensa/ioctls.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-xtensa/ioctls.h2007-04-30
10:48:19.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-xtensa/ioctls.h2007-05-23
16:47:53.890712656 +0100
@@ -91,6 +91,10 @@
#define TIOCSBRK _IO('T', 39) /* BSD compatibility */
#define TIOCCBRK _IO('T', 40) /* BSD compatibility */
#define TIOCGSID _IOR('T', 41, pid_t) /* Return the session ID of FD*/
+#define TCGETS2_IOR('T', 42, struct termios2)
+#define TCSETS2_IOW('T', 43, struct termios2)
+#define TCSETSW2 _IOW('T', 44, struct termios2)
+#define TCSETSF2 _IOW('T', 45, struct termios2)
#define TIOCGPTN _IOR('T',0x30, unsigned int) /* Get Pty Number (of
pty-mux device) */
#define TIOCSPTLCK _IOW('T',0x31, int) /* Lock/unlock Pty */
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-xtensa/termbits.h
linux-2.6.22-rc1-mm1/include/asm-xtensa/termbits.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-xtensa/termbits.h 2007-04-30
10:48:19.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-xtensa/termbits.h 2007-05-23
16:46:59.730946192 +0100
@@ -146,6 +146,7 @@
#define HUPCL 0002000
#define CLOCAL 0004000
#define CBAUDEX 001
+#define BOTHER 001
#defineB57600 0010001
#define B115200 0010002
#define B230400 0010003
@@ -161,10 +162,12 @@
#define B300 0010015
#define B350 0010016
#define B400 0010017
-#define CIBAUD 00200360 /* input baud rate (not used) */
+#define CIBAUD 00200360 /* input baud rate */
#define CMSPAR 0100 /* mark or space (stick) parity */
#define CRTSCTS 0200 /* flow control */
+#define IBSHIFT16 /* Shift from CBAUD to CIBAUD */
+
/* c_lflag bits */
#define ISIG 001
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-xtensa/termios.h
linux-2.6.22-rc1-mm1/include/asm-xtensa/termios.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-xtensa/termios.h 2007-04-30
11:00:09.0 +0100
+++ linux-2.6.22-rc1-mm1/include/asm-xtensa/termios.h 2007-05-23
16:47:24.030252136 +0100
@@ -95,8 +95,10 @@
copy_to_user((termio)-c_cc, (termios)-c_cc, NCC); \
})
-#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios))
-#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios))
+#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios2))
+#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios2))
+#define user_termios_to_kernel_termios_1(k, u) copy_from_user(k, u,
sizeof(struct termios))
+#define kernel_termios_to_user_termios_1(u, k) copy_to_user(u, k,
sizeof(struct termios))
#endif /* __KERNEL__ */
-
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.21.1 fails to suspend/resume to disk (sort of)
On Wednesday, 23 May 2007 11:57, Romano Giannetti wrote: On Wed, 2007-05-23 at 11:05 +0200, Rafael J. Wysocki wrote: Hi, On Wednesday, 23 May 2007 09:25, Romano Giannetti wrote: http://lkml.org/lkml/2007/5/23/38 Please see http://bugzilla.kernel.org/show_bug.cgi?id=8456 That seems to resemble the symptoms you describe. No, I don't think. The delay I observe is on resume (suspend is very fast). Moreover, I have no SATA. It seems that my problem came from pcmcia. Hmm, there also is this patch: http://lkml.org/lkml/2007/5/22/434 Now for the suspend to disk. With default setting (/sys/power/disk == platform) my laptop (vaio PGC-FX701) fails to poweroff; it stays with backlight on, a white screen, and if I power it off manually afterward it did not resume. By doing echo shutdown /sys/power/disk the laptop *do* power off (it's very slow, but I think that's related with the 60 secs delay commented in the other post). Then it resume --- text console did resume ok --- but the virtual console with X do not come back. I had to do a ctrl-alt-backspace thing. Any hints? More data? Could you please test the 2.6.22-rc2 kernel? Also, if it still doesn't work properly, could you apply the hibernation/suspend patchset available from http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc2/patches on top of it and see if that helps? Uf, I will try to find the time. I am on my way to try to compile 2.6.21.2 now. Problem is that a kernel compile the ubuntu way last hours here. If there is an expert on make-kpkg here, I could use some advise. I'd prefer to test patches over a 2.6.21 stable release, to avoid mixing symptoms from an experimental -rc... OK, I'll try to see which ones apply on top of 2.6.21 cleanly. Greetings, Rafael - 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: Google are using linux kernel - what do you know about the source?
On Wed, May 23, 2007 at 04:50:35PM +0200, Diego Calleja wrote: El Wed, 23 May 2007 16:23:44 +0200, Gergo Szakal [EMAIL PROTECTED] escribió: Greetings to all list-members! Recently I have read that Google are selling enterprise hardware that is running a modified version of the Linuk kernel [1]. I decided to ask them whether the source is available. I did this via the question form they offered. http://code.google.com/mirror/gsa.html Gerco, Please read the FAQ at http://www.tux.org/lkml/ There you will notice that use of Linux KERNEL does not mean that your must publish sources for your proprietary application, or to make it easy for somebody to make a distribution competeting with yours. People like Oracle have realized this a long ago, and are selling their commercial products also for Linux platform. Google has made available all parts of the system that they are obliged under GPL to make available. Perhaps person supplying the reply from Google didn't quite understand what the product is, and that it has lots of components where you can get sources for, although nothing exiting and special happens in them. A better reply from Google would have been: The GSA is made of a branded PC hardware, Linux operating system (sources of components available) plus proprietary Google search engine suite. /Matti Aarnio - 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: Sched - graphic smoothness under load - cfs-v13 sd-0.48
Con Kolivas wrote: On Wednesday 23 May 2007 10:28, Bill Davidsen wrote: kernel2.6.21-cfs-v132.6.21-ck2 a)194464254669 b)54159124 Everyone seems to like ck2, this makes it look as if the video display would be really pretty unusable. While sd-0.48 does show an occasional video glitch when watching video under heavy load, it's annoying rather than unusable. That's because the whole premise of your benchmark relies on a workload that yield()s itself to the eyeballs on most graphic card combinations when using glxgears. Your test remains a test of sched_yield in the presence of your workloads rather than anything else. If people like ck2 it's because in the real world with real workloads it is better, rather than on a yield() based benchmark. Repeatedly the reports are that 3d apps and games in normal usage under -ck are better than mainline and cfs. I have to admit that I call in the teen reserves to actually get good feedback on games, but I do watch a fair number of videos and under high load I find sd acceptable and cfs totally smooth. The next time my game expert comes to visit I'll get some subjective feedback. My use of glxgears was mainly intended to use something readily available, and which gave me the ability to make both subjective and objective evaluations. My -ck2 results certainly show no significant difference from sd-0.48, I suspect that on a machine with less memory the swap reload would be more beneficial. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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/
[Fwd: Re: Google are using linux kernel - what do you know about the source?]
And copy to the list... ---BeginMessage--- And where, may I ask, does one find the source of Google's modified kernel? (At least, the unmodified bits!) Chris Matti Aarnio wrote: On Wed, May 23, 2007 at 04:50:35PM +0200, Diego Calleja wrote: El Wed, 23 May 2007 16:23:44 +0200, Gergo Szakal [EMAIL PROTECTED] escribió: Greetings to all list-members! Recently I have read that Google are selling enterprise hardware that is running a modified version of the Linuk kernel [1]. I decided to ask them whether the source is available. I did this via the question form they offered. http://code.google.com/mirror/gsa.html Gerco, Please read the FAQ at http://www.tux.org/lkml/ There you will notice that use of Linux KERNEL does not mean that your must publish sources for your proprietary application, or to make it easy for somebody to make a distribution competeting with yours. People like Oracle have realized this a long ago, and are selling their commercial products also for Linux platform. Google has made available all parts of the system that they are obliged under GPL to make available. Perhaps person supplying the reply from Google didn't quite understand what the product is, and that it has lots of components where you can get sources for, although nothing exiting and special happens in them. A better reply from Google would have been: The GSA is made of a branded PC hardware, Linux operating system (sources of components available) plus proprietary Google search engine suite. /Matti Aarnio - 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/ ---End Message--- smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH] add notime boot option
On Wed, 23 May 2007 15:03:01 +0400 Michael Tokarev wrote: Randy Dunlap wrote: Add notime boot option to prevent timing data from being printed on each printk message line. That's a good source of confusion. To me, notime means something like don't bother calculating time, instead of the proposed behavior. Can't it be something like 'nologts' (no log timestamps) or nots or notimestamps or nologtime instead? nologtime is OK with me. or does it confuse people in a different way? Anyone else? --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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.22-rc2-mm1
On Wed, 23 May 2007, Andrew Morton wrote: This is intermittently getting resume-from-RAM failures. It is not sufficiently repeatable to be able to bisect. [ 1381.119362] PM: Preparing system for mem sleep [ 2331.798452] Stopping tasks ... [ 2351.760431] Stopping kernel threads timed out after 20 seconds (2 tasks refusing to freeze): [ 2351.762385] ksuspend_usbd [ 2351.764374] khubd [ 2351.766338] Restarting tasks ... done. Hmm, that seems to be related to usb-fix-suspend-to-ram.patch (probably one of the threads is waiting for a completion by some other thread that has been frozen already). Is it possible to get an Alt-SysRq-T stack trace during those 20 seconds? Knowing what those threads are waiting for would be a big help. The trace is at http://userweb.kernel.org/~akpm/tasks.txt. Interesting bits are [ 144.201264] khubd D 0045 0 160 2 (L-TLB) [ 144.204358]c207fe78 0046 90399a85 0045 0246 c207fe60 c25b0cc4 c206f4cc [ 144.204539]0286 769e4cea 004a 90399a85 0045 c32713c0 c207fed4 [ 144.207754]0001 c207fe94 c207febc c02e8e1b [ 144.210934] Call Trace: [ 144.217012] [c02e8e1b] wait_for_completion+0x68/0x91 [ 144.220090] [c011824f] default_wake_function+0x0/0x9 [ 144.223158] [c0127a41] flush_cpu_workqueue+0x4d/0x55 [ 144.226223] [c0127a69] wq_barrier_func+0x0/0x8 [ 144.229269] [c026343d] usb_release_dev+0x28/0x63 [ 144.232340] [c0233011] device_release+0x37/0x7c [ 144.235431] [c01cb6c7] kobject_cleanup+0x3d/0x54 [ 144.238520] [c01cb6de] kobject_release+0x0/0x8 [ 144.241631] [c01cc2a7] kref_put+0x75/0x82 [ 144.244699] [c0265482] hub_thread+0x376/0xa74 [ 144.247768] [c01180c2] pick_next_task_fair+0xf2/0x12a [ 144.250815] [c0116af1] __wake_up_common+0x31/0x4f [ 144.253864] [c012a259] autoremove_wake_function+0x0/0x35 [ 144.256902] [c026510c] hub_thread+0x0/0xa74 [ 144.259944] [c012a102] kthread+0x36/0x5c [ 144.262891] [c012a0cc] kthread+0x0/0x5c [ 144.265757] [c010464b] kernel_thread_helper+0x7/0x10 [ 144.268716] === [ 144.137704] ksuspend_usbd D 0045 0 157 2 (L-TLB) [ 144.140830]c2085f18 0046 9072767a 0045 c20626f0 c010449b c3182118 c206288c [ 144.141011]c3182120 c3182120 76d728df 004a 9072767a 0045 c3271200 c3182118 [ 144.144263]c3182120 0246 c20626f0 c02ea1c9 [ 144.147576] Call Trace: [ 144.153929] [c010449b] common_interrupt+0x23/0x28 [ 144.157245] [c02ea1c9] __down+0xba/0xc6 [ 144.160528] [c011824f] default_wake_function+0x0/0x9 [ 144.163832] [c02664fc] hcd_resume_work+0x0/0x43 [ 144.167126] [c02e9fd3] __down_failed+0x7/0xc [ 144.170372] [c0266518] hcd_resume_work+0x1c/0x43 [ 144.173603] [c01278cf] run_workqueue+0x6d/0xdf [ 144.176780] [c0127b4c] worker_thread+0x0/0xd0 [ 144.179885] [c0127b4c] worker_thread+0x0/0xd0 [ 144.182930] [c0127c12] worker_thread+0xc6/0xd0 [ 144.185964] [c012a259] autoremove_wake_function+0x0/0x35 [ 144.189056] [c012a102] kthread+0x36/0x5c [ 144.192118] [c012a0cc] kthread+0x0/0x5c [ 144.195153] [c010464b] kernel_thread_helper+0x7/0x10 Okay, it's clear that the two threads are in deadlock. It's not clear how the deadlock arose to begin with -- apparently there was a remote wakeup request for a root hub at the same time as a device below that root hub was disconnected, which doesn't make much sense. Anyway, this looks like a good place to use cancel_work_sync(). The patch below is highly untested, so Andrew, you're the guinea pig. :-) If it seems to help, I'll submit it with a proper Changelog entry. Alan Stern Index: usb-2.6/drivers/usb/core/hub.c === --- usb-2.6.orig/drivers/usb/core/hub.c +++ usb-2.6/drivers/usb/core/hub.c @@ -1294,6 +1294,7 @@ void usb_disconnect(struct usb_device ** *pdev = NULL; spin_unlock_irq(device_state_lock); +#ifdef CONFIG_USB_SUSPEND /* Synchronize with the ksuspend thread to prevent any more * autosuspend requests from being submitted, and decrement * the parent's count of unsuspended children. @@ -1303,6 +1304,10 @@ void usb_disconnect(struct usb_device ** usb_autosuspend_device(udev-parent); usb_pm_unlock(udev); + cancel_delayed_work(udev-autosuspend); + cancel_work_sync(udev-autosuspend.work); +#endif + put_device(udev-dev); } Index: usb-2.6/drivers/usb/core/usb.c === --- usb-2.6.orig/drivers/usb/core/usb.c +++ usb-2.6/drivers/usb/core/usb.c @@ -184,10 +184,6 @@ static void usb_release_dev(struct devic udev = to_usb_device(dev); -#ifdef CONFIG_USB_SUSPEND -
Re: [BUG] local_softirq_pending storm
Ingo Molnar wrote:
* Michal Piotrowski [EMAIL PROTECTED] wrote:
Bad news - I hit a bug in 2.6.22-rc2-hrt3. Bug symptoms:
- X hangs (keyboard, mouse, sound etc.)
- only Magic SysRq works
please try the patch below! I think we have nailed this bug.
Ingo
Index: linux/kernel/sched.c
===
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -4212,9 +4212,7 @@ int __sched cond_resched_softirq(void)
BUG_ON(!in_softirq());
if (need_resched() system_state == SYSTEM_RUNNING) {
- raw_local_irq_disable();
- _local_bh_enable();
- raw_local_irq_enable();
+ local_bh_enable();
__cond_resched();
local_bh_disable();
return 1;
We may have a problem with that:
BUG: warning at kernel/softirq.c:138/local_bh_enable() (Not tainted)
[c042b2ef] local_bh_enable+0x45/0x92
[c06036b7] cond_resched_softirq+0x2c/0x42
[c059d5d0] release_sock+0x54/0xa3
[c05c9428] tcp_sendmsg+0x91b/0xa0c
[c05e1bb9] inet_sendmsg+0x3b/0x45
[c059af34] sock_aio_write+0xf9/0x105
[c0476035] do_sync_write+0xc7/0x10a
[c0437265] autoremove_wake_function+0x0/0x35
[c047688e] vfs_write+0xbc/0x154
[c0476e8c] sys_write+0x41/0x67
[c0404f70] syscall_call+0x7/0xb
That's:
WARN_ON_ONCE(irqs_disabled());
And another, tainted but probably valid:
BUG: warning at kernel/softirq.c:138/local_bh_enable() (Tainted: P )
[c042b2ef] local_bh_enable+0x45/0x92
[c06036b7] cond_resched_softirq+0x2c/0x42
[c059d5d0] release_sock+0x54/0xa3
[c05c9428] tcp_sendmsg+0x91b/0xa0c
[c04e8b30] copy_to_user+0x3c/0x50
[c05a1b71] memcpy_toiovec+0x27/0x4a
[c059d58f] release_sock+0x13/0xa3
[c0604ad5] _spin_unlock_bh+0x5/0xd
[c05e1bb9] inet_sendmsg+0x3b/0x45
[c059af34] sock_aio_write+0xf9/0x105
[c0475f31] do_sync_readv_writev+0xc1/0xfe
[c0437265] autoremove_wake_function+0x0/0x35
[c04e88e0] copy_from_user+0x3a/0x66
[c0475dec] rw_copy_check_uvector+0x5c/0xb0
[c047667a] do_readv_writev+0xbc/0x187
[c059ae3b] sock_aio_write+0x0/0x105
[c0476782] vfs_writev+0x3d/0x48
[c0476bee] sys_writev+0x41/0x95
[c0404f70] syscall_call+0x7/0xb
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240982
-
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 5/7] genhd: send async notification on media change
On Wed, 2007-05-23 at 09:31 -0700, Kristen Carlson Accardi wrote:
On Tue, 22 May 2007 14:12:11 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 9 May 2007 16:38:35 -0700
Kristen Carlson Accardi [EMAIL PROTECTED] wrote:
Send an uevent to user space to indicate that a media change event has
occurred.
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
Index: 2.6-git/block/genhd.c
===
--- 2.6-git.orig/block/genhd.c
+++ 2.6-git/block/genhd.c
@@ -643,6 +643,27 @@ struct seq_operations diskstats_op = {
.show = diskstats_show
};
+static void media_change_notify_thread(struct work_struct *work)
+{
+ struct gendisk *gd = container_of(work, struct gendisk, async_notify);
+ char event[] = MEDIA_CHANGE=1;
+ char *envp[] = { event, NULL };
+
+ /*
+ * set enviroment vars to indicate which event this is for
+ * so that user space will know to go check the media status.
+ */
+ kobject_uevent_env(gd-kobj, KOBJ_CHANGE, envp);
+ put_device(gd-driverfs_dev);
+}
+
+void genhd_media_change_notify(struct gendisk *disk)
+{
+ get_device(disk-driverfs_dev);
+ schedule_work(disk-async_notify);
+}
+EXPORT_SYMBOL_GPL(genhd_media_change_notify);
+
struct gendisk *alloc_disk(int minors)
{
return alloc_disk_node(minors, -1);
@@ -672,6 +693,8 @@ struct gendisk *alloc_disk_node(int mino
kobj_set_kset_s(disk,block_subsys);
kobject_init(disk-kobj);
rand_initialize_disk(disk);
+ INIT_WORK(disk-async_notify,
+ media_change_notify_thread);
}
return disk;
Why does this do a schedule_work() rather than calling kobject_uevent_env()
directly?
Because it is called at Interrupt time.
It better not be ... there's two GFP_KERNEL allocations just above this
line in the file.
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: [PROBLEM] 2.6.22-rc2 panics on x86-64 with slub
On Wed, 23 May 2007, Jens Axboe wrote: That works for me with the patch, .config attached. H... That means the .config sent initially here was bogus. - 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.22-rc2-mm1
On 05/23, Andrew Morton wrote: On Wed, 23 May 2007 10:47:04 -0400 (EDT) Alan Stern [EMAIL PROTECTED] wrote: Is it possible to get an Alt-SysRq-T stack trace during those 20 seconds? Knowing what those threads are waiting for would be a big help. [ 144.201264] khubd D 0045 0 160 2 (L-TLB) [ 144.204358]c207fe78 0046 90399a85 0045 0246 c207fe60 c25b0cc4 c206f4cc [ 144.204539]0286 769e4cea 004a 90399a85 0045 c32713c0 c207fed4 [ 144.207754]0001 c207fe94 c207febc c02e8e1b [ 144.210934] Call Trace: [ 144.217012] [c02e8e1b] wait_for_completion+0x68/0x91 [ 144.220090] [c011824f] default_wake_function+0x0/0x9 [ 144.223158] [c0127a41] flush_cpu_workqueue+0x4d/0x55 [ 144.226223] [c0127a69] wq_barrier_func+0x0/0x8 [ 144.229269] [c026343d] usb_release_dev+0x28/0x63 [ 144.232340] [c0233011] device_release+0x37/0x7c [ 144.235431] [c01cb6c7] kobject_cleanup+0x3d/0x54 [ 144.238520] [c01cb6de] kobject_release+0x0/0x8 [ 144.241631] [c01cc2a7] kref_put+0x75/0x82 [ 144.244699] [c0265482] hub_thread+0x376/0xa74 [ 144.247768] [c01180c2] pick_next_task_fair+0xf2/0x12a [ 144.250815] [c0116af1] __wake_up_common+0x31/0x4f [ 144.253864] [c012a259] autoremove_wake_function+0x0/0x35 [ 144.256902] [c026510c] hub_thread+0x0/0xa74 [ 144.259944] [c012a102] kthread+0x36/0x5c [ 144.262891] [c012a0cc] kthread+0x0/0x5c [ 144.265757] [c010464b] kernel_thread_helper+0x7/0x10 [ 144.268716] === Looks like usb_release_dev() does flush_workqueue() under usb_lock_device(). Is it possible? If yes, flush_workqueue() stalls because this lock is need to finish the execution of -wakeup_work (below). usb_release_dev: #ifdef CONFIG_USB_SUSPEND cancel_delayed_work(udev-autosuspend); flush_workqueue(ksuspend_usb_wq); #endif What is the reason for flush_workqueue() here? _IF_ it is only needed to flush -autosuspend, we can use cancel_rearming_delayed_work(udev-autosuspend). [ 144.137704] ksuspend_usbd D 0045 0 157 2 (L-TLB) [ 144.140830]c2085f18 0046 9072767a 0045 c20626f0 c010449b c3182118 c206288c [ 144.141011]c3182120 c3182120 76d728df 004a 9072767a 0045 c3271200 c3182118 [ 144.144263]c3182120 0246 c20626f0 c02ea1c9 [ 144.147576] Call Trace: [ 144.153929] [c010449b] common_interrupt+0x23/0x28 [ 144.157245] [c02ea1c9] __down+0xba/0xc6 [ 144.160528] [c011824f] default_wake_function+0x0/0x9 [ 144.163832] [c02664fc] hcd_resume_work+0x0/0x43 [ 144.167126] [c02e9fd3] __down_failed+0x7/0xc [ 144.170372] [c0266518] hcd_resume_work+0x1c/0x43 [ 144.173603] [c01278cf] run_workqueue+0x6d/0xdf [ 144.176780] [c0127b4c] worker_thread+0x0/0xd0 [ 144.179885] [c0127b4c] worker_thread+0x0/0xd0 [ 144.182930] [c0127c12] worker_thread+0xc6/0xd0 [ 144.185964] [c012a259] autoremove_wake_function+0x0/0x35 [ 144.189056] [c012a102] kthread+0x36/0x5c [ 144.192118] [c012a0cc] kthread+0x0/0x5c [ 144.195153] [c010464b] kernel_thread_helper+0x7/0x10 Oleg. - 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: [PROBLEM] 2.6.22-rc2 panics on x86-64 with slub
On Wed, 23 May 2007, Srihari Vijayaraghavan wrote: and then try to boot without slub_debug. I guess you mean with CONFIG_SLUB_CONFIG=y? If so, I built another kernel with CONFIG_SLUB_DEBUG=y (plus all of the above) tested it. It panics by default, but with slub_nomerge it works just fine (tested under moderate load). (the panic message produced by CONFIG_SLUB_DEBUG=y was the exact same call trace as my very first email in this email thread with slightly different address on a couple of functions, but rest remains the same) Ahh... At least we are getting to the original problem. I'm personally very happy that slub works stably without slub debug options, because that's what I'd run in a production env. Thanks to your patch, slub is quite stable without the slub debug for me :-)). But it'd to nice to have a working slub debug for test env., as you'd undoubtedly be aware of, of course :-). Just my humble opinion. If that fails then boot with slub_nomerge So lockdep has issues with slab merging? If locks are tracking within slabs then I imagine that lockdep gets confused if we put them together. Yup, I had to use slub_nomerge; without that CONFIG_SLUB_DEBUG=y kernel panics. (I haven't tested the UP case though. I did try nosmp maxcpus=1, but they had no effect on the panic. Do you want me to test UP case for CONFIG_SLUB_DEBUG=y without slub_nomerge?) Yes. - 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/
[RFC] [PATCH 0/3] Add group fairness to CFS
Here's an attempt to extend CFS (v13) to be fair at a group level, rather than just at task level. The patch is in a very premature state (passes simple tests, smp load balance not supported yet) at this point. I am sending it out early to know if this is a good direction to proceed. Salient points which needs discussion: 1. This patch reuses CFS core to achieve fairness at group level also. To make this possible, CFS core has been abstracted to deal with generic schedulable entities (tasks, users etc). 2. The per-cpu rb-tree has been split to be per-group per-cpu. schedule() now becomes two step on every cpu : pick a group first (from group rb-tree) and a task within that group next (from that group's task rb-tree) 3. Grouping mechanism - I have used 'uid' as the basis of grouping for timebeing (since that grouping concept is already in mainline today). The patch can be adapted to a more generic process grouping mechanism (like http://lkml.org/lkml/2007/4/27/146) later. Some results below, obtained on a 4way (with HT) Intel Xeon box. All number are reflective of single CPU performance (tests were forced to run on single cpu since load balance is not yet supported). uid vatsa uid guest (make -s -j4 bzImage)(make -s -j20 bzImage) 2.6.22-rc1772.02 sec497.42 sec (real) 2.6.22-rc1+cfs-v13780.62 sec478.35 sec (real) 2.6.22-rc1+cfs-v13+this patch 776.36 sec776.68 sec (real) [ An exclusive cpuset containing only one CPU was created and the compilation jobs of both users were run simultaneously in this cpuset ] I also disabled CONFIG_FAIR_USER_SCHED and compared the results with cfs-v13: uid vatsa make -s -j4 bzImage 2.6.22-rc1+cfs-v13 395.57 sec (real) 2.6.22-rc1+cfs-v13+this_patch 388.54 sec (real) There is no regression I can see (rather some improvement, which I can't understand atm). I will run more tests later to check this regression aspect. Request your comments on the future direction to proceed! -- Regards, vatsa - 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/
[RFC] [PATCH 1/3] task_cpu(p) needs to be correct always
We rely very much on task_cpu(p) to be correct at all times, so that we can
correctly find the task_grp_rq from which the task has to be removed or added
to.
There is however one place in the scheduler where this assumption of
task_cpu(p) being correct is broken. This patch fixes that piece of code.
(Thanks to Balbir Singh for pointing this out to me)
Signed-off-by : Srivatsa Vaddagiri [EMAIL PROTECTED]
---
kernel/sched.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
Index: linux-2.6.21-rc7/kernel/sched.c
===
--- linux-2.6.21-rc7.orig/kernel/sched.c2007-05-23 20:46:41.0
+0530
+++ linux-2.6.21-rc7/kernel/sched.c 2007-05-23 20:48:26.0 +0530
@@ -4571,7 +4571,7 @@
static int __migrate_task(struct task_struct *p, int src_cpu, int dest_cpu)
{
struct rq *rq_dest, *rq_src;
- int ret = 0;
+ int ret = 0, on_rq;
if (unlikely(cpu_is_offline(dest_cpu)))
return ret;
@@ -4587,9 +4587,11 @@
if (!cpu_isset(dest_cpu, p-cpus_allowed))
goto out;
- set_task_cpu(p, dest_cpu);
- if (p-on_rq) {
+ on_rq = p-on_rq;
+ if (on_rq)
deactivate_task(rq_src, p, 0);
+ set_task_cpu(p, dest_cpu);
+ if (on_rq) {
activate_task(rq_dest, p, 0);
check_preempt_curr(rq_dest, p);
}
--
Regards,
vatsa
-
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/
[RFC] [PATCH 2/3] Introduce two new structures - struct lrq and sched_entity
This patch groups together fields used by CFS (for SCHED_NORMAL tasks)
in task_struct and runqueue into separate structures so that they can be
reused in a later patch.
'struct sched_entity' represents the attributes used by CFS for every
schedulable entity (task in this case).
'struct lrq' represents the runqueue used to store schedulable entities (tasks
in this case) and to maintain various clocks (ex: fair clock for tasks).
This patch also modifies rest of kernel to reflect these new structures.
Intended effect of this patch is zero on overall functionality of
scheduler.
Signed-off-by : Srivatsa Vaddagiri [EMAIL PROTECTED]
---
fs/proc/array.c |2
include/linux/sched.h | 44
kernel/exit.c |2
kernel/posix-cpu-timers.c | 19 +--
kernel/sched.c| 195 +++--
kernel/sched_debug.c | 85
kernel/sched_fair.c | 238 +++---
7 files changed, 301 insertions(+), 284 deletions(-)
Index: linux-2.6.21-rc7/fs/proc/array.c
===
--- linux-2.6.21-rc7.orig/fs/proc/array.c 2007-05-23 20:46:40.0
+0530
+++ linux-2.6.21-rc7/fs/proc/array.c2007-05-23 20:48:34.0 +0530
@@ -412,7 +412,7 @@
* Use CFS's precise accounting, if available:
*/
if (!has_rt_policy(task)) {
- utime = nsec_to_clock_t(task-sum_exec_runtime);
+ utime = nsec_to_clock_t(task-se.sum_exec_runtime);
stime = 0;
}
Index: linux-2.6.21-rc7/include/linux/sched.h
===
--- linux-2.6.21-rc7.orig/include/linux/sched.h 2007-05-23 20:46:40.0
+0530
+++ linux-2.6.21-rc7/include/linux/sched.h 2007-05-23 20:48:34.0
+0530
@@ -838,6 +838,29 @@
void (*task_new) (struct rq *rq, struct task_struct *p);
};
+/* CFS scheduling entity (task, user etc) statistics fields: */
+struct sched_entity {
+ int load_weight;/* for niceness load balancing purposes */
+ int on_rq;
+ struct rb_node run_node;
+ u64 wait_start_fair;
+ u64 wait_start;
+ u64 exec_start;
+ u64 sleep_start, sleep_start_fair;
+ u64 block_start;
+ u64 sleep_max;
+ u64 block_max;
+ u64 exec_max;
+ u64 wait_max;
+ u64 last_ran;
+
+ s64 wait_runtime;
+ u64 sum_exec_runtime;
+ s64 fair_key;
+ s64 sum_wait_runtime, sum_sleep_runtime;
+ unsigned long wait_runtime_overruns, wait_runtime_underruns;
+};
+
struct task_struct {
volatile long state;/* -1 unrunnable, 0 runnable, 0 stopped */
void *stack;
@@ -852,34 +875,15 @@
int oncpu;
#endif
#endif
- int load_weight;/* for niceness load balancing purposes */
int prio, static_prio, normal_prio;
- int on_rq;
struct list_head run_list;
- struct rb_node run_node;
+ struct sched_entity se;
unsigned short ioprio;
#ifdef CONFIG_BLK_DEV_IO_TRACE
unsigned int btrace_seq;
#endif
- /* CFS scheduling class statistics fields: */
- u64 wait_start_fair;
- u64 wait_start;
- u64 exec_start;
- u64 sleep_start, sleep_start_fair;
- u64 block_start;
- u64 sleep_max;
- u64 block_max;
- u64 exec_max;
- u64 wait_max;
- u64 last_ran;
-
- s64 wait_runtime;
- u64 sum_exec_runtime;
- s64 fair_key;
- s64 sum_wait_runtime, sum_sleep_runtime;
- unsigned long wait_runtime_overruns, wait_runtime_underruns;
unsigned int policy;
cpumask_t cpus_allowed;
Index: linux-2.6.21-rc7/kernel/exit.c
===
--- linux-2.6.21-rc7.orig/kernel/exit.c 2007-05-23 20:46:40.0 +0530
+++ linux-2.6.21-rc7/kernel/exit.c 2007-05-23 20:48:34.0 +0530
@@ -124,7 +124,7 @@
sig-nivcsw += tsk-nivcsw;
sig-inblock += task_io_get_inblock(tsk);
sig-oublock += task_io_get_oublock(tsk);
- sig-sum_sched_runtime += tsk-sum_exec_runtime;
+ sig-sum_sched_runtime += tsk-se.sum_exec_runtime;
sig = NULL; /* Marker for below. */
}
Index: linux-2.6.21-rc7/kernel/posix-cpu-timers.c
===
--- linux-2.6.21-rc7.orig/kernel/posix-cpu-timers.c 2007-05-23
20:46:40.0 +0530
+++ linux-2.6.21-rc7/kernel/posix-cpu-timers.c 2007-05-23 20:48:34.0
+0530
@@ -161,7 +161,8 @@
}
static inline unsigned long long sched_ns(struct task_struct *p)
{
- return (p == current) ? current_sched_runtime(p) : p-sum_exec_runtime;
+ return (p == current) ? current_sched_runtime(p) :
+p-se.sum_exec_runtime;
}
int
[RFC] [PATCH 3/3] Generalize CFS core and provide per-user fairness
This patch reuses CFS core to provide inter task-group fairness. For
demonstration purpose, the patch also extends CFS to provide per-user
fairness. The patch is very experimental atm and in particular, SMP LOAD
BALANCE IS DISABLED to keep the patch simple. I think group-based smp
load
balance is more trickier and I intend to look at it next.
Although user id is chosen as the basis of grouping tasks, the patch can
be adapted to work with other task grouping mechanisms (like :
http://lkml.org/lkml/2007/4/27/146).
Signed-off-by : Srivatsa Vaddagiri [EMAIL PROTECTED]
---
arch/i386/Kconfig |6
arch/x86_64/Kconfig |6
include/linux/sched.h | 16
kernel/sched.c| 256 +++
kernel/sched_debug.c |4
kernel/sched_fair.c | 820 --
kernel/sched_rt.c |2
kernel/user.c |5
8 files changed, 753 insertions(+), 362 deletions(-)
Index: linux-2.6.21-rc7/arch/i386/Kconfig
===
--- linux-2.6.21-rc7.orig/arch/i386/Kconfig 2007-05-23 20:46:38.0
+0530
+++ linux-2.6.21-rc7/arch/i386/Kconfig 2007-05-23 20:48:39.0 +0530
@@ -307,6 +307,12 @@
making when dealing with multi-core CPU chips at a cost of slightly
increased overhead in some places. If unsure say N here.
+config FAIR_USER_SCHED
+ bool Fair user scheduler
+ default n
+ help
+ Fair user scheduler
+
source kernel/Kconfig.preempt
config X86_UP_APIC
Index: linux-2.6.21-rc7/arch/x86_64/Kconfig
===
--- linux-2.6.21-rc7.orig/arch/x86_64/Kconfig 2007-05-23 20:46:38.0
+0530
+++ linux-2.6.21-rc7/arch/x86_64/Kconfig2007-05-23 20:48:39.0
+0530
@@ -330,6 +330,12 @@
making when dealing with multi-core CPU chips at a cost of slightly
increased overhead in some places. If unsure say N here.
+config FAIR_USER_SCHED
+ bool Fair user scheduler
+ default n
+ help
+ Fair user scheduler
+
source kernel/Kconfig.preempt
config NUMA
Index: linux-2.6.21-rc7/include/linux/sched.h
===
--- linux-2.6.21-rc7.orig/include/linux/sched.h 2007-05-23 20:48:34.0
+0530
+++ linux-2.6.21-rc7/include/linux/sched.h 2007-05-23 20:48:39.0
+0530
@@ -551,6 +551,16 @@
#define is_rt_policy(p)((p) != SCHED_NORMAL (p) !=
SCHED_BATCH)
#define has_rt_policy(p) unlikely(is_rt_policy((p)-policy))
+#ifdef CONFIG_FAIR_USER_SCHED
+int sched_alloc_user(struct user_struct *user);
+void sched_free_user(struct user_struct *user);
+void sched_move_task(struct user_struct *old);
+#else
+static inline int sched_alloc_user(struct user_struct *user) { return 0; }
+static inline void sched_free_user(struct user_struct *user) { }
+static inline void sched_move_task(struct user_struct *user) { }
+#endif
+
/*
* Some day this will be a full-fledged user tracking system..
*/
@@ -575,6 +585,10 @@
/* Hash table maintenance information */
struct list_head uidhash_list;
uid_t uid;
+#ifdef CONFIG_FAIR_USER_SCHED
+ struct sched_entity *se;/* per-cpu sched_entity */
+ struct lrq *lrq;/* per-cpu runqueue for this user */
+#endif
};
extern struct user_struct *find_user(uid_t);
@@ -859,6 +873,8 @@
s64 fair_key;
s64 sum_wait_runtime, sum_sleep_runtime;
unsigned long wait_runtime_overruns, wait_runtime_underruns;
+ struct sched_entity *parent;
+ struct lrq *my_q; /* The queue owned by this entity */
};
struct task_struct {
Index: linux-2.6.21-rc7/kernel/sched.c
===
--- linux-2.6.21-rc7.orig/kernel/sched.c2007-05-23 20:48:34.0
+0530
+++ linux-2.6.21-rc7/kernel/sched.c 2007-05-23 20:48:39.0 +0530
@@ -129,6 +129,14 @@
struct rb_root tasks_timeline;
struct rb_node *rb_leftmost;
struct rb_node *rb_load_balance_curr;
+ struct sched_entity *curr;
+ unsigned int *sched_granularity;/* sysctl_sched_granularity */
+ struct rq *rq;
+ unsigned long nice_0_load;
+#ifdef CONFIG_FAIR_USER_SCHED
+ struct list_head lrq_list;
+ struct rcu_head rcu;
+#endif
};
/*
@@ -164,6 +172,7 @@
struct task_struct *curr, *idle;
unsigned long next_balance;
+ unsigned long rt_load;
struct mm_struct *prev_mm;
u64 clock, prev_clock_raw;
@@ -214,6 +223,32 @@
struct lock_class_key rq_lock_key;
};
+#define NICE_0_LOADSCHED_LOAD_SCALE
+#define NICE_0_SHIFT SCHED_LOAD_SHIFT
+
+#ifdef CONFIG_FAIR_USER_SCHED
+static struct sched_entity root_user_se[NR_CPUS];
+static struct lrq root_user_lrq[NR_CPUS];
+
+static inline void init_se(struct sched_entity
Re: 2.6.21-mm2: ACPI exception on resume
On Wed, 23 May 2007, Rafael J. Wysocki wrote: While I agree with that, it would really be helpful if you tested the latest -rc kernel and saw if the bug was present in there. If the bug is not present in the latest -rc, it'll be possible to identify the patch that causes it to appear in -mm and find the reason of the breakage. And, once we know the reason, we will be able to find out how to best fix the problem. So, do please test latest -rc, or bissect to the last known-good kernel. As I said, we need further data points to do anything. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - 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.22-rc2-mm1
On 05/23, Alan Stern wrote: Okay, it's clear that the two threads are in deadlock. It's not clear how the deadlock arose to begin with -- apparently there was a remote wakeup request for a root hub at the same time as a device below that root hub was disconnected, which doesn't make much sense. Please note that this flush_workqueue() was not safe anyway. We are freezing tasks, and ksuspend_usb_wq is freezeable. So, it could be frozen before khubd task, and we have another deadlock. Anyway, this looks like a good place to use cancel_work_sync(). The Could you use cancel_rearming_delayed_work() ? (It should be renamed to cancel_delayed_work_sync()). Oleg. - 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: Define CONFIG_BOUNCE to avoid useless inclusion of bounce buffer logic.
On Wed, 23 May 2007, Russell King wrote: That is wrong. ppc should have ZONE_NORMAL and no ZONE_DMA. Otherwise you cannot switch off ZONE_DMA and you cannot switch off bounce. ZONE_DMA is a zone for exceptional allocs. If you do not have those then you only have normal allocs - ZONE_NORMAL. That sounds very wrong to me. Since about 1995 ARM has always placed all DMA-able memory in the DMA zone, and none in the normal zone. The reason for doing this is that normal allocations fall back to DMA allocations when the normal zone becomes full/empty. However, DMA allocations can never be satisfied by allocations from the normal zone. Usually DMA is done via ZONE_NORMAL allocations. GFP_DMA allocs and ZONE_DMA are for devices that cannot performa DMA to all of memory. There is no need to fall back if you do not have such devices. So no need for ZONE_DMA. Moreover, special casing the doesn't use __GFP_DMA allocations on this machine so places all memory in ZONE_NORMAL is just too complicated - I've no idea which of the 100+ ARM machine support currently merged into the Linux kernel uses __GFP_DMA allocations and which don't. GFP_DMA allocations are an exception and that exception can be removed from the core VM by not defining ZONE_DMA. You cannot switch off the NORMAL zone. The DMA zone is for memory allocations _for_ _DMA_. If all your memory is DMA-able then it belongs in the DMA zone. Nope. The DMA zone is for crappy DMA devices that can only use a portion of memory. - 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.22-rc2-mm1
On Wed, 23 May 2007, Michal Piotrowski wrote: Christoph, this looks like a bug in SLUB. Please boot with slub_debug to find the bad code that overwrites a slab object after it was freed. - 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: [PROBLEM] 2.6.22-rc2 panics on x86-64 with slub
On Wed, 23 May 2007, Srihari Vijayaraghavan wrote: I'm personally very happy that slub works stably without slub debug options, because that's what I'd run in a production env. Thanks to your patch, slub is quite stable without the slub debug for me :-)). But it'd to nice to have a working slub debug for test env., as you'd undoubtedly be aware of, of course :-). Just my humble opinion. Just switching off lockdep should make you happy until we figure out what is wrong? - 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: bad networking related lag in v2.6.22-rc2
Linus Torvalds wrote:
There appear to be other obvious problems in the recent cleanups in this
area..
Look at
psched_tdiff_bounded(psched_time_t tv1, psched_time_t tv2,
psched_time_t bound)
{
return min(tv1 - tv2, bound);
}
and compare it to the previous code:
#define PSCHED_TDIFF_SAFE(tv1, tv2, bound) \
min_t(long long, (tv1) - (tv2), bound)
and ponder how that trivial cleanup totally broke the thing.
Hint: psched_time_t is an u64. What does that mean for
min(tv1 - tv2, bound);
again, when tv2 is larger than tv1. It _used_ to return a negative
value. Now it returns a positive bound upper bound, because tv1-tv2
will be used as a huge unsigned (and thus _positive_) integer. And was
that accidental, or done on purpose?
Sounds accidental to me, since you then want to return a psched_tdiff_t,
which is typedeffed to be long.
Doesn't sound very safe to me, especially since the commit message for
this is [NET_SCHED]: turn PSCHED_TDIFF_SAFE into inline function, and
there's no indication that anybody realized that it changed semantics in
the process.
I did realize it, but tv2 tv1 can't happen and makes no sense for
the users of this function. I probably should have provided a more
detailed changelog entry.
Hmm? What _should_ that thing do?
It is used to calculate the amount of tokens a tocken bucket has
accumulated since the last refill, thus we always have tv1 = tv2
(modulo ktime wraps). In fact tv2 tv1 was never properly
supported. This macro would have returned the negative long long
value, but all users assign it to a psched_tdiff_t (long), so
depending on the exact values, it might still be interpreted as a
large positive value. Additionally there was a second implementation
for the gettimeofday clocksource that didn't return the negative
difference but the bound value.
-
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: Sched - graphic smoothness under load - cfs-v13 sd-0.48
Michael Gerdau wrote: That's because the whole premise of your benchmark relies on a workload that yield()s itself to the eyeballs on most graphic card combinations when using glxgears. Your test remains a test of sched_yield in the presence of your workloads rather than anything else. If people like ck2 it's because in the real world with real workloads it is better, rather than on a yield() based benchmark. Repeatedly the reports are that 3d apps and games in normal usage under -ck are better than mainline and cfs. While I can't comment on the technical/implementational details of Con's claim I definitely have to agree from a users POV. Any of the sd/ck/cfs schedulers are an improvement on the current mainline, and hopefully they will continue to cross pollinate and evolve. Perhaps by 2.6.23 a clear best will emerge, or Linus will change his mind and make sd and cfs be compile options at build time. All my recent CPU intensive benchmarks show that both ck/sd and cfs are very decent scheduler and IMO superior to mainline for all _my_ usecases. In particular playing supertux while otherwise fully utilizing both CPUs on a dualcore works without any glitch and better than on mainline for both sd and cfs. I did some kernel compile timing numbers as part of my work with ctxbench, and there is little to choose between the schedulers under load, although the special case for sched_yield makes some loads perform better with cfs. With large memory and fast disk, a kernel make becomes a CPU benchmark, there's virtually no iowait not filled with another process. For me the huge difference you have for sd to the others increases the likelyhood the glxgears benchmark does not measure scheduling of graphic but something else. The glitch1 script generates a number of CPU bound processes updating the screen independently, which stresses both graphics performance and scheduler fairness. And once again I note that it's a *characterization* rather than a benchmark. The ability of the scheduler to deliver the same resources to multiple identical processes, and to keep another CPU bound process (glxgears) getting the processor at regular intervals is more revealing than the frames per second or loops run. I would expect sd to be better at this, since it uses a deadline concept, but in practice the gears pause, and then move rapidly or appear to jump. My reading on this is that the process starves for some ms, then gets a lot of CPU because it is owed more. I think I see this in games, but not being a game player I can't tell from experience if it's artifact or the games suck. That's what my test rig, based on a 15 year old boy and several cans of high caffeine soda, is used for. ;-) Anyway, I'm still in the process of collecting data or more precisely until recently constantly refined what data to collect and how. I plan to provide new benchmark results on CPU intensive tasks in a couple of days. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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.6.21] cramfs: add cramfs Linear XIP
To me, it looks like this work can be modified to use filemap_xip. How? - 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 3/7] lockdep: lock contention tracking
On Wed, 2007-05-23 at 12:11 -0400, Jason Baron wrote: On Wed, 23 May 2007, Peter Zijlstra wrote: On Wed, 2007-05-23 at 10:40 -0400, Jason Baron wrote: On Wed, 23 May 2007, Peter Zijlstra wrote: Count lock contention events per lock class. Additionally track the first four callsites that resulted in the contention. I think that we need the total number of locking calls, not just the total number of *contended* locking calls, in order to make the data significant. Same for waittime. Yes, this pollutes the fastpath. In the contention case, its one extra addition, and for the waittime, its a call the sched_clock(). I don't think that's too much to pay for much more meaningful data. The holdtime statistics add these numbers. ok, i see what you are saying...however, the 'waittime' statistic as implemented, is only recorded when we don't get the lock immediately. Thus, it's really measuring the waittime when there is lock contention. I understand that in the non-contended case we are only talking a a few cycles, but the fact that the non-contended case is not counted as another waittime of even zero length (so no measurement is required), might skew the stats a bit. For examples, if there was a lock that was almost never contended but one time happened to be contended for a long time, its average wait time would look really high. I'm not seeing how or why this is a problem. The number of contentions is reported on the same line, so it should be obvious. Your definition of wait-time is also obtainable from the numbers, one would just divide waittime-total by acquisitions, instead of contentions. - 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.22-rc2-mm1
On Wed, May 23, 2007 at 12:42:33AM -0700, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/
- A new readahead patch series. This needs serious review and performance
testing please.
- Added Ingo's CFS CPU scheduler
- Xen dom-U support is now in the x86 tree.
This patch silences the following warning:
WARNING: drivers/built-in.o(.text+0x500fd): Section mismatch: reference to
.init.data: (between 'pxm_to_node' and 'node_to_pxm')
WARNING: drivers/built-in.o(.text+0x50112): Section mismatch: reference to
.init.data: (between 'node_to_pxm' and 'acpi_get_pxm')
pxm_to_node() and node_to_pxm() reference node_to_pxm_map[] and
pxm_to_node_map[], which are __cpuinitdata. This patch marks pxm_to_node()
and node_to_pxm() __cpuinit accordingly.
Signed-off-by: William Irwin [EMAIL PROTECTED]
Index: mm-2.6.22-rc2/drivers/acpi/numa.c
===
--- mm-2.6.22-rc2.orig/drivers/acpi/numa.c 2007-05-23 09:35:02.932827713
-0700
+++ mm-2.6.22-rc2/drivers/acpi/numa.c 2007-05-23 09:35:48.919448341 -0700
@@ -43,14 +43,14 @@
static int __cpuinitdata node_to_pxm_map[MAX_NUMNODES]
= { [0 ... MAX_NUMNODES - 1] = PXM_INVAL };
-int pxm_to_node(int pxm)
+int __cpuinit pxm_to_node(int pxm)
{
if (pxm 0)
return NID_INVAL;
return pxm_to_node_map[pxm];
}
-int node_to_pxm(int node)
+int __cpuinit node_to_pxm(int node)
{
if (node 0)
return PXM_INVAL;
-
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] ARM/ARM26 Cleanup, using ARRAY_SIZE
Use the kernel wide ARRAY_SIZE when determining the array size of a struct. Signed-off-by: Jerry Stralko [EMAIL PROTECTED] --- diff --git a/arch/arm/kernel/dma-isa.c b/arch/arm/kernel/dma-isa.c index 0a3e9ad..c94ad71 100644 --- a/arch/arm/kernel/dma-isa.c +++ b/arch/arm/kernel/dma-isa.c @@ -19,6 +19,7 @@ #include linux/ioport.h #include linux/init.h #include linux/dma-mapping.h +#include linux/kernel.h #include asm/dma.h #include asm/io.h @@ -216,7 +217,7 @@ void __init isa_init_dma(dma_t *dma) request_dma(DMA_ISA_CASCADE, cascade); - for (i = 0; i sizeof(dma_resources) / sizeof(dma_resources[0]); i++) + for (i = 0; i ARRAY_SIZE(dma_resources); i++) request_resource(ioport_resource, dma_resources + i); } } - 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 -rt] ARM TLB flush fix: don't forget to re-enable preemption
Russell King wrote: On Wed, May 23, 2007 at 09:13:57AM -0700, Kevin Hilman wrote: On Wed, 2007-05-23 at 10:22 +0100, Russell King wrote: In which case shouldn't it be at the end of the function so it includes the write buffer handling as well? However, I think I agree with Daniel on this one. I don't see the point of the preempt_disable() here. Note that my patch simply adds an enable to match the disable added by the -rt patch. I'm not sure where the disable originally came from, but there are disable/enable pairs scattered throughout tlbflush.h in the -rt patch. If this one isn't necessary, then the others probably are not either. In most cases there are 2 mcr instructions inside the critical section. One for the dsb() and the other for the actual function. Russell, is there a reason any of these sections should be atomic? I don't see any reason for them to be - when switching to another process we'll generally do a full TLB flush anyway, so what's the point in making these flushes atomic? OK, I've removed the locally and will be doing some testing on OMAP2 (ARMv6.) I'll submit a patch to Ingo if things look good. In the meantime, my previous fix is still necessary for -rt to even work on ARM. Kevin - 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: Linux 2.6.22-rc2
On Tue, 22 May 2007 17:00:18 -0700 (PDT) Linus Torvalds [EMAIL PROTECTED] wrote: and the load off sk-sk_prot-ioctl oopses, because sk-sk_prot is corrupt and contains 0x8e3cad42, which is not a valid kernel pointer. The other oops is even worse. I also think it meshes with sky2 eth0: descriptor error q=0x280 get=285 [800042375e2e5e] put=285 and I suspect your memory got corrupted by sky2 reading the wrong descriptors, and overwriting kernel memory. So it's almost certainly some DMA problem. Now, _why_ you have DMA problems, I have no idea. But can you try: - disable CONFIG_PREEMPT - disable CONFIG_HIGHMEM if you have it on - just in general see if you can disable any kernel config options that might be unnecessary. to see if it changes the situation at all.. Thanks for looking at this. After further posts in the discussion I wasn't sure if you still wanted me to try this, but I thought it might be useful to see if (particularly) highmem support might change the behaviour, or the messages in any way that might lead to a clue. There was no change to the behaviour. I have a Core 2 duo, and 2 Gb of RAM, but I built a uniprocessor kernel (with apic), without highmem support, with no PREEMPT and without other unnecessary stuff. If by chance I got it working, my plan was to enable things one at a time. I won't get that oops on this setup though (never have, anyways... it was just the PCLinux install on that other hard disk which has now been returned to use elsewhere), but the messages on trying to transfer data are the same: First try (instant failure on trying to ssh): May 23 12:51:14 cramit kernel: sky2 eth0: enabling interface May 23 12:51:14 cramit kernel: sky2 eth0: ram buffer 0K May 23 12:51:16 cramit kernel: sky2 eth0: Link is up at 100 Mbps, full duplex, flow control both May 23 12:51:34 cramit kernel: sky2 :04:00.0: error interrupt status=0x1 May 23 12:51:34 cramit kernel: sky2 eth0: descriptor error q=0x280 get=7 [0] put=7 Second try after cold boot (failure on trying to transfer file): May 23 12:52:59 cramit kernel: sky2 eth0: enabling interface May 23 12:52:59 cramit kernel: sky2 eth0: ram buffer 0K May 23 12:53:01 cramit kernel: sky2 eth0: Link is up at 100 Mbps, full duplex, flow control both May 23 12:55:40 cramit kernel: sky2 :04:00.0: error interrupt status=0x8000 May 23 12:55:40 cramit kernel: sky2 eth0: hw error interrupt status 0x8 May 23 12:55:40 cramit kernel: sky2 eth0: MAC parity error This is exactly the behaviour I've been seeing. I still happen to have a Windows Vista install kicking around, so to make sure we're not flogging a dead horse I booted that and let it set up the yukon2 chip and I tested it. (more to make sure that eeprom update didn't break it). I used it for a bit and successfully transferred some large files from box running Samba. MS must be using some specific workaround or something. Mike Houston - 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/
maximum count of thermal zones and fans in acpi?
Hi,
I am currently implementing a general purpose shared library
for acpi focused on all the tools giving acpi information
like battery, thermal zones, fans, etc.
Since I was not able to find anything about it in the acpi
specs[0] (of course I didn't read every single page though)
and with a quick look into the kernel sources I wondered if
there is a maximum count for thermal zones and fans in the
acpi implementation of the kernel.
Every acpi module just calls proc_mkdir for example:
acpi_device_dir(device) = proc_mkdir(acpi_device_bid(device),
acpi_thermal_dir);
struct proc_dir_entry *proc_mkdir_mode(const char *name, mode_t mode,
struct proc_dir_entry *parent)
{
struct proc_dir_entry *ent;
ent = proc_create(parent, name, S_IFDIR | mode, 2);
if (ent) {
ent-proc_fops = proc_dir_operations;
ent-proc_iops = proc_dir_inode_operations;
if (proc_register(parent, ent) 0) {
kfree(ent);
ent = NULL;
}
}
return ent;
}
struct proc_dir_entry *proc_mkdir(const char *name,
struct proc_dir_entry *parent)
{
return proc_mkdir_mode(name, S_IRUGO | S_IXUGO, parent);
}
So is there no check for any max item count here?
I ask because I need to decide whether I want to allocate space for every
acpi object or to use a fixed size array for them depending on the maximum
item (where item is one device) count.
[0]: http://www.acpi.info/spec.htm
Kind regards
Nico
P.S. Please Cc me I am not subscribed
--
Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.
pgpq5nEgVEOgn.pgp
Description: PGP signature
Re: [PATCH 1/1] hotplug cpu: migrate a task within its cpuset
On Mon, 21 May 2007 15:08:56 -0500 [EMAIL PROTECTED] (Cliff Wickman) wrote: (this is a third submission -- corrects a locking/blocking issue pointed out by Nathan Lynch) When a cpu is disabled, move_task_off_dead_cpu() is called for tasks that have been running on that cpu. So I still have these three patches in the pending queue but I was rather hoping that the scheduler, sched-domains and cpuset people could take a look at them, please. They hit sched.c and cpuset.c mainly, and they might trash Ingo's CFS patch (I haven't checked). - 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: BUG: sleeping function called from invalid context at kernel/fork.c:385
Saw this when running strace -f on a script on 2.6.21 on ia64: BUG: sleeping function called from invalid context at kernel/fork.c:385 in_atomic():1, irqs_disabled():0 ... snip ... I could reproduce it via 'strace -f sleep 1' I'd say this is specific to ia64. Someone would have spotted it on x86 by now. I tried the strace -f sleep 1 on 2.6.22-rc2, and I didn't see this BUG there. Can you try your other test cases on the latest kernel. If it has already been fixed we can see about identifying the patch for possible backport to 2.6.21.stable -Tony - 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 3/7] lockdep: lock contention tracking
On Wed, 23 May 2007, Peter Zijlstra wrote: On Wed, 2007-05-23 at 12:11 -0400, Jason Baron wrote: On Wed, 23 May 2007, Peter Zijlstra wrote: On Wed, 2007-05-23 at 10:40 -0400, Jason Baron wrote: On Wed, 23 May 2007, Peter Zijlstra wrote: Count lock contention events per lock class. Additionally track the first four callsites that resulted in the contention. I think that we need the total number of locking calls, not just the total number of *contended* locking calls, in order to make the data significant. Same for waittime. Yes, this pollutes the fastpath. In the contention case, its one extra addition, and for the waittime, its a call the sched_clock(). I don't think that's too much to pay for much more meaningful data. The holdtime statistics add these numbers. ok, i see what you are saying...however, the 'waittime' statistic as implemented, is only recorded when we don't get the lock immediately. Thus, it's really measuring the waittime when there is lock contention. I understand that in the non-contended case we are only talking a a few cycles, but the fact that the non-contended case is not counted as another waittime of even zero length (so no measurement is required), might skew the stats a bit. For examples, if there was a lock that was almost never contended but one time happened to be contended for a long time, its average wait time would look really high. I'm not seeing how or why this is a problem. The number of contentions is reported on the same line, so it should be obvious. Your definition of wait-time is also obtainable from the numbers, one would just divide waittime-total by acquisitions, instead of contentions. agreed, I just want to point out that under my definition of waitime, I would have to make the assumption that the waittime is 0 for a lock that is acquired without fallback to the slowpath. For a spinlock acquisition, this is likely a fair assumption, however the trylock path for semaphores can be longer. Acked-by: Jason Baron [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: Linux 2.6.22-rc2
On Wed, 23 May 2007, Mike Houston wrote: I still happen to have a Windows Vista install kicking around, so to make sure we're not flogging a dead horse I booted that and let it set up the yukon2 chip and I tested it. (more to make sure that eeprom update didn't break it). I used it for a bit and successfully transferred some large files from box running Samba. MS must be using some specific workaround or something. I think there is some lspci-like thing for windows too. Can you do the equivalent of lspci -vvxxx on that box under both Linux and Windows? _If_ it's some PCI config space thing (which is not at all guaranteed - it could be about setup in random MMIO ranges) it might give us some clues. 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: 2.6.21-mm2: ACPI exception on resume
On Wed, May 23, 2007 at 02:13:30PM -0300, Henrique de Moraes Holschuh wrote:
On Wed, 23 May 2007, Rafael J. Wysocki wrote:
While I agree with that, it would really be helpful if you tested the
latest -rc
kernel and saw if the bug was present in there.
If the bug is not present in the latest -rc, it'll be possible to identify
the
patch that causes it to appear in -mm and find the reason of the breakage.
And, once we know the reason, we will be able to find out how to best fix the
problem.
So, do please test latest -rc, or bissect to the last known-good kernel. As
I said, we need further data points to do anything.
This isn't conclusive as this bug is fairly hard to trigger, but it
looks like the culprit may have been this patch and not anything in
-mm or mainline. So the below patch doesn't help the problem it was
intended for (lid switch no longer wakes up S2R after a S2D cycle) and
appears to be implicated in making my EC unhappy.
-
Can you please check if the appended debug patch helps?
Rafael
---
kernel/power/disk.c |4 ++--
kernel/power/user.c |8
2 files changed, 6 insertions(+), 6 deletions(-)
Index: linux-2.6.21-rc7/kernel/power/disk.c
===
--- linux-2.6.21-rc7.orig/kernel/power/disk.c
+++ linux-2.6.21-rc7/kernel/power/disk.c
@@ -170,9 +170,9 @@ int pm_suspend_disk(void)
if (in_suspend) {
enable_nonboot_cpus();
- platform_finish();
device_resume();
resume_console();
+ platform_finish();
pr_debug(PM: writing image.\n);
error = swsusp_write();
if (!error)
@@ -189,9 +189,9 @@ int pm_suspend_disk(void)
Enable_cpus:
enable_nonboot_cpus();
Resume_devices:
- platform_finish();
device_resume();
resume_console();
+ platform_finish();
Thaw:
unprepare_processes();
Finish:
Index: linux-2.6.21-rc7/kernel/power/user.c
===
--- linux-2.6.21-rc7.orig/kernel/power/user.c
+++ linux-2.6.21-rc7/kernel/power/user.c
@@ -170,11 +170,11 @@ static inline int snapshot_suspend(int p
}
enable_nonboot_cpus();
Resume_devices:
+ device_resume();
+ resume_console();
if (platform_suspend)
platform_finish();
- device_resume();
- resume_console();
Finish:
mutex_unlock(pm_mutex);
return error;
@@ -202,11 +202,11 @@ static inline int snapshot_restore(int p
enable_nonboot_cpus();
Resume_devices:
+ device_resume();
+ resume_console();
if (platform_suspend)
platform_finish();
- device_resume();
- resume_console();
Finish:
pm_restore_console();
mutex_unlock(pm_mutex);
--
Mathematics is the supreme nostalgia of our time.
-
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] Define new percpu interface for shared data -- version 3
On Tue, 22 May 2007 11:20:03 -0700 Fenghua Yu [EMAIL PROTECTED] wrote: per cpu data section contains two types of data. One set which is exclusively accessed by the local cpu and the other set which is per cpu, but also shared by remote cpus. In the current kernel, these two sets are not clearely separated out. This can potentially cause the same data cacheline shared between the two sets of data, which will result in unnecessary bouncing of the cacheline between cpus. One way to fix the problem is to cacheline align the remotely accessed per cpu data, both at the beginning and at the end. Because of the padding at both ends, this will likely cause some memory wastage and also the interface to achieve this is not clean. This patch: Moves the remotely accessed per cpu data (which is currently marked as cacheline_aligned_in_smp) into a different section, where all the data elements are cacheline aligned. And as such, this differentiates the local only data and remotely accessed data cleanly. OK, but could we please have a concise description of the impact of these changes on kernel memory footprint? Increase or decrease? And by approximately how much? 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: Google are using linux kernel - what do you know about the source?
On Wed, 23 May 2007 19:52:20 +0300 Matti Aarnio [EMAIL PROTECTED] wrote: Please read the FAQ at http://www.tux.org/lkml/ There you will notice that use of Linux KERNEL does not mean that your must publish sources for your proprietary application, or to make it easy for somebody to make a distribution competeting with yours. Did I seem to be unaware of this? :-) In any case, here is the answer: http://code.google.com/mirror/gsa.html -- Gergo Szakal - 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: Google are using linux kernel - what do you know about the source?
On May 23 2007 20:00, Gergo Szakal wrote: Please read the FAQ at http://www.tux.org/lkml/ There you will notice that use of Linux KERNEL does not mean that your must publish sources for your proprietary application, or to make it easy for somebody to make a distribution competeting with yours. Did I seem to be unaware of this? :-) In any case, here is the answer: http://code.google.com/mirror/gsa.html kernel-2.2.14 wtf :p Jan -- - 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] joydev.c automatic re-calibration
On Wed, 23 May 2007 01:33:14 +0100 Renato Golin [EMAIL PROTECTED] wrote: This small patch adds the automatic recalibration feature without spoiling previously calibrated devices. It's a fix for those joysticks that report faulty range, specially Saitek Cyborg Evo Force. File: drivers/input/joydev.c Fix: - extracted code from joydev_connect to method joydev_calculate_correction to be able to call it from both joydev_event upon recalibration and joydev_connect during first connection. - on joydev_connect check ranges and zero calibration if found out of range - on joydev_event, every time found out of range, update min/max and recalculate the correction A few patch protocol things: - Please always prepare patches in `patch -p1' form - Include a Signed-off-by: as per Documentation/SubmittingPatches, section 11. - Avoid including two copies of the patch in the one email. Inlined plain text is preferred, ext/plain attachments are grudgingly accepted. I descrambled the patch, fixed a reject and queued it up in the -mm tree for Dmitry's consideration, 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: signals logged / [RFC] log out-of-virtual-memory events
On 5/21/07, Folkert van Heusden [EMAIL PROTECTED] wrote:
What about the following enhancement: I check with sig_fatal if it would
kill the process and only then emit a message. So when an application
takes care itself of handling it nothing is printed.
+/* emit some logging for unhandled signals
+ */
+if (sig_fatal(t, sig))
Not unhandled_signal()?
Can we already use that one in send_signal? As the signal needs to be
send first I think before we know if it was handled or not? sig_fatal
checks if the handler is set to default - which is it is not taken care
of.
+{
if (sig_fatal(t, sig)) {
+printk(KERN_WARNING Sig %d send to %d owned by %d.%d (%s)\n,
s/send/sent/;
+sig, t - pid, t - uid, t - gid, t - comm);
t-pid, t-uid, t-gid, t-comm);
Description:
This patch adds code to the signal-sender making it log a message when
an unhandled fatal signal will be delivered.
Gargh ... why does this want to be in the *kernel*'s logs? In any case, can
you please make this KERN_INFO (or lower) instead of KERN_WARNING.
-
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/
[RFC 1/5] inode reservation v0.1
This patch is only experimental, just have a try whether the subdirectory inode reservation idea works. Now the answer is it works, and I am working on an improved version for this patch. The basic idea of subdirecctory inode reservation is to avoid unnecessary redundant meta data writing and hard disk seeking. Detailed idea can be found here:http://lkml.org/lkml/2007/3/26/180 This email has another 4 extra parts: 1) ext4 kernel patch 2) e2fsprogs patch 3) current benchmark 4) next step working The reason to release this unstable patch is: * I want others to know I am working on it. * The result of benchmark indecates that this work maybe is valuable. * Hope others can give me feedback at very basic phase of this patch. I should thank Adreas Dilger, who firstly introduces this idea to me. Also I should thank other friends in #linuxfs at irc.oftc.org, great helps to me. In the next several months, I will try best to write a usable patch :-) Coly - 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: Linux 2.6.22-rc2
On Wed, 23 May 2007 10:46:05 -0700 (PDT) Linus Torvalds [EMAIL PROTECTED] wrote: On Wed, 23 May 2007, Mike Houston wrote: I still happen to have a Windows Vista install kicking around, so to make sure we're not flogging a dead horse I booted that and let it set up the yukon2 chip and I tested it. (more to make sure that eeprom update didn't break it). I used it for a bit and successfully transferred some large files from box running Samba. MS must be using some specific workaround or something. I think there is some lspci-like thing for windows too. Can you do the equivalent of lspci -vvxxx on that box under both Linux and Windows? _If_ it's some PCI config space thing (which is not at all guaranteed - it could be about setup in random MMIO ranges) it might give us some clues. Linus lspci will work in windows, it is probably part of cygwin. -- Stephen Hemminger [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/
[RFC 2/5] inode reservation v0.1 (ext4 kernel patch)
The patch is generated based on 2.6.20-ext4-2 branch. you can find the
benchmark from other email.
DO NOT waste time on reading the patch :-) I post this patch here is to
show that I really spent time on it and the patch can work (even not
well).
diff --git a/Makefile b/Makefile
index 7e2750f..21d21e4 100644
--- a/Makefile
+++ b/Makefile
@@ -1,8 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 20
-EXTRAVERSION =
-NAME = Homicidal Dwarf Hamster
+EXTRAVERSION = inores
# *DOCUMENTATION*
# To see a list of typical targets execute make help
diff --git a/fs/ext4/bitmap.c b/fs/ext4/bitmap.c
index 11e93c1..daf88b4 100644
--- a/fs/ext4/bitmap.c
+++ b/fs/ext4/bitmap.c
@@ -30,3 +30,29 @@ unsigned long ext4_count_free (struct buffer_head *
map, unsigned int numchars)
#endif /* EXT4FS_DEBUG */
+/*
+ * Read the inode allocation bitmap for a given block_group, reading
+ * into the specified slot in the superblock's bitmap cache.
+ *
+ * Return buffer_head of bitmap on success or NULL.
+ */
+struct buffer_head *
+read_inode_bitmap(struct super_block * sb, unsigned long block_group)
+{
+ struct ext4_group_desc *desc;
+ struct buffer_head *bh = NULL;
+
+ desc = ext4_get_group_desc(sb, block_group, NULL);
+ if (!desc)
+ goto error_out;
+
+ bh = sb_bread(sb, ext4_inode_bitmap(sb, desc));
+ if (!bh)
+ ext4_error(sb, read_inode_bitmap,
+ Cannot read inode bitmap -
+ block_group = %lu, inode_bitmap = %llu,
+ block_group, ext4_inode_bitmap(sb, desc));
+error_out:
+ return bh;
+}
+
diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
index 427f830..bb83112 100644
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -45,32 +45,6 @@
/*
- * Read the inode allocation bitmap for a given block_group, reading
- * into the specified slot in the superblock's bitmap cache.
- *
- * Return buffer_head of bitmap on success or NULL.
- */
-static struct buffer_head *
-read_inode_bitmap(struct super_block * sb, unsigned long block_group)
-{
- struct ext4_group_desc *desc;
- struct buffer_head *bh = NULL;
-
- desc = ext4_get_group_desc(sb, block_group, NULL);
- if (!desc)
- goto error_out;
-
- bh = sb_bread(sb, ext4_inode_bitmap(sb, desc));
- if (!bh)
- ext4_error(sb, read_inode_bitmap,
- Cannot read inode bitmap -
- block_group = %lu, inode_bitmap = %llu,
- block_group, ext4_inode_bitmap(sb, desc));
-error_out:
- return bh;
-}
-
-/*
* NOTE! When we get the inode, we're the only people
* that have access to it, and as such there are no
* race conditions we have to worry about. The inode
@@ -288,6 +262,12 @@ static int find_group_orlov(struct super_block *sb,
struct inode *parent)
for (i = 0; i ngroups; i++) {
group = (parent_group + i) % ngroups;
desc = ext4_get_group_desc (sb, group, bh);
+ if (test_opt(sb, INORES)
+ (ext4_unreserved_inodes(sb, group)
+ EXT4_INIT_RESERVE_INODES)) {
+ printk(KERN_DEBUG no enough reserved inodes in group %d\n, group);
+ continue;
+ }
if (!desc || !desc-bg_free_inodes_count)
continue;
if (le16_to_cpu(desc-bg_used_dirs_count) = best_ndir)
@@ -323,6 +303,12 @@ static int find_group_orlov(struct super_block *sb,
struct inode *parent)
for (i = 0; i ngroups; i++) {
group = (parent_group + i) % ngroups;
desc = ext4_get_group_desc (sb, group, bh);
+ if (test_opt(sb, INORES)
+ (ext4_unreserved_inodes(sb, group)
+ EXT4_INIT_RESERVE_INODES)) {
+ printk(KERN_DEBUG no enough reserved inodes in group %d\n, group);
+ continue;
+ }
if (!desc || !desc-bg_free_inodes_count)
continue;
if (le16_to_cpu(desc-bg_used_dirs_count) = max_dirs)
@@ -335,6 +321,9 @@ static int find_group_orlov(struct super_block *sb,
struct inode *parent)
}
fallback:
+ printk(KERN_DEBUG reach fallback, disable INORES\n);
+ return -1; /* for test */
+ clear_opt(sbi-s_mount_opt, INORES);
for (i = 0; i ngroups; i++) {
group = (parent_group + i) % ngroups;
desc = ext4_get_group_desc (sb, group, bh);
@@ -414,6 +403,598 @@ static int find_group_other(struct super_block
*sb, struct inode *parent)
return -1;
}
+
+static int ext4_inores_newdir_ino(handle_t * handle,
+ struct inode * dir,
+ time_t ctime,
+ unsigned long * ino)
+{
+ struct super_block * sb;
+ struct ext4_sb_info * sbi;
+ int group;
+ struct buffer_head * bitmap_bh = NULL, * bh2;
+ unsigned long lastres_ino, start_ino, end_ino;
+ struct ext4_magic_inode * link_minode, * lastres_minode;
+ struct ext4_iloc link_iloc, lastres_iloc;
+ struct ext4_group_desc * gdp = NULL;
+ int itable_offset;
+ int ret = 0;
+
+ sb = dir-i_sb;
+ sbi = EXT4_SB(sb);
+
+find_group_again:
+ group = find_group_orlov(sb, dir);
+
+ if (group == -1) {
+ printk(no space in find_group_orlove.\n);
+ return -ENOSPC;
+ }
+ if (!test_opt (sb, INORES)) {
+ printk(KERN_DEBUG INORES is not set, return 0.\n);
+ * ino = 0;
+ return 0;
+ }
+
+ /*
+ * the corresponded block is already loaded into memory in
+ * find_group_orlov(), this lock will not hurt performance
+ * in common case.
+ */
+ spin_lock(sb_bgl_lock(sbi, group));
+ if (ext4_unreserved_inodes(sb, group) EXT4_INIT_RESERVE_INODES) {
+
[RFC 4/5] inode reservation v0.1 (benchmark result)
Current patch avoids inodes from different directories mixed together in the inode table. Therefore the benchmakr emulate a situation that mixes inodes of different sub-directories together. and record the time on removing them all. In the first part, reserving 16 inodes for each new created directory. Therefore 14 files can only use 1 reserved block for each directory in inode table, obviously, the result of benchmark is the best case :-) Enviornment: 1) create 9890 directory, create files in each directory alternatively 2) kernel version 2.6.20-mm, the ext4 subdir-inode-reservation is patched based on 2.6.20-mm 3) 14 files in each subdirectory. 9890 sub directories in mount_point/mailbox/ 4) mount with option data=writeback 5) each operation followed by a reboot 6) EXT4_INIT_RESERVE_INODES = 16 = data=writeback remove directories and files by rm -rf: * ext3 read 16m56.979s user 0m0.156s sys 0m21.449s * ext4org real 18m38.809s user 0m0.636s sys 0m37.422s * ext4inores real 7m57.437s user 0m0.452s sys 0m34.698s = data=ordered remove directories and files by rm -rf: * ext3 real 17m23.435s user 0m0.140s sys 0m21.709s * ext4org real 17m39.515s user 0m0.120s sys 0.22.097s * ext4inores real 7m41.365s user 0m0.196s sys 0m24.210s = data=journal remove directories and files by rm -rf: * ext3 real 12m50.545s user 0m0.152s sys 0m22.725s * ext4org real 13m43.910s user 0m0.196s sys 0m23.161s * ext4inores real 7m49.915s user 0m0.168s sys 0m23.633s Due to the bad design of magic inode and the on-disk layout of magic inode. When 30 files created alternatively in each directory, no performance advantage exists. When 50 files created alternatively in each directory, the patched ext4 will use double time on removing all the files and directories. Therefore, in the next version a new on-disk layout will be used. - 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/
[RFC 5/5] inode reservation v0.1 (next step working)
From the benchmark and the experimental inores patch on ext4, it can be found that inode reservation on ext4 is a good idea to be tried. One of the original idea of inode reservation is NOT modifying on-disk format. Current magic inode can make it, but use a magic inodes list to link each reserved inode block together is not a good idea. Indeed, this is a performance killer. 1, Therefor, group descriptor has to be modified to add a new member --- this new member records the lastest reserved inode in inode table of each block group. 2, Use rest room in magic inode (sizeof(ext4_inode) - sizeof(ext4_magic_inode)) to record other reserved inode blocks. This method can reduce number of magic inodes, which can minimize I/O for magic inodes. 3, Use magic inode cache. Most of the magic inode accessings are reading (not writing), therefore, caching can help to reduce most of the read I/O for magic inode. 4, Modify mke2fs to support new on-disk layout for inode reservation. Coly - 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/
[RFC 3/5] inode reservation v0.1 (e2fsprogs patch)
This patch only makes mke2fs support on-disk layout for inode
reservation. Just for experiment. e2fsck and other utils can not work
with magic inode yet.
diff -u -r
e2fsprogs-1.39-tyt1/debugfs/debugfs.c ../e2fsprogs/debugfs/debugfs.c
--- e2fsprogs-1.39-tyt1/debugfs/debugfs.c 2006-10-07 11:42:54.0
+0800
+++ ../e2fsprogs/debugfs/debugfs.c 2007-03-29 23:05:05.0 +0800
@@ -1215,7 +1215,8 @@
} else
mode = 010755;
- retval = ext2fs_new_inode(current_fs, dir, mode, 0, free_inode);
+ retval = ext2fs_new_inode(current_fs, dir, mode, 0, free_inode,
+ LINUX_S_ISDIR(mode) ? 1 : 0);
if (retval)
com_err(ext2fs_new_inode, retval, 0);
else
@@ -1294,7 +1295,7 @@
return;
}
- retval = ext2fs_new_inode(current_fs, cwd, 010755, 0, newfile);
+ retval = ext2fs_new_inode(current_fs, cwd, 010755, 0, newfile, 0);
if (retval) {
com_err(argv[0], retval, 0);
close(fd);
@@ -1384,7 +1385,7 @@
goto usage;
if (check_fs_read_write(argv[0]))
return;
- retval = ext2fs_new_inode(current_fs, cwd, 010755, 0, newfile);
+ retval = ext2fs_new_inode(current_fs, cwd, 010755, 0, newfile, 0);
if (retval) {
com_err(argv[0], retval, 0);
return;
diff -u -r
e2fsprogs-1.39-tyt1/debugfs/util.c ../e2fsprogs/debugfs/util.c
--- e2fsprogs-1.39-tyt1/debugfs/util.c 2006-10-07 11:40:28.0
+0800
+++ ../e2fsprogs/debugfs/util.c 2007-03-31 02:07:10.0 +0800
@@ -119,7 +119,7 @@
retval = ext2fs_namei(current_fs, root, cwd, str, ino);
if (retval) {
- com_err(str, retval, );
+ com_err(str, retval, );
return 0;
}
return ino;
diff -u -r
e2fsprogs-1.39-tyt1/e2fsck/pass1.c ../e2fsprogs/e2fsck/pass1.c
--- e2fsprogs-1.39-tyt1/e2fsck/pass1.c 2006-10-07 11:42:54.0
+0800
+++ ../e2fsprogs/e2fsck/pass1.c 2007-03-31 02:05:25.0 +0800
@@ -248,7 +248,7 @@
struct ext2_super_block *sb = ctx-fs-super;
struct ext2_inode_large *inode;
struct ext2_ext_attr_entry *entry;
- char *start, *end, *name;
+ char *start, *end;
int storage_size, remain, offs;
int problem = 0;
@@ -329,7 +329,7 @@
/* simple remove all possible EA(s) */
*((__u32 *)start) = 0UL;
- e2fsck_write_inode_full(ctx, pctx-ino, inode,
+ e2fsck_write_inode_full(ctx, pctx-ino, (struct ext2_inode *)inode,
EXT2_INODE_SIZE(sb), pass1);
}
@@ -919,7 +919,6 @@
if (ctx-flags E2F_FLAG_RESIZE_INODE) {
ext2fs_block_bitmap save_bmap;
- errcode_t retval;
save_bmap = fs-block_map;
fs-block_map = ctx-block_found_map;
diff -u -r
e2fsprogs-1.39-tyt1/e2fsck/pass3.c ../e2fsprogs/e2fsck/pass3.c
--- e2fsprogs-1.39-tyt1/e2fsck/pass3.c 2006-10-07 11:40:28.0
+0800
+++ ../e2fsprogs/e2fsck/pass3.c 2007-03-29 23:05:05.0 +0800
@@ -436,7 +436,7 @@
* Next find a free inode.
*/
retval = ext2fs_new_inode(fs, EXT2_ROOT_INO, 040700,
- ctx-inode_used_map, ino);
+ ctx-inode_used_map, ino, 1);
if (retval) {
pctx.errcode = retval;
fix_problem(ctx, PR_3_ERR_LPF_NEW_INODE, pctx);
diff -u -r
e2fsprogs-1.39-tyt1/lib/ext2fs/alloc.c ../e2fsprogs/lib/ext2fs/alloc.c
--- e2fsprogs-1.39-tyt1/lib/ext2fs/alloc.c 2006-10-07 11:40:28.0
+0800
+++ ../e2fsprogs/lib/ext2fs/alloc.c 2007-04-30 15:21:01.0 +0800
@@ -26,6 +26,192 @@
#include ext2_fs.h
#include ext2fs.h
+
+static errcode_t ext2fs_reserve_inodes_area(ext2_filsys fs,
+ struct ext2_magic_inode * prev_link_minode)
+{
+ struct ext2_magic_inode lastres_minode;
+ struct ext2_magic_inode new_link_minode;
+ ext2_ino_t reserv_size;
+ ext2_ino_t new_link_ino;
+ ext2_ino_t lastres_ino;
+ ext2_ino_t dir_group;
+ ext2_ino_t itable_idx;
+ int find = 0;
+ errcode_t retval;
+
+ reserv_size = prev_link_minode-mi_next_ressize;
+ if(reserv_size EXT2_INODES_PER_GROUP(fs-super))
+ return EXT2_ET_MAGIC_INODE_CORRUPT;
+
+ for(dir_group = 0; dir_group fs-group_desc_count; dir_group ++)
+ {
+ lastres_ino = ext2fs_get_group_lastres_ino(fs, dir_group);
+ retval = ext2fs_read_magic_inode(fs, lastres_ino,
+ lastres_minode);
+ if(retval)
+ return retval;
+ retval = ext2fs_check_magic_inode(lastres_minode,
+ EXT2_MINODE_TYPE_LASTRES);
+ if(retval)
+ return retval;
+ itable_idx = lastres_minode.mi_lastres_ino %
+ EXT2_INODES_PER_GROUP(fs-super);
+ if((EXT2_INODES_PER_GROUP(fs-super) - itable_idx) =
+ reserv_size) {
+ find = 1;
+ break;
+ }
+ }
+ if (!find)
+ return EXT2_ET_DIR_NO_SPACE;
+ new_link_ino = lastres_minode.mi_lastres_ino + reserv_size;
+ if(ext2fs_test_inode_bitmap(fs-inode_map, new_link_ino))
+ return EXT2_ET_MAGIC_INODE_CORRUPT;
+ ext2fs_inode_alloc_stats2(fs, new_link_ino, +1, 0);
+ ext2fs_setup_magic_inode(new_link_minode,
+ EXT2_MINODE_TYPE_LINK);
+ new_link_minode.mi_next_ino = 0;
+ new_link_minode.mi_parent_ino = prev_link_minode-mi_parent_ino;
+ new_link_minode.mi_current_ressize = reserv_size;
+ reserv_size *= 2;
+ if(reserv_size EXT2_INODES_PER_GROUP(fs-super))
+ reserv_size = EXT2_INODES_PER_GROUP(fs-super);
+ new_link_minode.mi_next_ressize = reserv_size;
+ retval = ext2fs_write_magic_inode(fs, new_link_ino, new_link_minode);
+ if(retval)
+ return retval;
+ lastres_minode.mi_lastres_ino = new_link_ino;
+ retval =
Re: [RFC PATCH] /sys/block - /sys/class/block (Fedora 3 4 testers wanted)
On Wed, May 23, 2007 at 07:39:59AM +0200, Cornelia Huck wrote: On Tue, 22 May 2007 17:32:55 -0700, Greg KH [EMAIL PROTECTED] wrote: On Tue, May 22, 2007 at 06:28:12PM +0200, Cornelia Huck wrote: On Tue, 22 May 2007 10:25:01 +0200, Cornelia Huck [EMAIL PROTECTED] wrote: I tried this on one of our internal drivers, which is based on FC 3 (or 4, can look this up). With s390 defconfig, it is unable to open the root device /dev/dasda1 (which is unsurprising, considering udev (063) decided to create /dev/dasda(1) as a character node instead of a block node). Just to be clear, it's fsck that complains: Checking filesystems Checking all file systems. [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/dasda1 fsck.ext3: No such device or address while trying to open /dev/dasda1 Possibly non-existent or swap device? [FAILED] (so that is after udev has been started and obviously dasda1 could be accessed) But /dev/dasda1 isn't present? Or why would fsck be complaining here? See above. /dev/dasda1 exists, but strangely as a character device, which makes fsck unhappy. When I look at the system, /sys/block/ and /sys/class/block/ look sane at first glance (working on a 3270 console is usally PITA...) Even more surprisingly, the system comes up fine (once I added ptmx to makedev.d/) with CONFIG_SYSFS_DEPRECATED not set. /sys/block/ and /sys/class/block/ look just like expected. (Unfortunately, our lsdasd tool breaks with this...) I'll see if I can find out more. I currently have the inkling that lrwxrwxrwx 1 root root0 May 22 15:59 block:dasda1- ../../../class/block/dasda1 in /sys/block/dasda/ is the culprit. Why? See the paragraph just below, but it's more like a hunch currently. In all other versions I've tried (without CONFIG_SYSFS_DEPRECATED, and on an older kernel with and without CONFIG_SYSFS_DEPRECATED), it's always dasda1. That's just a back symlink, the real device should still be there. It is, but somehow udev seems confused. Oh, and yes, you will probably have to have CONFIG_SYSFS_DEPRECATED enabaled to have a chance for these to work on Fedora 4 or 3. Hmpf. That's just the problem :) - enable CONFIG_SYSFS_DEPRECATED: fails as described - disable CONFIG_SYSFS_DEPRECATED: works If one of the two was to fail, I'd rather expect it the other way around... Ok, yeah, that is wierd. Kay found the problem (he's traveling right now) and here's his updated version of the patch which should work for everyone involved. Please let me know if this causes any problems or not. thanks, greg k-h From: Kay Sievers [EMAIL PROTECTED] Subject: Driver core: convert block from raw kobjects to core devices This moves the block devices to /sys/class/block. It will create a flat list of all block devices, with the disks and partitions in one directory. For compatibility /sys/block is created and contains symlinks to the disks. /sys/class/block |-- sda - ../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda |-- sda1 - ../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda1 |-- sda10 - ../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda10 |-- sda5 - ../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda5 |-- sda6 - ../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda6 |-- sda7 - ../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda7 |-- sda8 - ../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda8 |-- sda9 - ../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda9 `-- sr0 - ../../devices/pci:00/:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 /sys/block/ |-- sda - ../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda `-- sr0 - ../devices/pci:00/:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 Signed-off-by: Kay Sievers [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] --- block/genhd.c | 413 ++--- block/ll_rw_blk.c |4 drivers/base/core.c| 16 + drivers/block/aoe/aoeblk.c | 51 ++--- drivers/block/nbd.c| 15 - drivers/ide/ide-probe.c|2 drivers/md/dm.c|2 drivers/md/md.c|8 fs/block_dev.c |8 fs/partitions/check.c | 304 +++-- include/linux/genhd.h | 23 +- init/do_mounts.c | 108 --- 12 files changed, 359 insertions(+), 595 deletions(-) --- a/block/genhd.c +++ b/block/genhd.c @@ -17,8 +17,12 @@ #include linux/buffer_head.h #include linux/mutex.h -struct kset block_subsys; -static DEFINE_MUTEX(block_subsys_lock); +extern struct class
Re: [PATCH] ARM/ARM26 Cleanup, using ARRAY_SIZE
On Wed, May 23, 2007 at 01:27:11PM -0400, Gerb Stralko wrote: Use the kernel wide ARRAY_SIZE when determining the array size of a struct. Signed-off-by: Jerry Stralko [EMAIL PROTECTED] Whitespace damanged patch, probably due to using format=flowed in your mailer. Please get a proper mail client. 8) Also, please note that ARM and ARM26 are two separate architectures maintained by two separate people. Please don't confuse them and merge patches - it's about the same level of evilness as labelling PPC and i386 as one architecture and expecting PPC folk to take the lot. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - 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] headercheck: add dependency check and improve speed
Introduced a perl based script to do the actual check of the headers. Modified Makfile.headerinst so all files in a dir is checked with one call to checkhdr.pl script. The file check is used as marker when last run was executed. And the file .check.cmd contains a list of dependencies used by make to determine if a new check should be executed. The perl script was named check* to follow same naming as other check scripts. The speedup is 10 seconds for a build with headercheck enabled. Signed-off-by: Sam Ravnborg [EMAIL PROTECTED] --- Linus complained that the header check part was too slow on his mac-mini. So as the well trained monkey^Whacker I am I went ahead and optimized it. The unidef and install part could be optimized too but that will be another time. David - I assume you will take it in your tree? Sam b/lib/Kconfig.debug|1 b/scripts/Makefile.headersinst | 51 +-- b/scripts/checkhdr.pl | 53 + scripts/hdrcheck.sh| 10 --- 4 files changed, 82 insertions(+), 33 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index fbc5c62..596f973 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -70,6 +70,7 @@ config HEADERS_CHECK relevant for userspace, say 'Y', and check the headers exported to $(INSTALL_HDR_PATH) (usually 'usr/include' in your build tree), to make sure they're suitable. + Note: Enabling this check requires perl to be installed config DEBUG_KERNEL bool Kernel debugging diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst index 8cd6301..988e5ba 100644 --- a/scripts/Makefile.headersinst +++ b/scripts/Makefile.headersinst @@ -23,6 +23,15 @@ HDRSED := sed -e s/ inline / __inline__ /g \ _dst := $(if $(dst),$(dst),$(obj)) +# file generated during checktime listing depfiles and incfiles +depsfile := $(INSTALL_HDR_PATH)/$(_dst)/.check.cmd +checkfile := $(INSTALL_HDR_PATH)/$(_dst)/check + +# Include autogenerated file listing depfiles and incfiles +ifneq ($(wildcard $(depsfile)),) + include $(depsfile) +endif + ifeq (,$(patsubst include/asm/%,,$(obj)/)) # For producing the generated stuff in include/asm for biarch builds, include # both sets of Kbuild files; we'll generate anything which is mentioned in @@ -56,22 +65,18 @@ subdir-y:= $(patsubst %/,%,$(filter %/, $(header-y))) header-y := $(filter-out %/, $(header-y)) header-y := $(filter-out $(unifdef-y),$(header-y)) -# stamp files for header checks -check-y:= $(patsubst %,.check.%,$(header-y) $(unifdef-y) $(objhdr-y)) +# All files to check for this dir +check-y:= $(header-y) $(unifdef-y) $(objhdr-y) # Work out what needs to be removed oldheaders := $(patsubst $(INSTALL_HDR_PATH)/$(_dst)/%,%,$(wildcard $(INSTALL_HDR_PATH)/$(_dst)/*.h)) -unwanted := $(filter-out $(header-y) $(unifdef-y) $(objhdr-y),$(oldheaders)) - -oldcheckstamps := $(patsubst $(INSTALL_HDR_PATH)/$(_dst)/%,%,$(wildcard $(INSTALL_HDR_PATH)/$(_dst)/.check.*.h)) -unwanted += $(filter-out $(check-y),$(oldcheckstamps)) +unwanted := $(filter-out $(check-y),$(oldheaders)) # Prefix them all with full paths to $(INSTALL_HDR_PATH) -header-y := $(patsubst %,$(INSTALL_HDR_PATH)/$(_dst)/%,$(header-y)) -unifdef-y := $(patsubst %,$(INSTALL_HDR_PATH)/$(_dst)/%,$(unifdef-y)) -objhdr-y := $(patsubst %,$(INSTALL_HDR_PATH)/$(_dst)/%,$(objhdr-y)) -check-y:= $(patsubst %,$(INSTALL_HDR_PATH)/$(_dst)/%,$(check-y)) - +header-y := $(patsubst %,$(INSTALL_HDR_PATH)/$(_dst)/%,$(header-y)) +unifdef-y := $(patsubst %,$(INSTALL_HDR_PATH)/$(_dst)/%,$(unifdef-y)) +objhdr-y := $(patsubst %,$(INSTALL_HDR_PATH)/$(_dst)/%,$(objhdr-y)) +check-y:= $(patsubst %,$(INSTALL_HDR_PATH)/$(_dst)/%,$(check-y)) ifdef ALTARCH ifeq ($(obj),include/asm-$(ARCH)) @@ -96,9 +101,9 @@ quiet_cmd_unifdef = UNIFDEF $(patsubst $(INSTALL_HDR_PATH)/%,%,$@) cmd_unifdef= $(UNIFDEF) $(patsubst $(INSTALL_HDR_PATH)/$(_dst)/%,$(srctree)/$(obj)/%,$@) \ | $(HDRSED) $@ || : -quiet_cmd_check = CHECK $(patsubst $(INSTALL_HDR_PATH)/$(_dst)/.check.%,$(_dst)/%,$@) - cmd_check = $(CONFIG_SHELL) $(srctree)/scripts/hdrcheck.sh \ - $(INSTALL_HDR_PATH)/include $(subst /.check.,/,$@) $@ +quiet_cmd_check = CHECK $(words $(check-y)) files in $(_dst) + cmd_check = $(PERL) $(srctree)/scripts/checkhdr.pl \ + $(INSTALL_HDR_PATH)/include $(depsfile) $(check-y) quiet_cmd_remove = REMOVE $(_dst)/$@ cmd_remove = rm -f $(INSTALL_HDR_PATH)/$(_dst)/$@ @@ -137,17 +142,16 @@ echo \#endif /* $$STUBDEF */ ; \ .PHONY: __headersinst __headerscheck ifdef
Re: [PATCH] joydev.c automatic re-calibration
On 23/05/07, Andrew Morton [EMAIL PROTECTED] wrote: A few patch protocol things: - Please always prepare patches in `patch -p1' form - Include a Signed-off-by: as per Documentation/SubmittingPatches, section 11. - Avoid including two copies of the patch in the one email. Inlined plain text is preferred, ext/plain attachments are grudgingly accepted. I descrambled the patch, fixed a reject and queued it up in the -mm tree for Dmitry's consideration, thanks. Hi Andrew, sorry for the confusion, I'm following up with Dimitri and Jiri and hopefully will have a patch following the protocol next time. ;) cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm - 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] Define new percpu interface for shared data -- version 3
elements are cacheline aligned. And as such, this differentiates the local only data and remotely accessed data cleanly. OK, but could we please have a concise description of the impact of these changes on kernel memory footprint? Increase or decrease? And by approximately how much? Depending on how linker places percpu data, the patches could increase or decrease percpu section size. Data from 2.6.21-rc7-mm2: On x86 SMP, the section size is increased from 0x7768 to 0x790c. 1.3% increase. On X86-64 SMP, the size is decreased from 0x72d0 to 0x6540. 11.8% decrease. On X86-64 VSMP, the size is increased from 0x72d0 to 0x8340. 14.3% increase. On IA64 SMP, the size is decreased from 0x8370 to 0x7fc0. 2.8% decrease. - 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: Sched - graphic smoothness under load - cfs-v13 sd-0.48
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xavier Bestel wrote: On Wed, 2007-05-23 at 07:23 +0200, Michael Gerdau wrote: For me the huge difference you have for sd to the others increases the likelyhood the glxgears benchmark does not measure scheduling of graphic but something else. I think some people forget that X11 has its own scheduler for graphics operations. And in the direct-rendering case, this scheduler is not used for OpenGL. The client-side driver submits rendering commands directly to its kernel module. It is possible that some kernel modules perform some sort of scheduling, but none of the open-source drivers implement such a thing. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGVIZ7X1gOwKyEAw8RAottAJ9oQtnKVZ+xwrZXxyndanwkswp3IACeNY2v JJeDU3cgBtn1dBOr3erl3Ww= =YnG7 -END PGP SIGNATURE- - 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: Sched - graphic smoothness under load - cfs-v13 sd-0.48
Bill Davidsen wrote:
I was unable to reproduce the numbers Miguel generated, comments below.
The -ck2 patch seems to run nicely, although the memory repopulation
from swap would be most useful on system which have a lot of memory
pressure.
Bill Davidsen wrote:
Miguel Figueiredo wrote:
Hi Bill,
if i've understood correctly the script runs glxgears for 43 seconds
and in that time generates random numbers in a random number of times
(processes, fork and forget), is that it?
No, I haven't made it clear. A known number (default four) of xterms
are started, each of which calculates random numbers and prints them,
using much CPU time and causing a lot of scrolling. At the same time
glxgears is running, and the smoothness (or not) is observed manually.
The script records raw data on the number of frames per second and the
number of random numbers calculated by each shell. Since these are
FAIR schedulers, the variance between the scripts, and between
multiple samples from glxgears is of interest. To avoid startup
effects the glxgears value from the first sample is reported
separately and not included in the statistics.
I looked at your results, and they are disturbing to say the least, it
appears that using the ck2 scheduler glxgears stopped for all
practical purposes. You don't have quite the latest glitch1, the new
one runs longer and allows reruns to get several datasets, but the
results still show very slow gears and a large difference between the
work done by the four shells. That's not a good result, how did the
system feel?
You find the data, for 2.6.21-{cfs-v13, ck2} in
http://www.debianpt.org/~elmig/pool/kernel/20070522/
Thank you, these results are very surprising, and I would not expect
the system to be pleasing the use under load, based on this.
Here's the funny part...
Lets call:
a) to random number of processes run while glxgears is running,
gl_fairloops file
It's really the relative work done by identical processes, hopefully
they are all nearly the same, magnitude is interesting but related to
responsiveness rather than fairness.
b) to generated frames while running a burst of processes aka
massive and uknown amount of operations in one process, gl_gears file
Well, top or ps will give you a good idea of processing, but it tried
to use all of one CPU if allowed. Again, similarity of samples
reflects fairness and magnitude reflects work done.
kernel2.6.21-cfs-v132.6.21-ck2
a)194464254669 b)54159124
Everyone seems to like ck2, this makes it look as if the video display
would be really pretty unusable. While sd-0.48 does show an occasional
video glitch when watching video under heavy load, it's annoying
rather than unusable.
I spent a few hours running the -ck2 patch, and I didn't see any numbers
like yours. What I did see is going up with my previous results as
http://www.tmr.com/~davidsen/sched_smooth_04.html. While there were
still some minor pauses in glxgears with my test, performance was very
similar to the sd-0.48 results. And I did try watching video with high
load, without problems. Only when I run a lot of other screen-changing
processes can I see pauses in the display.
Your subjective impressions would be helpful, and you may find that
the package in the www.tmr.com/~public/source is slightly easier to
use and gives more stable results. The documentation suggests the way
to take samples (the way I did it) but if you feel more or longer
samples would help it is tunable.
I added Con to the cc list, he may have comments or suggestions
(against the current versions, please). Or he may feel that video
combined with other heavy screen updating is unrealistic or not his
chosen load. I'm told the load is similar to games which use threads
and do lots of independent action, if that's a reference.
I'll include the -ck2 patch in my testing on other hardware.
Hi Bill,
the numbers i posted before are repeatable on that machine.
I did run, again, glitch1 on my laptop (T2500 CoreDuo, also Nvidia)
please check: http://www.debianpt.org/~elmig/pool/kernel/20070523/
--
Com os melhores cumprimentos/Best regards,
Miguel Figueiredo
http://www.DebianPT.org
-
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 5/7] genhd: send async notification on media change
On Wed, 23 May 2007 12:03:55 -0500
James Bottomley [EMAIL PROTECTED] wrote:
On Wed, 2007-05-23 at 09:31 -0700, Kristen Carlson Accardi wrote:
On Tue, 22 May 2007 14:12:11 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 9 May 2007 16:38:35 -0700
Kristen Carlson Accardi [EMAIL PROTECTED] wrote:
Send an uevent to user space to indicate that a media change event has
occurred.
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
Index: 2.6-git/block/genhd.c
===
--- 2.6-git.orig/block/genhd.c
+++ 2.6-git/block/genhd.c
@@ -643,6 +643,27 @@ struct seq_operations diskstats_op = {
.show = diskstats_show
};
+static void media_change_notify_thread(struct work_struct *work)
+{
+ struct gendisk *gd = container_of(work, struct gendisk,
async_notify);
+ char event[] = MEDIA_CHANGE=1;
+ char *envp[] = { event, NULL };
+
+ /*
+* set enviroment vars to indicate which event this is for
+* so that user space will know to go check the media status.
+*/
+ kobject_uevent_env(gd-kobj, KOBJ_CHANGE, envp);
+ put_device(gd-driverfs_dev);
+}
+
+void genhd_media_change_notify(struct gendisk *disk)
+{
+ get_device(disk-driverfs_dev);
+ schedule_work(disk-async_notify);
+}
+EXPORT_SYMBOL_GPL(genhd_media_change_notify);
+
struct gendisk *alloc_disk(int minors)
{
return alloc_disk_node(minors, -1);
@@ -672,6 +693,8 @@ struct gendisk *alloc_disk_node(int mino
kobj_set_kset_s(disk,block_subsys);
kobject_init(disk-kobj);
rand_initialize_disk(disk);
+ INIT_WORK(disk-async_notify,
+ media_change_notify_thread);
}
return disk;
Why does this do a schedule_work() rather than calling
kobject_uevent_env()
directly?
Because it is called at Interrupt time.
It better not be ... there's two GFP_KERNEL allocations just above this
line in the file.
James
Where? We are talking about the call to genhd_media_change_notify().
the calling path is this:
ahci_host_intr()-ata_scsi_media_change_notify()-genhd_media_change_notify().
I don't see the allocations - are they hidden somewhere?
thanks,
Kristen
-
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] [PATCH 0/3] Add group fairness to CFS
* Srivatsa Vaddagiri [EMAIL PROTECTED] wrote: Here's an attempt to extend CFS (v13) to be fair at a group level, rather than just at task level. The patch is in a very premature state (passes simple tests, smp load balance not supported yet) at this point. I am sending it out early to know if this is a good direction to proceed. cool patch! :-) Salient points which needs discussion: 1. This patch reuses CFS core to achieve fairness at group level also. To make this possible, CFS core has been abstracted to deal with generic schedulable entities (tasks, users etc). yeah, i like this alot. The struct sched_entity abstraction looks very clean, and that's the main thing that matters: it allows for a design that will only cost us performance if group scheduling is desired. If you could do a -v14 port and at least add minimal SMP support: i.e. it shouldnt crash on SMP, but otherwise no extra load-balancing logic is needed for the first cut - then i could try to pick all these core changes up for -v15. (I'll let you know about any other thoughts/details when i do the integration.) 2. The per-cpu rb-tree has been split to be per-group per-cpu. schedule() now becomes two step on every cpu : pick a group first (from group rb-tree) and a task within that group next (from that group's task rb-tree) yeah. It might even become more steps if someone wants to have a different, deeper hierarchy (at the price of performance). Containers will for example certainly want to use one more level. 3. Grouping mechanism - I have used 'uid' as the basis of grouping for timebeing (since that grouping concept is already in mainline today). The patch can be adapted to a more generic process grouping mechanism (like http://lkml.org/lkml/2007/4/27/146) later. yeah, agreed. Some results below, obtained on a 4way (with HT) Intel Xeon box. All number are reflective of single CPU performance (tests were forced to run on single cpu since load balance is not yet supported). uid vatsa uid guest (make -s -j4 bzImage)(make -s -j20 bzImage) 2.6.22-rc1 772.02 sec497.42 sec (real) 2.6.22-rc1+cfs-v13 780.62 sec478.35 sec (real) 2.6.22-rc1+cfs-v13+this patch 776.36 sec 776.68 sec (real) [ An exclusive cpuset containing only one CPU was created and the compilation jobs of both users were run simultaneously in this cpuset ] looks really promising! I also disabled CONFIG_FAIR_USER_SCHED and compared the results with cfs-v13: uid vatsa make -s -j4 bzImage 2.6.22-rc1+cfs-v13395.57 sec (real) 2.6.22-rc1+cfs-v13+this_patch 388.54 sec (real) There is no regression I can see (rather some improvement, which I can't understand atm). I will run more tests later to check this regression aspect. kernel builds dont really push scheduling micro-costs, rather try something like 'hackbench.c' to measure that. (kernel builds are of course one of our primary benchmarks.) Request your comments on the future direction to proceed! full steam ahead please! =B-) Ingo - 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: [BUG] local_softirq_pending storm
Chuck Ebbert wrote:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240982
Another; these started to appear after the below patch was merged:
Index: linux/kernel/sched.c
===
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -4212,9 +4212,7 @@ int __sched cond_resched_softirq(void)
BUG_ON(!in_softirq());
if (need_resched() system_state == SYSTEM_RUNNING) {
- raw_local_irq_disable();
- _local_bh_enable();
- raw_local_irq_enable();
+ local_bh_enable();
__cond_resched();
local_bh_disable();
return 1;
May 23 19:26:26 localhost kernel: BUG: warning at
kernel/softirq.c:138/local_bh_enable() (Not tainted)
May 23 19:26:26 localhost kernel: [c042b2ef] local_bh_enable+0x45/0x92
May 23 19:26:26 localhost kernel: [c06036b7] cond_resched_softirq+0x2c/0x42
May 23 19:26:26 localhost kernel: [c059d5d0] release_sock+0x54/0xa3
May 23 19:26:26 localhost kernel: [c04373af] prepare_to_wait+0x24/0x3f
May 23 19:26:26 localhost kernel: [c05e267f] inet_stream_connect+0x116/0x1ff
May 23 19:26:26 localhost kernel: [c0437265]
autoremove_wake_function+0x0/0x35
May 23 19:26:26 localhost kernel: [c059c339] sys_connect+0x82/0xad
May 23 19:26:26 localhost kernel: [c059d58f] release_sock+0x13/0xa3
May 23 19:26:26 localhost kernel: [c0604ad5] _spin_unlock_bh+0x5/0xd
May 23 19:26:26 localhost kernel: [c059e714] sock_setsockopt+0x4a8/0x4b2
May 23 19:26:26 localhost kernel: [c059b6b6] sock_attach_fd+0x70/0xd2
May 23 19:26:26 localhost kernel: [c04774a0] get_empty_filp+0xfc/0x170
May 23 19:26:26 localhost kernel: [c059b54f] sys_setsockopt+0x9b/0xa7
May 23 19:26:26 localhost kernel: [c059cb83] sys_socketcall+0xac/0x261
May 23 19:26:26 localhost kernel: [c0404f70] syscall_call+0x7/0xb
-
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.22-rc2-mm1
On Wed, 23 May 2007, Oleg Nesterov wrote:
On 05/23, Alan Stern wrote:
Okay, it's clear that the two threads are in deadlock. It's not clear
how the deadlock arose to begin with -- apparently there was a remote
wakeup request for a root hub at the same time as a device below that
root hub was disconnected, which doesn't make much sense.
Please note that this flush_workqueue() was not safe anyway. We are freezing
tasks, and ksuspend_usb_wq is freezeable. So, it could be frozen before
khubd task, and we have another deadlock.
Correct. I was planning to replace the flush_workqueue() anyway for
that very reason; this is a good excuse to do it.
Anyway, this looks like a good place to use cancel_work_sync(). The
Could you use cancel_rearming_delayed_work() ? (It should be renamed to
cancel_delayed_work_sync()).
Good idea. Here's a revised patch.
Alan Stern
Index: usb-2.6/drivers/usb/core/hub.c
===
--- usb-2.6.orig/drivers/usb/core/hub.c
+++ usb-2.6/drivers/usb/core/hub.c
@@ -1228,6 +1228,30 @@ static void release_address(struct usb_d
}
}
+#ifdef CONFIG_USB_SUSPEND
+
+static void usb_stop_pm(struct usb_device *udev)
+{
+ /* Synchronize with the ksuspend thread to prevent any more
+* autosuspend requests from being submitted, and decrement
+* the parent's count of unsuspended children.
+*/
+ usb_pm_lock(udev);
+ if (udev-parent !udev-discon_suspended)
+ usb_autosuspend_device(udev-parent);
+ usb_pm_unlock(udev);
+
+ /* Stop any autosuspend requests already submitted */
+ cancel_rearming_delayed_work(udev-autosuspend);
+}
+
+#else
+
+static inline void usb_stop_pm(struct usb_device *udev)
+{ }
+
+#endif
+
/**
* usb_disconnect - disconnect a device (usbcore-internal)
* @pdev: pointer to device being disconnected
@@ -1294,14 +1318,7 @@ void usb_disconnect(struct usb_device **
*pdev = NULL;
spin_unlock_irq(device_state_lock);
- /* Synchronize with the ksuspend thread to prevent any more
-* autosuspend requests from being submitted, and decrement
-* the parent's count of unsuspended children.
-*/
- usb_pm_lock(udev);
- if (udev-parent !udev-discon_suspended)
- usb_autosuspend_device(udev-parent);
- usb_pm_unlock(udev);
+ usb_stop_pm(udev);
put_device(udev-dev);
}
Index: usb-2.6/drivers/usb/core/usb.c
===
--- usb-2.6.orig/drivers/usb/core/usb.c
+++ usb-2.6/drivers/usb/core/usb.c
@@ -184,10 +184,6 @@ static void usb_release_dev(struct devic
udev = to_usb_device(dev);
-#ifdef CONFIG_USB_SUSPEND
- cancel_delayed_work(udev-autosuspend);
- flush_workqueue(ksuspend_usb_wq);
-#endif
usb_destroy_configuration(udev);
usb_put_hcd(bus_to_hcd(udev-bus));
kfree(udev-product);
Index: usb-2.6/drivers/usb/core/hcd.c
===
--- usb-2.6.orig/drivers/usb/core/hcd.c
+++ usb-2.6/drivers/usb/core/hcd.c
@@ -1683,7 +1683,7 @@ void usb_remove_hcd(struct usb_hcd *hcd)
spin_unlock_irq (hcd_root_hub_lock);
#ifdef CONFIG_PM
- flush_workqueue(ksuspend_usb_wq);
+ cancel_work_sync(hcd-wakeup_work);
#endif
mutex_lock(usb_bus_list_lock);
-
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: Sched - graphic smoothness under load - cfs-v13 sd-0.48
Le mercredi 23 mai 2007 à 11:22 -0700, Ian Romanick a écrit : I think some people forget that X11 has its own scheduler for graphics operations. And in the direct-rendering case, this scheduler is not used for OpenGL. The client-side driver submits rendering commands directly to its kernel module. It is possible that some kernel modules perform some sort of scheduling, but none of the open-source drivers implement such a thing. True, but glxgears isn't a pure DRI app: it calls XNextEvent() each time it refreshes its window (which is quite often). Xav - 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] headercheck: add dependency check and improve speed
Modified Makfile.headerinst so all files in a dir is checked with one call to checkhdr.pl script. The file check is used as marker when last run was executed. And the file .check.cmd contains a list of dependencies used by make to determine if a new check should be executed. The perl script was named check* to follow same naming as other check scripts. The speedup is 10 seconds for a build with headercheck enabled. Signed-off-by: Sam Ravnborg [EMAIL PROTECTED] --- This version works on powerpc. The assignment of checkfile had to move below the point where we check for biarch. Sam lib/Kconfig.debug|1 + scripts/Makefile.headersinst | 55 +++-- scripts/checkhdr.pl | 53 scripts/hdrcheck.sh | 10 --- 4 files changed, 85 insertions(+), 34 deletions(-) create mode 100644 scripts/checkhdr.pl delete mode 100755 scripts/hdrcheck.sh diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index fbc5c62..596f973 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -70,6 +70,7 @@ config HEADERS_CHECK relevant for userspace, say 'Y', and check the headers exported to $(INSTALL_HDR_PATH) (usually 'usr/include' in your build tree), to make sure they're suitable. + Note: Enabling this check requires perl to be installed config DEBUG_KERNEL bool Kernel debugging diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst index 8cd6301..6d74b54 100644 --- a/scripts/Makefile.headersinst +++ b/scripts/Makefile.headersinst @@ -28,7 +28,7 @@ ifeq (,$(patsubst include/asm/%,,$(obj)/)) # both sets of Kbuild files; we'll generate anything which is mentioned in # _either_ arch, and recurse into subdirectories which are mentioned in either # arch. Since some directories may exist in one but not the other, we must -# use $(wildcard...). +# use $(wildcard...). GENASM := 1 archasm := $(subst include/asm,asm-$(ARCH),$(obj)) altarchasm := $(subst include/asm,asm-$(ALTARCH),$(obj)) @@ -39,7 +39,7 @@ endif include $(KBUILDFILES) -include scripts/Kbuild.include +include scripts/Kbuild.include # If this is include/asm-$(ARCH) and there's no $(ALTARCH), then # override $(_dst) so that we install to include/asm directly. @@ -50,28 +50,29 @@ ifeq ($(obj)$(ALTARCH),include/asm-$(ARCH)$(BIASMDIR)) _dst := include/asm endif +# file generated during checktime listing depfiles and incfiles +depsfile := $(INSTALL_HDR_PATH)/$(_dst)/.check.cmd +checkfile := $(INSTALL_HDR_PATH)/$(_dst)/check + + header-y := $(sort $(header-y)) unifdef-y := $(sort $(unifdef-y)) subdir-y := $(patsubst %/,%,$(filter %/, $(header-y))) header-y := $(filter-out %/, $(header-y)) header-y := $(filter-out $(unifdef-y),$(header-y)) -# stamp files for header checks -check-y:= $(patsubst %,.check.%,$(header-y) $(unifdef-y) $(objhdr-y)) +# All files to check for this dir +check-y:= $(header-y) $(unifdef-y) $(objhdr-y) # Work out what needs to be removed oldheaders := $(patsubst $(INSTALL_HDR_PATH)/$(_dst)/%,%,$(wildcard $(INSTALL_HDR_PATH)/$(_dst)/*.h)) -unwanted := $(filter-out $(header-y) $(unifdef-y) $(objhdr-y),$(oldheaders)) - -oldcheckstamps := $(patsubst $(INSTALL_HDR_PATH)/$(_dst)/%,%,$(wildcard $(INSTALL_HDR_PATH)/$(_dst)/.check.*.h)) -unwanted += $(filter-out $(check-y),$(oldcheckstamps)) +unwanted := $(filter-out $(check-y),$(oldheaders)) # Prefix them all with full paths to $(INSTALL_HDR_PATH) -header-y := $(patsubst %,$(INSTALL_HDR_PATH)/$(_dst)/%,$(header-y)) -unifdef-y := $(patsubst %,$(INSTALL_HDR_PATH)/$(_dst)/%,$(unifdef-y)) -objhdr-y := $(patsubst %,$(INSTALL_HDR_PATH)/$(_dst)/%,$(objhdr-y)) -check-y:= $(patsubst %,$(INSTALL_HDR_PATH)/$(_dst)/%,$(check-y)) - +header-y := $(patsubst %,$(INSTALL_HDR_PATH)/$(_dst)/%,$(header-y)) +unifdef-y := $(patsubst %,$(INSTALL_HDR_PATH)/$(_dst)/%,$(unifdef-y)) +objhdr-y := $(patsubst %,$(INSTALL_HDR_PATH)/$(_dst)/%,$(objhdr-y)) +check-y:= $(patsubst %,$(INSTALL_HDR_PATH)/$(_dst)/%,$(check-y)) ifdef ALTARCH ifeq ($(obj),include/asm-$(ARCH)) @@ -96,9 +97,9 @@ quiet_cmd_unifdef = UNIFDEF $(patsubst $(INSTALL_HDR_PATH)/%,%,$@) cmd_unifdef= $(UNIFDEF) $(patsubst $(INSTALL_HDR_PATH)/$(_dst)/%,$(srctree)/$(obj)/%,$@) \ | $(HDRSED) $@ || : -quiet_cmd_check = CHECK $(patsubst $(INSTALL_HDR_PATH)/$(_dst)/.check.%,$(_dst)/%,$@) - cmd_check = $(CONFIG_SHELL) $(srctree)/scripts/hdrcheck.sh \ - $(INSTALL_HDR_PATH)/include $(subst /.check.,/,$@) $@ +quiet_cmd_check = CHECK $(words $(check-y)) files in $(_dst) + cmd_check = $(PERL) $(srctree)/scripts/checkhdr.pl \ +
Re: [PATCH] CDROM: replace jiffies busyloop with msleep
On 05/22/2007 12:25 PM, Thomas Gleixner wrote: From: Ingo Molnar [EMAIL PROTECTED] The SJCD driver uses a jiffies busy loop. Replace it with msleep. Signed-off-by: Ingo Molnar [EMAIL PROTECTED] Acked-by: Thomas Gleixner [EMAIL PROTECTED] Okay, that's just waiting for a reset to complete, which seems perfectly fine with a sleeping loop like that, but... I re-started working on a rewrite of the mitsumi legacy cdrom driver that Pekka Enberg and I have been doing this afternoon again and I ran into not being able to use sleeping loops there an hour ago! The trouble there is that unless you poll the bloody thing like mad too much of the Q subchannels passes below you and you need a huge number of retries to get anything out of it. I noticed when I started adding audio bits that the driver took full seconds to complete some audio requests while the old driver was snappy in that regard. When I replaced our sleeping loop with a busy-wait same as the original the snappyness returned and moreover, reading the TOC from the CD went from something close to a minute to approximately a second. Thought that minute was just because I was dealing with an old junk 1-speed drive... Now, as said, this looks to be fine since it's just waiting for a reset to complete, but unless you have the hardware to actually test, be careful in there. Or in fact, maybe even decide there's not much point. The current plan is to do mitsumi, sony and panasonic and then throw the rest away (that trio is special in so far that controllers for them are still available on a lot of old ISA soundcards). Or do you actually have the hardware? Rene. - 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: signals logged / [RFC] log out-of-virtual-memory events
+{
if (sig_fatal(t, sig)) {
+printk(KERN_WARNING Sig %d send to %d owned by %d.%d
(%s)\n,
s/send/sent/;
+sig, t - pid, t - uid, t - gid, t - comm);
t-pid, t-uid, t-gid, t-comm);
Gargh ... why does this want to be in the *kernel*'s logs? In any case, can
you please make this KERN_INFO (or lower) instead of KERN_WARNING.
Description:
This patch adds code to the signal-sender making it log a message when
an unhandled fatal signal will be delivered.
Signed-of by: Folkert van Heusden [EMAIL PROTECTED]
--- kernel/signal.c.org 2007-05-20 22:47:13.0 +0200
+++ kernel/signal.c 2007-05-21 14:46:05.0 +0200
@@ -739,6 +739,12 @@
struct sigqueue * q = NULL;
int ret = 0;
+ /* unhandled fatal signals are logged */
+ if (sig_fatal(t, sig)) {
+ printk(KERN_INFO Sig %d sent to %d owned by %d.%d (%s)\n,
+ sig, t-pid, t-uid, t-gid, t-comm);
+ }
+
/*
* fast-pathed signals for kernel-internal things like SIGSTOP
* or SIGKILL.
Folkert van Heusden
--
Temperature outside:21.437500, temperature livingroom:
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
-
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: libata and legacy ide pcmcia failure
Alan Cox wrote: http://thread.gmane.org/gmane.linux.kernel/530099 It seems we're losing interrupts from the CFA device. Any ideas? Alan probably knows more, but ISTR some CFA PCMCIA devices that needed polling... Not that I know of. Not devices anyway - there are embedded boxes with no IRQ configuration for the CF slot but we've never supported those (indeed there are even people who bitbang ATA on GPIO pins...) So my understanding is, that although some issues with the libata pcmcia code where found, the latest issue is a pure pcmcia issue? Anything I can supply or test to further narrow down the problem? I have already posted lspci -vxxx and full dmesg log to the linux-kernel list, but here are some select pieces of it Yenta: CardBus bridge found at :02:00.0 [1014:0552] Yenta: Using INTVAL to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket :02:00.0, mfunc 0x01d21b22, devctl 0x64 Yenta: ISA IRQ mask 0x04b8, PCI irq 11 Socket status: 3086 pcmcia: parent PCI bridge I/O window: 0x4000 - 0x8fff cs: IO port probe 0x4000-0x8fff: clean. pcmcia: parent PCI bridge Memory window: 0xc020 - 0xcfff pcmcia: parent PCI bridge Memory window: 0xe800 - 0xefff PM: Adding info for No Bus:pcmcia_socket0 Yenta: CardBus bridge found at :02:00.1 [1014:0552] Yenta: Using INTVAL to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket :02:00.1, mfunc 0x01d21b22, devctl 0x64 Yenta: ISA IRQ mask 0x04b8, PCI irq 11 Socket status: 3086 pcmcia: parent PCI bridge I/O window: 0x4000 - 0x8fff cs: IO port probe 0x4000-0x8fff: clean. pcmcia: parent PCI bridge Memory window: 0xc020 - 0xcfff pcmcia: parent PCI bridge Memory window: 0xe800 - 0xefff PM: Adding info for No Bus:pcmcia_socket1 cs: IO port probe 0x100-0x3af: clean. cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7 cs: IO port probe 0x820-0x8ff: clean. cs: IO port probe 0xc00-0xcf7 clean. cs: IO port probe 0xa00-0xaff: clean. cs: IO port probe 0x100-0x3af: clean. cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7 cs: IO port probe 0x820-0x8ff: clean. cs: IO port probe 0xc00-0xcf7: clean. cs: IO port probe 0xa00-0xaff: clean. 02:00.0 CardBus bridge: Texas Instruments PCI4520 PC card Cardbus Controller (rev 01) Subsystem: IBM Unknown device 0552 Flags: bus master, medium devsel, latency 168, IRQ 11 Memory at b000 (32-bit, non-prefetchable) [size=4K] Bus: primary=02, secondary=03, subordinate=06, sec-latency=176 Memory window 0: e800-ebfff000 (prefetchable) Memory window 1: c400-c7fff000 I/O window 0: 4000-40ff I/O window 1: 4400-44ff 16-bit legacy interface ports at 0001 00: 4c 10 46 ac 07 00 10 02 01 00 07 06 20 a8 82 00 10: 00 00 00 b0 a0 00 00 02 02 03 06 b0 00 00 00 e8 20: 00 f0 ff eb 00 00 00 c4 00 f0 ff c7 00 40 00 00 30: fc 40 00 00 00 44 00 00 fc 44 00 00 0b 01 c0 05 40: 14 10 52 05 01 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 71 d0 40 08 00 00 0a 04 00 00 0f 00 22 1b d2 01 90: c0 02 64 41 00 00 00 00 00 00 00 00 00 00 00 00 a0: 01 00 12 fe 00 00 c0 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02:00.1 CardBus bridge: Texas Instruments PCI4520 PC card Cardbus Controller (rev 01) Subsystem: IBM Unknown device 0552 Flags: bus master, medium devsel, latency 168, IRQ 11 Memory at b100 (32-bit, non-prefetchable) [size=4K] Bus: primary=02, secondary=07, subordinate=07, sec-latency=176 Memory window 0: ec00-e000 (prefetchable) Memory window 1: c800-cbfff000 I/O window 0: 4800-48ff I/O window 1: 4c00-4cff 16-bit legacy interface ports at 0001 00: 4c 10 46 ac 07 00 10 02 01 00 07 06 20 a8 82 00 10: 00 00 00 b1 a0 00 00 02 02 07 07 b0 00 00 00 ec 20: 00 f0 ff ef 00 00 00 c8 00 f0 ff cb 00 48 00 00 30: fc 48 00 00 00 4c 00 00 fc 4c 00 00 0b 02 c0 05 40: 14 10 52 05 01 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 71 d0 40 08 00 00 0a 04 00 00 0f 00 22 1b d2 01 90: c0 02 64 41 00 00 00 00 00 00 00 00 00 00 00 00 a0: 01 00 12 fe 00 00 c0 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00
Re: [PATCH] ARM/ARM26 Cleanup, using ARRAY_SIZE
On 5/23/07, Russell King [EMAIL PROTECTED] wrote: On Wed, May 23, 2007 at 01:27:11PM -0400, Gerb Stralko wrote: Use the kernel wide ARRAY_SIZE when determining the array size of a struct. Signed-off-by: Jerry Stralko [EMAIL PROTECTED] Whitespace damanged patch, probably due to using format=flowed in your mailer. Please get a proper mail client. 8) Sorry about that one. I didn't realize my mailer was being stupid. I'll see if I can fix _or_ get a new mailer, and maybe send out a better patch :) Also, please note that ARM and ARM26 are two separate architectures maintained by two separate people. Please don't confuse them and merge patches - it's about the same level of evilness as labelling PPC and i386 as one architecture and expecting PPC folk to take the lot. Ok, sorry about that, I don't want to cause you any more confusion or frustration. I'm a newbie in this area and just wanted to help out and learn. Thanks for being polite about it...instead of chewing my head off - your a good man. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - 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 5/7] genhd: send async notification on media change
On Wed, 2007-05-23 at 11:26 -0700, Kristen Carlson Accardi wrote:
On Wed, 23 May 2007 12:03:55 -0500
James Bottomley [EMAIL PROTECTED] wrote:
On Wed, 2007-05-23 at 09:31 -0700, Kristen Carlson Accardi wrote:
On Tue, 22 May 2007 14:12:11 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 9 May 2007 16:38:35 -0700
Kristen Carlson Accardi [EMAIL PROTECTED] wrote:
Send an uevent to user space to indicate that a media change event
has occurred.
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
Index: 2.6-git/block/genhd.c
===
--- 2.6-git.orig/block/genhd.c
+++ 2.6-git/block/genhd.c
@@ -643,6 +643,27 @@ struct seq_operations diskstats_op = {
.show = diskstats_show
};
+static void media_change_notify_thread(struct work_struct *work)
+{
+ struct gendisk *gd = container_of(work, struct gendisk,
async_notify);
+ char event[] = MEDIA_CHANGE=1;
+ char *envp[] = { event, NULL };
+
+ /*
+ * set enviroment vars to indicate which event this is for
+ * so that user space will know to go check the media status.
+ */
+ kobject_uevent_env(gd-kobj, KOBJ_CHANGE, envp);
+ put_device(gd-driverfs_dev);
+}
+
+void genhd_media_change_notify(struct gendisk *disk)
+{
+ get_device(disk-driverfs_dev);
+ schedule_work(disk-async_notify);
+}
+EXPORT_SYMBOL_GPL(genhd_media_change_notify);
+
struct gendisk *alloc_disk(int minors)
{
return alloc_disk_node(minors, -1);
@@ -672,6 +693,8 @@ struct gendisk *alloc_disk_node(int mino
kobj_set_kset_s(disk,block_subsys);
kobject_init(disk-kobj);
rand_initialize_disk(disk);
+ INIT_WORK(disk-async_notify,
+ media_change_notify_thread);
}
return disk;
Why does this do a schedule_work() rather than calling
kobject_uevent_env()
directly?
Because it is called at Interrupt time.
It better not be ... there's two GFP_KERNEL allocations just above this
line in the file.
James
Where? We are talking about the call to genhd_media_change_notify().
the calling path is this:
ahci_host_intr()-ata_scsi_media_change_notify()-genhd_media_change_notify().
I don't see the allocations - are they hidden somewhere?
Sorry, I thought you were saying alloc_disk_node() could be called from
interrupt context.
gets back on ball
If you just want to invoke guaranteed user context from a place in the
code which *may* be called from interrupt, then
execute_in_process_context() might be a better way of doing it ... at
least it avoids setting up a workqueue where none is needed.
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: [RFC PATCH] PCI MMCONFIG: add validation against ACPI motherboard resources
On Tuesday, May 22, 2007 6:06 pm Robert Hancock wrote:
There was a big discussion about this back in 2002, in which Linus
wasn't overly enthused about disabling the decode during probing due
to risk of causing problems with some devices:
http://lkml.org/lkml/2002/12/19/145
In this particular case (64-bit BAR) we might be able to avoid the
problem by changing the order in which we probe the two halves of the
address, i.e. change the top half to 0x before messing with
the bottom half and then change it back last. That way, we end up
mapping it way to the top of 64-bit address space, which hopefully is
less likely to conflict..
Fixed it (finally). I don't think moving the 64 bit probing around
would make a difference, since we'd restore its original value anyway
before moving on to the 32 bit probe which is where I think the problem
is.
I think what's happening is the probe is writing 0x to the video
device, which is in the GMCH, and without memory decoding disabled,
it'll start claiming PCI config access cycles causing the problems I
saw. So my code to disable I/O and memory decode was actually working
but I had a bug in the re-enable path so all my devices were staying
disabled. :)
So here's the patch I used (along with your ACPI patch and my 965 MCFG
enable patch of course). The probing code could probably use a bit
more cleanup, but this patch limits itself to implementing PCI_COMMAND
based I/O and memory space decode disabling during size probing. We
might want to do this unconditionally if we're using mmconfig based
configuration access, since I imagine other machines might end up
having similar address space layouts that would cause problems.
Linus, since you were the one concerned about breaking working setups,
what do you think? Should we use this approach, or specifically quirk
out cases where mmconfig space might conflict with BAR probing?
Thanks,
Jesse
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index e48fcf0..69dfe0c 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -170,6 +170,48 @@ static inline int is_64bit_memory(u32 mask)
return 0;
}
+#define BAR_IS_MEMORY(bar) (((bar) PCI_BASE_ADDRESS_SPACE) ==\
+ PCI_BASE_ADDRESS_SPACE_MEMORY)
+
+/**
+ * pci_bar_size - get raw PCI BAR size
+ * @dev: PCI device
+ * @reg: BAR to probe
+ *
+ * Use basic PCI probing:
+ * - save original BAR value
+ * - disable MEM or IO decode as appropriate in PCI_COMMAND reg
+ * - write all 1s to the BAR
+ * - read back value
+ * - reenble MEM or IO decode as necessary
+ * - write original value back
+ *
+ * Returns raw BAR size to caller.
+ */
+static u32 pci_bar_size(struct pci_dev *dev, unsigned int reg)
+{
+ u32 orig_reg, sz;
+ u16 orig_cmd;
+
+ pci_read_config_dword(dev, reg, orig_reg);
+ pci_read_config_word(dev, PCI_COMMAND, orig_cmd);
+
+ if (BAR_IS_MEMORY(orig_reg))
+ pci_write_config_word(dev, PCI_COMMAND,
+ orig_cmd ~PCI_COMMAND_MEMORY);
+ else
+ pci_write_config_word(dev, PCI_COMMAND,
+ orig_cmd ~PCI_COMMAND_IO);
+
+ pci_write_config_dword(dev, reg, 0x);
+ pci_read_config_dword(dev, reg, sz);
+ pci_write_config_dword(dev, reg, orig_reg);
+
+ pci_write_config_word(dev, PCI_COMMAND, orig_cmd);
+
+ return sz;
+}
+
static void pci_read_bases(struct pci_dev *dev, unsigned int howmany,
int rom)
{
unsigned int pos, reg, next;
@@ -185,17 +227,15 @@ static void pci_read_bases(struct pci_dev *dev,
unsigned int howmany, int rom)
res = dev-resource[pos];
res-name = pci_name(dev);
reg = PCI_BASE_ADDRESS_0 + (pos 2);
+
pci_read_config_dword(dev, reg, l);
- pci_write_config_dword(dev, reg, ~0);
- pci_read_config_dword(dev, reg, sz);
- pci_write_config_dword(dev, reg, l);
+ sz = pci_bar_size(dev, reg);
if (!sz || sz == 0x)
continue;
if (l == 0x)
l = 0;
raw_sz = sz;
- if ((l PCI_BASE_ADDRESS_SPACE) ==
- PCI_BASE_ADDRESS_SPACE_MEMORY) {
+ if (BAR_IS_MEMORY(l)) {
sz = pci_size(l, sz, (u32)PCI_BASE_ADDRESS_MEM_MASK);
/*
* For 64bit prefetchable memory sz could be 0, if the
@@ -219,9 +259,7 @@ static void pci_read_bases(struct pci_dev *dev,
unsigned int howmany, int rom)
u32 szhi, lhi;
pci_read_config_dword(dev, reg+4, lhi);
- pci_write_config_dword(dev, reg+4, ~0);
- pci_read_config_dword(dev, reg+4, szhi);
- pci_write_config_dword(dev,
Re: [PATCH 1/2] Define new percpu interface for shared data -- version 3
On Wed, May 23, 2007 at 11:26:53AM -0700, Yu, Fenghua wrote: elements are cacheline aligned. And as such, this differentiates the local only data and remotely accessed data cleanly. OK, but could we please have a concise description of the impact of these changes on kernel memory footprint? Increase or decrease? And by approximately how much? Depending on how linker places percpu data, the patches could increase or decrease percpu section size. Data from 2.6.21-rc7-mm2: On x86 SMP, the section size is increased from 0x7768 to 0x790c. 1.3% increase. On X86-64 SMP, the size is decreased from 0x72d0 to 0x6540. 11.8% decrease. On X86-64 VSMP, the size is increased from 0x72d0 to 0x8340. 14.3% increase. On IA64 SMP, the size is decreased from 0x8370 to 0x7fc0. 2.8% decrease. Has there been any measurable benefit yet due to tail padding? It would also be interesting to check the wastage/savings on another large cache architecture like S390 (which has a 256 byte cache line) Thanks, Kiran - 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] headercheck: add dependency check and improve speed
$ make headers_check $ sed -i /auxvec.h/d include/asm/Kbuild $ make headers_check $ sed -i /auxvec.h/d include/asm-generic/Kbuild.asm $ make headers_check Why doesn't it recheck linux/auxvec.h and fail? -- dwmw2 - 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/
