kobject_add unreachable code
The following code in kobject_add
if (!kobj->k_name)
kobj->k_name = kobj->name;
if (!kobj->k_name) {
pr_debug("kobject attempted to be registered with no name!\n");
WARN_ON(1);
return -EINVAL;
}
doesn't look right to me. The second 'if' statement looks useless after
the assignment in the first one. May be it was meant to be like:
if (!*kobj->k_name)
See the full patch:
--- linux-2.6.20-rc2/lib/kobject.c 2006-12-28 19:59:56.0 -0800
+++ linux-2.6.20-rc2.mod/lib/kobject.c 2006-12-28 20:00:25.0 -0800
@@ -161,19 +161,19 @@
int kobject_add(struct kobject * kobj)
{
int error = 0;
struct kobject * parent;
if (!(kobj = kobject_get(kobj)))
return -ENOENT;
if (!kobj->k_name)
kobj->k_name = kobj->name;
- if (!kobj->k_name) {
+ if (!*kobj->k_name) {
pr_debug("kobject attempted to be registered with no
name!\n");
WARN_ON(1);
return -EINVAL;
}
parent = kobject_get(kobj->parent);
-Martin
-
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: No sound in KDE with intel hda since 2.6.20-rc1
> Since 2.6.20-rc1 (tested both -rc1 and rc2), system notification sounds under > KDE, and sound in games (e.g. TuxPaint) no longer seem to work on my T60 > thinkpad. Works fine under 2.6.19 though. The strange thing is e.g. Amarok > still plays music fine. Tis is on Kubuntu 6.06, BTW. -- MST - 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: Want comments regarding patch
Hello! Thank you for your comments. It seems to me the issue was the readability. It was my goal to improve the readability. I failed. I personally prefer to use standard functions instead of writing code. In my opinion using standard functions means less code that is easier to read. Best regards, 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/
Re: [PATCH] mm: fix page_mkclean_one
On Fri, 29 Dec 2006, Segher Boessenkool wrote:
>
> > I think what might be happening is that pdflush writes them out fine,
> > however we don't trap writes by the application _during_ that writeout.
>
> Yeah. I believe that more exactly it happens if the very last
> write to the page causes a writeback (due to dirty balancing)
> while another writeback for the page is already happening.
>
> As usual in these cases, I have zero proof.
I actually have proof to the contrary, ie I have traces that say "the
write was started" after the last write.
And the VM layer in this area is actually fairly sane and civilized. It
has a bit that says "writeback in progress", and if that bit is set, it
simply _will_not_ start a new write. It even has various BUG_ON()'s to
that effect.
So everything I have ever seen says that the VM layer is actually doing
everything right.
> It's the do_wp_page -> balance_dirty_pages -> generic_writepages
> path for sure. Maybe it's enough to change
>
> if (wbc->sync_mode != WB_SYNC_NONE)
> wait_on_page_writeback(page);
>
> if (PageWriteback(page) ||
> !clear_page_dirty_for_io(page)) {
> unlock_page(page);
> continue;
> }
Notive how this one basically says:
- if it's under writeback, don't even clear the page dirty flag.
Your suggested change:
> if (wbc->sync_mode != WB_SYNC_NONE)
> wait_on_page_writeback(page);
>
> if (PageWriteback(page)) {
> redirty_page_for_writepage(wbc, page);
makes no sense, because we simply never _did_ the "clear_page_dirty()" if
the thing was under writeback in the first place. That's how C
conditionals work. So there's no reason to "redirty" it, because it
wasn't cleaned in the first place.
I've double- and triple-checked the dirty bits, including having traces
that actually say that the IO was started (from a VM perspective) _after_
the last write was done. The IO just didn't hit the disk.
I'm personally fairly convinced that it's not a VM issue, but a "IO
issue". Either in a low-level filesystem or in some of the fs/buffer.c
helper routines.
But I'd love to be proven wrong.
I do have a few interesting details from the trace I haven't really
analyzed yet. Here's the trace for events on one of the pages that was
corrupted. Note how the events are numbered (there were 171640 events
total), so the thing you see is just a small set of events from the whole
big trace, but it's the ones that talk about _that_ particular page.
I've grouped them so hat "consecutive" events group together. That just
means that no events on any other pages happened in between those events,
and it is usually a sign that it's really one single call-chain that
causes all the events.
For example, for the first group of three events (44366-44368), it's the
page fault that brings in the page, and since it's a write-fault, it will
not only map the page, it will mark the page itself dirty and then also
set the TAG_DIRTY on the mapping. So the "group" is just really a result
of one single event happening, which causes several things to happen to
that page. That's exactly what you'd expect.
Anyway, here is the list of events that page went through:
44366 PG 0f6d: mm/memory.c:2254 mapping at b789fc54 (write)
44367 PG 0f6d: mm/page-writeback.c:817 setting dirty
44368 PG 0f6d: fs/buffer.c:738 setting TAG_DIRTY
64231 PG 0f6d: mm/page-writeback.c:872 clean_for_io
64232 PG 0f6d: mm/rmap.c:451 cleaning PTE b789f000
64233 PG 0f6d: mm/page-writeback.c:914 set writeback
64234 PG 0f6d: mm/page-writeback.c:916 setting TAG_WRITEBACK
64235 PG 0f6d: mm/page-writeback.c:922 clearing TAG_DIRTY
67570 PG 0f6d: mm/page-writeback.c:891 end writeback
67571 PG 0f6d: mm/page-writeback.c:893 clearing TAG_WRITEBACK
76705 PG 0f6d: mm/page-writeback.c:817 setting dirty
76706 PG 0f6d: fs/buffer.c:725 dirtied buffers
76707 PG 0f6d: fs/buffer.c:738 setting TAG_DIRTY
105267 PG 0f6d: mm/page-writeback.c:872 clean_for_io
105268 PG 0f6d: mm/rmap.c:451 cleaning PTE b789f000
105269 PG 0f6d: mm/page-writeback.c:914 set writeback
105270 PG 0f6d: mm/page-writeback.c:916 setting TAG_WRITEBACK
105271 PG 0f6d: mm/page-writeback.c:922 clearing TAG_DIRTY
105272 PG 0f6d: mm/page-writeback.c:891 end writeback
105273 PG 0f6d: mm/page-writeback.c:893 clearing TAG_WRITEBACK
128032 PG 0f6d: mm/memory.c:670 unmapped at b789f000
132662 PG 0f6d: mm/filemap.c:119 Removing page cache
148278 PG 0f6d: mm/memory.c:2254 mapping at b789f000 (read)
166326 PG 0f6d: mm/memory.c:670 unmapped at b789f000
171958 PG
Re: [PATCH 2.6.16.29 1/1] memory: enhance Linux swap subsystem
I've re-published my work on quilt, sorry.
Index: linux-2.6.16.29/Documentation/vm_pps.txt
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.16.29/Documentation/vm_pps.txt2006-12-29 14:36:36.507332384
+0800
@@ -0,0 +1,192 @@
+ Pure Private Page System (pps)
+ Copyright by Yunfeng Zhang on GFDL 1.2
+ [EMAIL PROTECTED]
+ December 24-26, 2006
+
+// Purpose <([{
+The file is used to document the idea which is published firstly at
+http://www.ussg.iu.edu/hypermail/linux/kernel/0607.2/0451.html, as a part of my
+OS -- main page http://blog.chinaunix.net/u/21764/index.php. In brief, a patch
+of the document to enchance the performance of Linux swap subsystem. You can
+find the overview of the idea in section and how I patch it into Linux 2.6.16.29 in section .
+// }])>
+
+// How to Reclaim Pages more Efficiently <([{
+Good idea originates from overall design and management ability, when you look
+down from a manager view, you will relief yourself from disordered code and
+find some problem immediately.
+
+OK! to modern OS, its memory subsystem can be divided into three layers
+1) Space layer (InodeSpace, UserSpace and CoreSpace).
+2) VMA layer (PrivateVMA and SharedVMA, memory architecture-independent layer).
+3) PTE and page layer (architecture-dependent).
+
+Since the 2nd layer assembles the much statistic of page-acess information, so
+it's nature that swap subsystem should be deployed and implemented on the 2nd
+layer.
+
+Undoubtedly, there are some virtues about it
+1) SwapDaemon can collect the statistic of process acessing pages and by it
+ unmaps ptes, SMP specially benefits from it for we can use flush_tlb_range
+ to unmap ptes batchly rather than frequently TLB IPI interrupt per a page in
+ current Linux legacy swap subsystem.
+2) Page-fault can issue better readahead requests since history data shows all
+ related pages have conglomerating affinity. In contrast, Linux page-fault
+ readaheads the pages relative to the SwapSpace position of current
+ page-fault page.
+3) It's conformable to POSIX madvise API family.
+
+Unfortunately, Linux 2.6.16.29 swap subsystem is based on the 3rd layer -- a
+system on zone::active_list/inactive_list.
+
+I've finished a patch, see section .
Note, it ISN'T perfect.
+// }])>
+
+// Pure Private Page System -- pps <([{
+As I've referred in previous section, perfectly applying my idea need to unroot
+page-surrounging swap subsystem to migrate it on VMA, but a huge gap has
+defeated me -- active_list and inactive_list. In fact, you can find
+lru_add_active code anywhere ... It's IMPOSSIBLE to me to complete it only by
+myself. It's also the difference between my design and Linux, in my OS, page is
+the charge of its new owner totally, however, to Linux, page management system
+is still tracing it by PG_active flag.
+
+So I conceive another solution:) That is, set up an independent page-recycle
+system rooted on Linux legacy page system -- pps, intercept all private pages
+belonging to PrivateVMA to pps, then use my pps to cycle them. By the way, the
+whole job should be consist of two parts, here is the first --
+PrivateVMA-oriented (PPS), other is SharedVMA-oriented (should be called SPS)
+scheduled in future. Of course, if all are done, it will empty Linux legacy
+page system.
+
+In fact, pps is centered on how to better collect and unmap process private
+pages in SwapDaemon mm/vmscan.c:shrink_private_vma, the whole process is
+divided into six stages -- . Other sections show the remain
+aspects of pps
+1) is basic data definition.
+2) is focused on synchronization.
+3) -- how private pages enter in/go off pps.
+4) which VMA is belonging to pps.
+
+PPS uses init_mm.mm_list list to enumerate all swappable UserSpace.
+
+I'm also glad to highlight my a new idea -- dftlb which is described in
+section .
+// }])>
+
+// Delay to Flush TLB (dftlb) <([{
+Delay to flush TLB is instroduced by me to enhance flushing TLB efficiency, in
+brief, when we want to unmap a page from the page table of a process, why we
+send TLB IPI to other CPUs immediately, since every CPU has timer interrupt, we
+can insert flushing tasks into timer interrupt route to implement a
+free-charged TLB flushing.
+
+The trick is implemented in
+1) TLB flushing task is added in fill_in_tlb_task of mm/vmscan.c.
+2) timer_flush_tlb_tasks of kernel/timer.c is used by other CPUs to execute
+ flushing tasks.
+3) all data are defined in include/linux/mm.h.
+
+The restriction of dftlb. Following conditions must be met
+1) atomic cmpxchg instruction.
+2) atomically set the access bit after they touch a pte firstly.
+3) To some architectures, vma parameter of flush_tlb_range is maybe important,
+ if it's true, since it's possible that the vma of a TLB flushing task has
+ gone when a CPU starts to execute
compile fix for via-pmu-backlight
Not sure if this is right. I just copied the other conversions.
Given every other driver added a 'NULL' too, I'm a bit suspicious
but I lack the hardware to test this.
drivers/macintosh/via-pmu-backlight.c: In function 'pmu_backlight_init':
drivers/macintosh/via-pmu-backlight.c:150: error: too few arguments to function
'backlight_device_register'
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
--- linux-2.6.19.noarch/drivers/macintosh/via-pmu-backlight.c~ 2006-12-29
01:41:24.0 -0500
+++ linux-2.6.19.noarch/drivers/macintosh/via-pmu-backlight.c 2006-12-29
01:41:28.0 -0500
@@ -147,7 +147,7 @@ void __init pmu_backlight_init()
snprintf(name, sizeof(name), "pmubl");
- bd = backlight_device_register(name, NULL, _backlight_data);
+ bd = backlight_device_register(name, NULL, NULL, _backlight_data);
if (IS_ERR(bd)) {
printk("pmubl: Backlight registration failed\n");
goto error;
--
http://www.codemonkey.org.uk
-
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.19 and up to 2.6.20-rc2 Ethernet problems x86_64
On 28-12-2006 04:23, Sid Boyce wrote: > > > I first saw the problem on the 64x2 box after upgrading to 2.6.19. The > network appeared OK with ifconfig and route -n, but I had no network > access. Pinging any other box, the box was responding, but no response ... > barrabas:/usr/src/linux-2.6.20-rc1-git5 # ssh Boycie ifconfig > Password: > eth0 Link encap:Ethernet HWaddr 00:0A:E4:4E:A1:42 > inet addr:192.168.10.5 Bcast:255.255.255.255 Mask:255.255.255.0 This Bcast isn't probably what you need. Regards, Jarek P. - 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/
Fix implicit declarations in via-pmu
drivers/macintosh/via-pmu.c: In function 'pmac_suspend_devices': drivers/macintosh/via-pmu.c:2014: error: implicit declaration of function 'pm_prepare_console' drivers/macintosh/via-pmu.c: In function 'pmac_wakeup_devices': drivers/macintosh/via-pmu.c:2139: error: implicit declaration of function 'pm_restore_console' Signed-off-by: Dave Jones <[EMAIL PROTECTED]> --- linux-2.6.19.noarch/drivers/macintosh/via-pmu.c~2006-12-12 11:18:03.0 -0500 +++ linux-2.6.19.noarch/drivers/macintosh/via-pmu.c 2006-12-12 11:18:33.0 -0500 @@ -44,6 +44,7 @@ #include #include #include +#include #include #include #include -- http://www.codemonkey.org.uk - 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/
Fix implicit declarations in i386 process.c
Building the kernel with -Werror-implicit fails pretty fast with this..
arch/i386/kernel/process.c: In function '__switch_to':
arch/i386/kernel/process.c:645: error: implicit declaration of function
'load_user_cs_desc'
arch/i386/kernel/process.c: In function 'arch_add_exec_range':
arch/i386/kernel/process.c:915: error: implicit declaration of function
'set_user_cs'
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
--- linux-2.6.19.noarch/include/asm-i386/desc.h~2006-12-08
06:52:55.0 -0500
+++ linux-2.6.19.noarch/include/asm-i386/desc.h 2006-12-08 06:53:14.0
-0500
@@ -185,6 +185,20 @@ static inline unsigned long get_desc_bas
return base;
}
+static inline void set_user_cs(struct desc_struct *desc, unsigned long limit)
+{
+ limit = (limit - 1) / PAGE_SIZE;
+ desc->a = limit & 0x;
+ desc->b = (limit & 0xf) | 0x00c0fb00;
+}
+
+#define load_user_cs_desc(cpu, mm) \
+ get_cpu_gdt_table(cpu)[GDT_ENTRY_DEFAULT_USER_CS] =
(mm)->context.user_cs
+
+extern void arch_add_exec_range(struct mm_struct *mm, unsigned long limit);
+extern void arch_remove_exec_range(struct mm_struct *mm, unsigned long limit);
+extern void arch_flush_exec_range(struct mm_struct *mm);
+
#else /* __ASSEMBLY__ */
/*
@@ -208,20 +222,6 @@ static inline unsigned long get_desc_bas
shll $16, base; \
movw idx*8+2(gdt), lo_w;
-static inline void set_user_cs(struct desc_struct *desc, unsigned long limit)
-{
- limit = (limit - 1) / PAGE_SIZE;
- desc->a = limit & 0x;
- desc->b = (limit & 0xf) | 0x00c0fb00;
-}
-
-#define load_user_cs_desc(cpu, mm) \
- get_cpu_gdt_table(cpu)[GDT_ENTRY_DEFAULT_USER_CS] =
(mm)->context.user_cs
-
-extern void arch_add_exec_range(struct mm_struct *mm, unsigned long limit);
-extern void arch_remove_exec_range(struct mm_struct *mm, unsigned long limit);
-extern void arch_flush_exec_range(struct mm_struct *mm);
-
#endif /* !__ASSEMBLY__ */
#endif
--
http://www.codemonkey.org.uk
-
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.20-rc1 6/6] input: ads7846 directly senses PENUP state
On Thursday 28 December 2006 17:37, David Brownell wrote:
> > > > I think these helpers just obfuscate the code, just call
> > > > input_report_*() and input_sync() drectly like you used to do.
> > >
> > > Fair enough, I had a similar thought. Imre, could you do that update?
> >
> > Yes, the patch is against the OMAP tree.
>
> Thanks ... still hoping that the OMAP tree will just be able
> to pull down the kernel.org version of this driver soon!!
>
> OK, here's an updated patch 6/6 that merges Imre's update.
>
> Dmitry, that makes six patches you should have ... I updated
> the hwmon patch (#3), and now this one (#6); #4 and #5 will
> thus apply with some offsets.
>
David,
I appied all patches except for hwmon as it had some issues with CONFIG_HWMON
handling. Could you please take a look at the patch below and tell me if it
works for you?
--
Dmitry
From: David Brownell <[EMAIL PROTECTED]>
Input: ads7846 - be more compatible with the hwmon framework
- Hook up to hwmon
* show sensor attributes only if hwmon is present
* ... and the board's reference voltage is known
* otherwise be just a touchscreen
- Report voltages per hwmon convention
* measure in millivolts
* voltages are named in[0-8]_input (ugh)
* for 7846 chips, properly range-adjust vBATT/in1_input
Battery measurements help during recharge monitoring. On OSK/Mistral,
the measured voltage agreed with a multimeter to several decimal places.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/input/touchscreen/Kconfig |9 -
drivers/input/touchscreen/ads7846.c | 306 +---
2 files changed, 224 insertions(+), 91 deletions(-)
Index: work/drivers/input/touchscreen/Kconfig
===
--- work.orig/drivers/input/touchscreen/Kconfig
+++ work/drivers/input/touchscreen/Kconfig
@@ -12,13 +12,18 @@ menuconfig INPUT_TOUCHSCREEN
if INPUT_TOUCHSCREEN
config TOUCHSCREEN_ADS7846
- tristate "ADS 7846 based touchscreens"
+ tristate "ADS 7846/7843 based touchscreens"
depends on SPI_MASTER
+ depends on HWMON = n || HWMON
help
Say Y here if you have a touchscreen interface using the
- ADS7846 controller, and your board-specific initialization
+ ADS7846 or ADS7843 controller, and your board-specific setup
code includes that in its table of SPI devices.
+ If HWMON is selected, and the driver is told the reference voltage
+ on your board, you will also get hwmon interfaces for the voltage
+ (and on ads7846, temperature) sensors of this chip.
+
If unsure, say N (but it's safe to say "Y").
To compile this driver as a module, choose M here: the
Index: work/drivers/input/touchscreen/ads7846.c
===
--- work.orig/drivers/input/touchscreen/ads7846.c
+++ work/drivers/input/touchscreen/ads7846.c
@@ -17,8 +17,9 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-#include
+#include
#include
+#include
#include
#include
#include
@@ -69,7 +70,7 @@ struct ts_event {
u16 x;
u16 y;
u16 z1, z2;
- intignore;
+ int ignore;
};
struct ads7846 {
@@ -77,7 +78,12 @@ struct ads7846 {
charphys[32];
struct spi_device *spi;
+
+#if defined(CONFIG_HWMON) || (defined(MODULE) && defined(CONFIG_HWMON_MODULE))
struct attribute_group *attr_group;
+ struct class_device *hwmon;
+#endif
+
u16 model;
u16 vref_delay_usecs;
u16 x_plate_ohms;
@@ -170,7 +176,12 @@ struct ads7846 {
/*
* Non-touchscreen sensors only use single-ended conversions.
+ * The range is GND..vREF. The ads7843 and ads7835 must use external vREF;
+ * ads7846 lets that pin be unconnected, to use internal vREF.
*/
+static unsigned vREF_mV;
+module_param(vREF_mV, uint, 0);
+MODULE_PARM_DESC(vREF_mV, "external vREF voltage, in milliVolts");
struct ser_req {
u8 ref_on;
@@ -198,50 +209,55 @@ static int ads7846_read12_ser(struct dev
struct ser_req *req = kzalloc(sizeof *req, GFP_KERNEL);
int status;
int sample;
- int i;
+ int use_internal;
if (!req)
return -ENOMEM;
spi_message_init(>msg);
- /* activate reference, so it has time to settle; */
- req->ref_on = REF_ON;
- req->xfer[0].tx_buf = >ref_on;
- req->xfer[0].len = 1;
- req->xfer[1].rx_buf = >scratch;
- req->xfer[1].len = 2;
-
- /*
-* for external VREF, 0 usec (and assume it's
replace "memset(...,0,PAGE_SIZE)" calls with "clear_page()"?
is there some reason there are so many calls of the form memset(addr, 0, PAGE_SIZE) rather than the apparently equivalent invocation of clear_page(addr) the majority of architectures appear to define the clear_page() macro in their include//page.h header file, but not entirely identically, and in some cases that definition is conditional, as with i386: = #ifdef CONFIG_X86_USE_3DNOW ... #define clear_page(page)mmx_clear_page((void *)(page)) ... #else ... #define clear_page(page)memset((void *)(page), 0, PAGE_SIZE) ... #endif should it perhaps be part of the CodingStyle doc to use the clear_page() macro rather than an explicit call to memset()? (and should all architectures be required to define that macro?) rday - 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: at arch/i386/mm/highmem.c:50 kmap_atomic()
On Thu, 28 Dec 2006 19:58:40 -0800 Daniel Walker <[EMAIL PROTECTED]> wrote: > Got several of the messages below on 2.6.20-rc2-mm1 . > > > Dec 29 03:34:08 10 kernel: [ 264.519401] BUG: at arch/i386/mm/highmem.c:50 > kmap_atomic() doh, I had a copy-n-paste error in the debug code, 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: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Dmitry Torokhov wrote:
On Friday 29 December 2006 00:17, Rene Herman wrote:
Yes, I do have that in my tree. From the looks of it it's probably not
surprising, but the following gets me blinking leds without the spurious
ACK messages. Maybe still useful to know?
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index debe944..9c70d34 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -371,7 +371,7 @@ static irqreturn_t i8042_interrupt(int i
if (unlikely(i8042_suppress_kbd_ack))
if (port_no == I8042_KBD_PORT_NO &&
(data == 0xfa || data == 0xfe)) {
- i8042_suppress_kbd_ack = 0;
+ /* i8042_suppress_kbd_ack = 0; */
goto out;
That would indicate that your keyboard generates multiple acks... I wonder
if you could boot with i8042.debug=1 and somehow capture the data flow
during panic (do you have a digital camera?).
Not even an analog camera, but with or without the above, I get a single:
" <7>drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [ 902]"
when it panics. During a full boot, I get:
===
pnp: the driver 'i8042 kbd' has been registered
pnp: match found with the PnP device '00:06' and the driver 'i8042 kbd'
pnp: the driver 'i8042 aux' has been registered
PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
PNP: PS/2 controller doesn't have AUX irq; using default 12
drivers/input/serio/i8042.c: 20 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 65 <- i8042 (return) [1]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 74 -> i8042 (parameter) [1]
drivers/input/serio/i8042.c: d3 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 5a -> i8042 (parameter) [1]
drivers/input/serio/i8042.c: 5a <- i8042 (return) [1]
drivers/input/serio/i8042.c: a7 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 20 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 74 <- i8042 (return) [1]
drivers/input/serio/i8042.c: a8 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 20 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 54 <- i8042 (return) [1]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [2]
drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [2]
drivers/input/serio/i8042.c: d3 -> i8042 (command) [2]
drivers/input/serio/i8042.c: a5 -> i8042 (parameter) [2]
drivers/input/serio/i8042.c: a5 <- i8042 (flush, aux) [252]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [252]
drivers/input/serio/i8042.c: 74 -> i8042 (parameter) [252]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [252]
drivers/input/serio/i8042.c: 65 -> i8042 (parameter) [252]
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
drivers/input/serio/i8042.c: f2 -> i8042 (kbd-data) [252]
input: PC Speaker as /class/input/input4
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [255]
drivers/input/serio/i8042.c: ab <- i8042 (interrupt, 0, 1) [256]
drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, 0, 1) [258]
drivers/input/serio/i8042.c: ed -> i8042 (kbd-data) [258]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [261]
drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [261]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [264]
drivers/input/serio/i8042.c: f3 -> i8042 (kbd-data) [264]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [267]
drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [267]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [270]
drivers/input/serio/i8042.c: f4 -> i8042 (kbd-data) [270]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [273]
input: AT Translated Set 2 keyboard as /class/input/input5
===
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: open /dev/kvm: No such file or directory
On Thursday 28 December 2006 16:51, Avi Kivity wrote: > Greg, /dev/kvm is a MISC_DYNAMIC_MINOR device. Is there any way of > using it without udev? Should I allocate a static number? You can write a small script that parses /proc/misc and creates the device, like # /sbin/mknod /dev/kvm c 10 `grep '\' /proc/misc | cut -f 1 -d\ ` If you already have an init script, e.g. to set up tun/tap devices, it would make sense to put it in there. Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] infiniband/ulp/ipoib/ipoib_cm.c: make functions static
> Quoting Adrian Bunk <[EMAIL PROTECTED]>: > Subject: [-mm patch] infiniband/ulp/ipoib/ipoib_cm.c: make functions static > > On Thu, Dec 28, 2006 at 02:42:37AM -0800, Andrew Morton wrote: > >... > > Changes since 2.6.20-rc1-mm1: > >... > > git-infiniband.patch > >... > > git trees > >... > > > This patch makes some needlessly global functions static. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Thanks, I'll put this in my tree. -- MST - 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.20-rc1] xfrm: Algorithm lookup using .compat name
From: Herbert Xu <[EMAIL PROTECTED]> Date: Sat, 23 Dec 2006 08:04:46 +1100 > On Fri, Dec 22, 2006 at 05:26:43PM +0100, Martin Willi wrote: > > Installing an IPsec SA using old algorithm names (.compat) does not work > > if the algorithm is not already loaded. When not using the PF_KEY > > interface, algorithms are not preloaded in xfrm_probe_algs() and > > installing a IPsec SA fails. > > Good catch. Thanks Martin! Applied. Martin, please be careful with future patch submissions, your email client corrupted up the patch by adding newlines and changing tab characters into spaces, so I had to add the patch by hand. Herbert, this fix is only needed for 2.6.20 correct? I assume it was added by the 2.6.20 crypto layer merge, right? 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: Changes to PM layer break userspace
On Thursday 28 December 2006 5:31 am, Alan wrote: > > Seems to me anyone really desperate to put PCI devices into a low > > power mode, without driver support at the "ifdown" level, would be > > able just "rmmod driver; setpci". > > Incorrect for very obvious reasons - there may be two devices driven by > the same driver one up and one down. Let me emphasize "desperate". ;) The examples given were all cases where that didn't seem to be an issue. But agreed, the best approach is really to make devices not in active use (i.e. before "ifup", after "ifdown" ... maybe even whenever no driver is bound to the device) stay in low power states. - Dave - 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 2.6.20-rc2] atkbd.c: Spurious ACK
On Friday 29 December 2006 00:17, Rene Herman wrote:
> Dmitry Torokhov wrote:
>
> >>> The change to suppress ACKs from paic blinking is already in Linus's
> >>> tree. I just tried booting with root=/dev/sdg and I had leds blinking
> >>> but no messages from atkbd were seen.
> >>>
> >>> Could it be that you loaded older kernel by accident? Does anybody
> >>> else still seeing "Spurios ACK" messages during kernel panic?
> >> Well, no, I'm really on 2.6.20-rc2, from a freshly cloned tree. And I do
> >> get atkbd.c complaining at me when I boot with root=/dev/wrong-device.
> >>
> >> Could you point me to the changeset in question? I couldn't find it
> >> searching for "leds" in the log.
> >>
> >
> > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=817e6ba3623de9cdc66c6aba90eae30b5588ff11
>
> Yes, I do have that in my tree. From the looks of it it's probably not
> surprising, but the following gets me blinking leds without the spurious
> ACK messages. Maybe still useful to know?
>
> diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
> index debe944..9c70d34 100644
> --- a/drivers/input/serio/i8042.c
> +++ b/drivers/input/serio/i8042.c
> @@ -371,7 +371,7 @@ static irqreturn_t i8042_interrupt(int i
> if (unlikely(i8042_suppress_kbd_ack))
> if (port_no == I8042_KBD_PORT_NO &&
> (data == 0xfa || data == 0xfe)) {
> - i8042_suppress_kbd_ack = 0;
> + /* i8042_suppress_kbd_ack = 0; */
> goto out;
That would indicate that your keyboard generates multiple acks... I wonder
if you could boot with i8042.debug=1 and somehow capture the data flow
during panic (do you have a digital camera?).
--
Dmitry
-
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 2.6.20-rc2] atkbd.c: Spurious ACK
Dmitry Torokhov wrote:
The change to suppress ACKs from paic blinking is already in Linus's
tree. I just tried booting with root=/dev/sdg and I had leds blinking
but no messages from atkbd were seen.
Could it be that you loaded older kernel by accident? Does anybody
else still seeing "Spurios ACK" messages during kernel panic?
Well, no, I'm really on 2.6.20-rc2, from a freshly cloned tree. And I do
get atkbd.c complaining at me when I boot with root=/dev/wrong-device.
Could you point me to the changeset in question? I couldn't find it
searching for "leds" in the log.
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=817e6ba3623de9cdc66c6aba90eae30b5588ff11
Yes, I do have that in my tree. From the looks of it it's probably not
surprising, but the following gets me blinking leds without the spurious
ACK messages. Maybe still useful to know?
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index debe944..9c70d34 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -371,7 +371,7 @@ static irqreturn_t i8042_interrupt(int i
if (unlikely(i8042_suppress_kbd_ack))
if (port_no == I8042_KBD_PORT_NO &&
(data == 0xfa || data == 0xfe)) {
- i8042_suppress_kbd_ack = 0;
+ /* i8042_suppress_kbd_ack = 0; */
goto out;
}
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: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
On Thursday 28 December 2006 23:20, Rene Herman wrote: > Dmitry Torokhov wrote: > > > The change to suppress ACKs from paic blinking is already in Linus's > > tree. I just tried booting with root=/dev/sdg and I had leds blinking > > but no messages from atkbd were seen. > > > > Could it be that you loaded older kernel by accident? Does anybody > > else still seeing "Spurios ACK" messages during kernel panic? > > Well, no, I'm really on 2.6.20-rc2, from a freshly cloned tree. And I do > get atkbd.c complaining at me when I boot with root=/dev/wrong-device. > > Could you point me to the changeset in question? I couldn't find it > searching for "leds" in the log. > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=817e6ba3623de9cdc66c6aba90eae30b5588ff11 -- Dmitry - 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.20-rc2] Fix set_pte_at arguments in page_mkclean_one
From: Balbir Singh <[EMAIL PROTECTED]> Date: Fri, 29 Dec 2006 09:43:10 +0530 > page_mkclean_one() passes vma instead of the expected mm as argument1 to > set_pte_at. Below is a simple fix (tested by compiling the kernel on > powerpc). Please ignore the patch, if a fix has already been applied. > > Signed-off-by: Balbir Singh <[EMAIL PROTECTED]> Good catch. Signed-off-by: David S. Miller <[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: [RFC] delayed allocation for ext4
> David Chinner (DC) writes: DC> So that mean's we'll have 2 separate mechanisms for marking DC> pages as delalloc. XFS uses the BH_delay flag to indicate DC> that a buffer (block) attached to the page is using delalloc. >> >> well, for blocksize=pagesize we can save 56 bytes on every page. DC> Sure, but it means that ext4 w/ delalloc won't work on lots of DC> machines it does not currenly. but I'm going to implement that. not sure whether it's worth to have two different codepaths for block size=page size and block size < page size. DC> FWIW, how does this mechanism deal with block size < page size? DC> Don't you have to track delalloc on a block basis rather than DC> a page basis? >> >> I'm still thinking how better to deal with that w/o much code duplication. DC> Code duplication in ext4, or across all filesystems? given what Andrew said about moving the code into VFS, it's more about all filesystems. thanks, Alex - 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.20-rc2: known unfixed regressions
From: "Horst H. von Brand" <[EMAIL PROTECTED]> Date: Thu, 28 Dec 2006 22:36:02 -0300 > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19. > > Add that on SPARC64 boot fails due to missing /dev/root. Vanilla 2.6.19 and > 2.6.19.1 work fine, before 2.6.20-rc1 it broke. I checked the initrds for > both versions, the only difference "diff -Nur" finds between the unpacked > initrds are the modules themselves (obviously). Did you report this will all relevant details on [EMAIL PROTECTED] so that the sparc64 maintainers can analyze the problem? I didn't see the report there else I would be looking into it. Please don't report sparc64 bugs here, 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: open /dev/kvm: No such file or directory
On 12/28/06, Jeff Chua <[EMAIL PROTECTED]> wrote: > Are you sure the kvm_intel & kvm modules are loaded? > Please check your dmesg. I checked and it's loaded ... Module Size Used by kvm_intel 18572 0 kvm 46276 1 kvm_intel Any chance of getting a static /dev/kvm ? Thanks, Jeff. - 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 2.6.20-rc2] atkbd.c: Spurious ACK
Dmitry Torokhov wrote: The change to suppress ACKs from paic blinking is already in Linus's tree. I just tried booting with root=/dev/sdg and I had leds blinking but no messages from atkbd were seen. Could it be that you loaded older kernel by accident? Does anybody else still seeing "Spurios ACK" messages during kernel panic? Well, no, I'm really on 2.6.20-rc2, from a freshly cloned tree. And I do get atkbd.c complaining at me when I boot with root=/dev/wrong-device. Could you point me to the changeset in question? I couldn't find it searching for "leds" in the log. 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/
[PATCH 2.6.20-rc2] Fix set_pte_at arguments in page_mkclean_one
page_mkclean_one() passes vma instead of the expected mm as argument1 to set_pte_at. Below is a simple fix (tested by compiling the kernel on powerpc). Please ignore the patch, if a fix has already been applied. Signed-off-by: Balbir Singh <[EMAIL PROTECTED]> --- mm/rmap.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN mm/rmap.c~fix-set-pte-in-page_mkclean_one mm/rmap.c --- linux-2.6.20-rc2/mm/rmap.c~fix-set-pte-in-page_mkclean_one 2006-12-29 09:18:26.0 +0530 +++ linux-2.6.20-rc2-balbir/mm/rmap.c 2006-12-29 09:25:28.0 +0530 @@ -461,7 +461,7 @@ static int page_mkclean_one(struct page entry = ptep_clear_flush(vma, address, pte); entry = pte_wrprotect(entry); entry = pte_mkclean(entry); - set_pte_at(vma, address, pte, entry); + set_pte_at(mm, address, pte, entry); lazy_mmu_prot_update(entry); ret = 1; } _ -- Balbir Singh, Linux Technology Center, IBM Software Labs - 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/
BUG: soft lockup detected / list_add corruption
Got this while trying to mount a ext3 block device. The host was running nfs root [ 929.130331] nfs: server 10.0.13.21 not responding, still trying [ 931.346289] BUG: soft lockup detected on CPU#3! [ 931.350860] [] show_trace_log_lvl+0x1a/0x2f [ 931.356081] [] show_trace+0x12/0x14 [ 931.360590] [] dump_stack+0x16/0x18 [ 931.365124] [] softlockup_tick+0xca/0xdc [ 931.370069] [] run_local_timers+0x12/0x14 [ 931.375092] [] update_process_times+0x3e/0x63 [ 931.380456] [] hrtimer_sched_tick+0x6c/0xb3 [ 931.385686] [] hrtimer_interrupt+0x132/0x1cd [ 931.390983] [] local_apic_timer_interrupt+0x41/0x46 [ 931.396924] [] smp_apic_timer_interrupt+0x2d/0x3c [ 931.402626] [] apic_timer_interrupt+0x33/0x38 [ 931.408013] [] on_each_cpu+0x1a/0x46 [ 931.412593] [] mce_work_fn+0x1e/0x2f [ 931.417198] [] run_workqueue+0x9a/0x174 [ 931.422066] [] worker_thread+0xf8/0x124 [ 931.426900] [] kthread+0xb5/0xde [ 931.431125] [] kernel_thread_helper+0x7/0x10 ... Then a few seconds later , got this, [ 931.905246] NETDEV WATCHDOG: eth0: transmit timed out [ 937.894061] NETDEV WATCHDOG: eth0: transmit timed out [ 941.217545] nfs: server 10.0.13.21 not responding, still trying [ 943.882880] NETDEV WATCHDOG: eth0: transmit timed out [ 946.881281] list_add corruption. prev->next should be next (c3cb9ed8), but was c3e16af8. (prev=c3e16af8). [ 946.891028] [ cut here ] [ 946.895661] kernel BUG at lib/list_debug.c:33! [ 946.900178] invalid opcode: [#1] [ 946.903886] SMP [ 946.905771] last sysfs file: /kernel/uevent_seqnum [ 946.910605] Modules linked in: [ 946.913697] CPU:3 [ 946.913698] EIP:0060:[]Not tainted VLI [ 946.913700] EFLAGS: 00010082 (2.6.20-rc2-mm1 #20) [ 946.926397] EIP is at __list_add+0x73/0x89 [ 946.930521] eax: 0070 ebx: c3cb9ed8 ecx: c1a91c74 edx: 0001 [ 946.937362] esi: c3e16af8 edi: c3e16af8 ebp: c3cefe24 esp: c3cefe08 [ 946.944196] ds: 007b es: 007b fs: 00d8 gs: ss: 0068 [ 946.950097] Process events/3 (pid: 17, ti=c3cee000 task=c3cea270 task.ti=c3cee000) [ 946.957571] Stack: c17d1af5 c3cb9ed8 c3e16af8 c3e16af8 c3cb9eb4 c3e16af4 0282 c3cefe3c [ 946.966120]c01416bc c013a5c6 c3c5dcf4 0003 c3e16af4 c3cefe50 c0141727 c3e16af4 [ 946.974706]0100 c3cda000 c3cefe80 c013a5d5 c01416e7 c3e16b20 c3cefe80 c014e305 [ 946.983259] Call Trace: [ 946.985905] [] show_trace_log_lvl+0x1a/0x2f [ 946.991135] [] show_stack_log_lvl+0x9d/0xac [ 946.996363] [] show_registers+0x1b2/0x288 [ 947.001411] [] die+0x127/0x23f [ 947.005473] [] do_trap+0x7f/0x99 [ 947.009661] [] do_invalid_op+0x97/0xa1 [ 947.014457] [] error_code+0x7c/0x84 [ 947.018968] [] __queue_work+0x48/0x73 [ 947.023637] [] delayed_work_timer_fn+0x40/0x45 [ 947.029064] [] run_timer_softirq+0x121/0x189 [ 947.034374] [] __do_softirq+0x78/0xf8 [ 947.039068] [] do_softirq+0x4b/0x77 [ 947.043571] [] irq_exit+0x47/0x8b [ 947.047899] [] smp_apic_timer_interrupt+0x32/0x3c [ 947.053655] [] apic_timer_interrupt+0x33/0x38 [ 947.059005] [] on_each_cpu+0x1a/0x46 [ 947.063605] [] mce_work_fn+0x1e/0x2f [ 947.068228] [] run_workqueue+0x9a/0x174 [ 947.073076] [] worker_thread+0xf8/0x124 [ 947.077937] [] kthread+0xb5/0xde [ 947.082187] [] kernel_thread_helper+0x7/0x10 [ 947.087485] === [ 947.091125] Code: 1d b5 c1 39 1e 0f 95 c2 e8 65 76 00 00 85 c0 74 1e 8b 06 89 74 24 0c 89 5c 24 04 c7 04 24 f5 1a 7d c1 89 44 24 [ 947.111085] EIP: [] __list_add+0x73/0x89 SS:ESP 0068:c3cefe08 [ 947.125703] <0>Kernel panic - not syncing: Fatal exception in interrupt - 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/
BUG: at arch/i386/mm/highmem.c:50 kmap_atomic()
Got several of the messages below on 2.6.20-rc2-mm1 . Dec 29 03:34:08 10 kernel: [ 264.519401] BUG: at arch/i386/mm/highmem.c:50 kmap_atomic() Dec 29 03:34:08 10 kernel: [ 264.524973] [] show_trace_log_lvl+0x1a/0x2f Dec 29 03:34:08 10 kernel: [ 264.530129] [] show_trace+0x12/0x14 Dec 29 03:34:08 10 kernel: [ 264.534583] [] dump_stack+0x16/0x18 Dec 29 03:34:08 10 kernel: [ 264.539030] [] kmap_atomic+0xcc/0x1e4 Dec 29 03:34:08 10 kernel: [ 264.543668] [] skb_copy_and_csum_bits+0x13f/0x31a Dec 29 03:34:08 10 kernel: [ 264.549340] [] skb_copy_and_csum_dev+0x94/0xcc Dec 29 03:34:08 10 kernel: [ 264.554741] [] rtl8139_start_xmit+0x73/0x12b Dec 29 03:34:08 10 kernel: [ 264.559987] [] dev_hard_start_xmit+0x21c/0x29d Dec 29 03:34:08 10 kernel: [ 264.565395] [] __qdisc_run+0x107/0x1d2 Dec 29 03:34:08 10 kernel: [ 264.570104] [] dev_queue_xmit+0x15c/0x26e Dec 29 03:34:08 10 kernel: [ 264.575071] [] ip_output+0x20b/0x245 Dec 29 03:34:08 10 kernel: [ 264.579622] [] ip_push_pending_frames+0x338/0x422 Dec 29 03:34:08 10 kernel: [ 264.585285] [] udp_push_pending_frames+0x2b9/0x2db Dec 29 03:34:08 10 kernel: [ 264.591034] [] udp_sendmsg+0x496/0x5e8 Dec 29 03:34:08 10 kernel: [ 264.595759] [] inet_sendmsg+0x3e/0x49 Dec 29 03:34:08 10 kernel: [ 264.600381] [] sock_sendmsg+0xe7/0x104 Dec 29 03:34:08 10 kernel: [ 264.605093] [] kernel_sendmsg+0x28/0x37 Dec 29 03:34:08 10 kernel: [ 264.609889] [] xs_send_kvec+0x73/0x7b Dec 29 03:34:08 10 kernel: [ 264.614514] [] xs_sendpages+0x19f/0x1c4 Dec 29 03:34:08 10 kernel: [ 264.619325] [] xs_udp_send_request+0x40/0xf6 Dec 29 03:34:08 10 kernel: [ 264.624554] [] xprt_transmit+0xdb/0x1d9 Dec 29 03:34:08 10 kernel: [ 264.629349] [] call_transmit+0x1fc/0x228 Dec 29 03:34:08 10 kernel: [ 264.634232] [] __rpc_execute+0x9b/0x20d Dec 29 03:34:08 10 kernel: [ 264.639026] [] rpc_execute+0x1b/0x1e Dec 29 03:34:08 10 kernel: [ 264.643575] [] nfs_execute_write+0x36/0x46 Dec 29 03:34:08 10 kernel: [ 264.648628] [] nfs_flush_one+0xc4/0x109 Dec 29 03:34:08 10 kernel: [ 264.653427] [] nfs_flush_list+0x82/0xce Dec 29 03:34:08 10 kernel: [ 264.658221] [] nfs_sync_mapping_wait+0x111/0x1fe Dec 29 03:34:08 10 kernel: [ 264.663803] [] nfs_wb_all+0x53/0x6f Dec 29 03:34:08 10 kernel: [ 264.668254] [] nfs_file_flush+0x44/0x77 Dec 29 03:34:08 10 kernel: [ 264.673059] [] filp_close+0x35/0x5c Dec 29 03:34:08 10 kernel: [ 264.677509] [] sys_dup2+0xd0/0xfc Dec 29 03:34:08 10 kernel: [ 264.681789] [] 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/
[PATCH] Input: HID - add CIDC USB device to HID blacklist
From: Zheng XiaoJun <[EMAIL PROTECTED]>
Add CIDC USB device to HID blacklist since it is actually a USB token
and has its own driver.
Signed-off-by: Zheng XiaoJun <[EMAIL PROTECTED]>
---
--- linux-2.6.19.1.orig/drivers/usb/input/hid-core.c2006-12-09
19:29:47.0 +0800
+++ linux-2.6.19.1/drivers/usb/input/hid-core.c 2006-12-25
13:54:24.0 +0800
@@ -1643,6 +1643,8 @@ void hid_init_reports(struct hid_device
#define USB_VENDOR_ID_AIRCABLE 0x16CA
#define USB_DEVICE_ID_AIRCABLE10x1502
+#define USB_VENDOR_ID_CIDC 0x1677
+
/*
* Alphabetically sorted blacklist by quirk type.
*/
@@ -1812,6 +1814,8 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_PANJIT, 0x0004, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_TURBOX, USB_DEVICE_ID_TURBOX_KEYBOARD,
HID_QUIRK_NOGET },
+
+ { USB_VENDOR_ID_CIDC, 0x0103, HID_QUIRK_IGNORE },
{ 0, 0 }
};
-
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/
Subject: [PATCH] Input: HID - add CIDC USB device to HID blacklist
From: Zheng XiaoJun <[EMAIL PROTECTED]>
Add CIDC USB device to HID blacklist since it is actually a USB token
and has its own driver.
Signed-off-by: Zheng XiaoJun <[EMAIL PROTECTED]>
---
--- linux-2.6.19.1.orig/drivers/usb/input/hid-core.c2006-12-09
19:29:47.0 +0800
+++ linux-2.6.19.1/drivers/usb/input/hid-core.c 2006-12-25
13:54:24.0 +0800
@@ -1643,6 +1643,8 @@ void hid_init_reports(struct hid_device
#define USB_VENDOR_ID_AIRCABLE 0x16CA
#define USB_DEVICE_ID_AIRCABLE10x1502
+#define USB_VENDOR_ID_CIDC 0x1677
+
/*
* Alphabetically sorted blacklist by quirk type.
*/
@@ -1812,6 +1814,8 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_PANJIT, 0x0004, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_TURBOX, USB_DEVICE_ID_TURBOX_KEYBOARD,
HID_QUIRK_NOGET },
+
+ { USB_VENDOR_ID_CIDC, 0x0103, HID_QUIRK_IGNORE },
{ 0, 0 }
};
-
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] Input: HID - add CIDC USB device to HID blacklist
Subject: [PATCH] Input: HID - add CIDC USB device to HID blacklist
From: Zheng XiaoJun <[EMAIL PROTECTED]>
Add CIDC USB device to HID blacklist since it is actually a USB token
and has its own driver.
Signed-off-by: Zheng XiaoJun <[EMAIL PROTECTED]>
---
--- linux-2.6.19.1.orig/drivers/usb/input/hid-core.c2006-12-09
19:29:47.0 +0800
+++ linux-2.6.19.1/drivers/usb/input/hid-core.c 2006-12-25
13:54:24.0 +0800
@@ -1643,6 +1643,8 @@ void hid_init_reports(struct hid_device
#define USB_VENDOR_ID_AIRCABLE 0x16CA
#define USB_DEVICE_ID_AIRCABLE10x1502
+#define USB_VENDOR_ID_CIDC 0x1677
+
/*
* Alphabetically sorted blacklist by quirk type.
*/
@@ -1812,6 +1814,8 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_PANJIT, 0x0004, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_TURBOX, USB_DEVICE_ID_TURBOX_KEYBOARD,
HID_QUIRK_NOGET },
+
+ { USB_VENDOR_ID_CIDC, 0x0103, HID_QUIRK_IGNORE },
{ 0, 0 }
};
-
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 2.6.20-rc2] atkbd.c: Spurious ACK
On Thursday 28 December 2006 16:45, Rene Herman wrote: > Dave Jones wrote: > > > On Wed, Dec 27, 2006 at 10:32:53PM +0100, Rene Herman wrote: > > >> The bug where the kernel repetitively emits "atkbd.c: Spurious ACK > >> on isa0060/serio0. Some program might be trying access hardware > >> directly" (sic) on a panic, thereby scrolling away the information > >> that would help in seeing what exactly the problem was (ie, "Unable > >> to mount root fs" or something) is still present in 2.6.20-rc2. > > > > Do you have a KVM ? Quite a few of those seem to tickle this printk. > > No, regular old PS/2 keyboard, directly connected. Due to that exact > uneventfullness and having seen it reported before recently (*) I > assumed everyone was seeing this. If not, I guess I can try to narrow it > down. > > It's easy to test for anyone willing: just boot with "root=/dev/null" or > something as a kernel param. The printk's are in sync with the panic > code blinking the leds. > > (*) Here there was supposed to be a link to the post I was refferring > to, but googling for it led to http://lkml.org/lkml/2006/11/13/300 > > Dmitry, could you ask Linus to pull the change? I find this to be an > exceedingly annoying bug. It's just so incredibly silly, having one part > of the kernel helpfully blink leds at you with another part going "hey, > dude! don't do that!" > Hi Rene, The change to suppress ACKs from paic blinking is already in Linus's tree. I just tried booting with root=/dev/sdg and I had leds blinking but no messages from atkbd were seen. Could it be that you loaded older kernel by accident? Does anybody else still seeing "Spurios ACK" messages during kernel panic? -- Dmitry - 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] mm: fix page_mkclean_one
I think what might be happening is that pdflush writes them out fine,
however we don't trap writes by the application _during_ that writeout.
Yeah. I believe that more exactly it happens if the very last
write to the page causes a writeback (due to dirty balancing)
while another writeback for the page is already happening.
As usual in these cases, I have zero proof.
It's something that will only occur with writeback and MAP_SHARED
writable access to the file pages.
It's the do_wp_page -> balance_dirty_pages -> generic_writepages
path for sure. Maybe it's enough to change
if (wbc->sync_mode != WB_SYNC_NONE)
wait_on_page_writeback(page);
if (PageWriteback(page) ||
!clear_page_dirty_for_io(page)) {
unlock_page(page);
continue;
}
to
if (wbc->sync_mode != WB_SYNC_NONE)
wait_on_page_writeback(page);
if (PageWriteback(page)) {
redirty_page_for_writepage(wbc, page);
unlock_page(page);
continue;
}
if (!clear_page_dirty_for_io(page)) {
unlock_page(page);
continue;
}
or something along those lines. Completely untested of course :-)
Segher
-
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] delayed allocation for ext4
On Sat, Dec 23, 2006 at 10:09:57PM +0300, Alex Tomas wrote: > > Good day, > > > David Chinner (DC) writes: > > DC> So that mean's we'll have 2 separate mechanisms for marking > DC> pages as delalloc. XFS uses the BH_delay flag to indicate > DC> that a buffer (block) attached to the page is using delalloc. > > well, for blocksize=pagesize we can save 56 bytes on every page. Sure, but it means that ext4 w/ delalloc won't work on lots of machines > DC> FWIW, how does this mechanism deal with block size < page size? > DC> Don't you have to track delalloc on a block basis rather than > DC> a page basis? > > I'm still thinking how better to deal with that w/o much code duplication. Code duplication in ext4, or across all filesystems? > DC> Ah, that's why you can get away with a page flag - you've ignored > DC> the partial page delay state problem. Any plans to use the > DC> existing method in the future so we will be able to use ext4 delalloc > DC> on machines with a page size larger than 4k? > > what do you mean by "exsiting"? BH_delay? Yes. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] delayed allocation for ext4
On Sat, Dec 23, 2006 at 09:27:18AM +, Christoph Hellwig wrote: > On Sat, Dec 23, 2006 at 02:31:23PM +1100, David Chinner wrote: > > > - ext4-delayed-allocation.patch > > >delayed allocation itself, enabled by "delalloc" mount option. > > >extents support is also required. currently it works only > > >with blocksize=pagesize. > > > > Ah, that's why you can get away with a page flag - you've ignored > > the partial page delay state problem. Any plans to use the > > existing method in the future so we will be able to use ext4 delalloc > > on machines with a page size larger than 4k? > > I think fixing this up for blocksize < pagesize is an absolute requirement > to get things merged. We don't need more filesystems that are crippled > on half of our platforms. > > Note that recording delayed alloc state at a page granularity in addition > to just the buffer heads has a lot of advantages aswell and would help > xfs, too. But I think it makes a lot more sense to record it as a radix > tree tag to speed up the gang lookups for delalloc conversion. I'm not sure it will make that much difference, really. Looking up by delalloc tag is only going to save a few tail pages in pagevec we use for the look up and could be more expensive if delalloc pages are sparsely distributed through the file. We'd still have to keep the bufferheads around for partial page state, and that becomes an interesting exercise in keeping things coherent between the radix tree and the buffer heads. Of course, then there's the unwritten state that XFS also carries around per block (bufferhead) which has all the same issues as the delalloc state. I'd hate to have a generic method for handling delalloc state which is different from the handling of the unwritten state and needing two different sets of code to handle what is essentially the same thing Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] drivers/mtd/ubi/vtbl.c: make 2 functions static
On Thu, Dec 28, 2006 at 02:42:37AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-rc1-mm1:
>...
> git-ubi.patch
>...
> git trees
>...
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/mtd/ubi/vtbl.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
--- linux-2.6.20-rc2-mm1/drivers/mtd/ubi/vtbl.c.old 2006-12-29
01:52:47.0 +0100
+++ linux-2.6.20-rc2-mm1/drivers/mtd/ubi/vtbl.c 2006-12-29 01:53:30.0
+0100
@@ -178,8 +178,8 @@
return 0;
}
-const struct ubi_vtbl_vtr *get_ivol_vtr(const struct ubi_info *ubi,
- int vol_id);
+static const struct ubi_vtbl_vtr *get_ivol_vtr(const struct ubi_info *ubi,
+ int vol_id);
const struct ubi_vtbl_vtr *ubi_vtbl_get_vtr(const struct ubi_info *ubi,
int vol_id)
@@ -237,7 +237,7 @@
static void __exit free_volume_info(const struct ubi_info *ubi);
-void __init init_ivols(struct ubi_info *ubi);
+static void __init init_ivols(struct ubi_info *ubi);
int __init ubi_vtbl_init_scan(struct ubi_info *ubi, struct ubi_scan_info *si)
{
@@ -778,7 +778,7 @@
* This function initializes information about internal UBI volumes. This
* information is not stored on flash but instead, is kept only in RAM.
*/
-void __init init_ivols(struct ubi_info *ubi)
+static void __init init_ivols(struct ubi_info *ubi)
{
struct ubi_vtbl_vtr *vtr;
struct ubi_vtbl_info *vtbl = ubi->vtbl;
@@ -818,8 +818,8 @@
* This function returns a pointer to the volume tabe record. The @vol_id must
* be correct.
*/
-const struct ubi_vtbl_vtr *get_ivol_vtr(const struct ubi_info *ubi,
- int vol_id)
+static const struct ubi_vtbl_vtr *get_ivol_vtr(const struct ubi_info *ubi,
+ int vol_id)
{
ubi_assert(ubi_is_ivol(vol_id));
return >vtbl->ivol_vtrs[vol_id - UBI_INTERNAL_VOL_START];
-
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/
[-mm patch] make usbvision_rvfree() static
On Thu, Dec 28, 2006 at 02:42:37AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-rc1-mm1:
>...
> git-dvb.patch
>...
> git trees
>...
usbvision_rvfree() can now become static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.20-rc2-mm1/drivers/media/video/usbvision/usbvision.h.old
2006-12-29 01:44:37.0 +0100
+++ linux-2.6.20-rc2-mm1/drivers/media/video/usbvision/usbvision.h
2006-12-29 01:44:43.0 +0100
@@ -486,7 +486,6 @@
void call_i2c_clients(struct usb_usbvision *usbvision, unsigned int cmd,void
*arg);
/* defined in usbvision-core.c */
-void usbvision_rvfree(void *mem, unsigned long size);
int usbvision_read_reg(struct usb_usbvision *usbvision, unsigned char reg);
int usbvision_write_reg(struct usb_usbvision *usbvision, unsigned char reg,
unsigned char value);
--- linux-2.6.20-rc2-mm1/drivers/media/video/usbvision/usbvision-core.c.old
2006-12-29 01:44:50.0 +0100
+++ linux-2.6.20-rc2-mm1/drivers/media/video/usbvision/usbvision-core.c
2006-12-29 01:44:59.0 +0100
@@ -139,7 +139,7 @@
return mem;
}
-void usbvision_rvfree(void *mem, unsigned long size)
+static void usbvision_rvfree(void *mem, unsigned long size)
{
unsigned long adr;
-
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/
[-mm patch] infiniband/ulp/ipoib/ipoib_cm.c: make functions static
On Thu, Dec 28, 2006 at 02:42:37AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-rc1-mm1:
>...
> git-infiniband.patch
>...
> git trees
>...
This patch makes some needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
--- linux-2.6.20-rc2-mm1/drivers/infiniband/ulp/ipoib/ipoib_cm.c.old
2006-12-29 01:40:17.0 +0100
+++ linux-2.6.20-rc2-mm1/drivers/infiniband/ulp/ipoib/ipoib_cm.c
2006-12-29 01:43:22.0 +0100
@@ -56,7 +56,8 @@
u32 remote_mtu;
};
-int ipoib_cm_tx_handler(struct ib_cm_id *cm_id, struct ib_cm_event *event);
+static int ipoib_cm_tx_handler(struct ib_cm_id *cm_id,
+ struct ib_cm_event *event);
static void ipoib_cm_dma_unmap_rx(struct ipoib_dev_priv *priv,
dma_addr_t mapping[IPOIB_CM_RX_SG])
@@ -265,7 +266,8 @@
return ret;
}
-int ipoib_cm_rx_handler(struct ib_cm_id *cm_id, struct ib_cm_event *event)
+static int ipoib_cm_rx_handler(struct ib_cm_id *cm_id,
+ struct ib_cm_event *event)
{
struct ipoib_cm_rx *p;
struct ipoib_dev_priv *priv;
@@ -396,7 +398,7 @@
"for buf %d\n", wr_id);
}
-void ipoib_cm_rx_completion(struct ib_cq *cq, void *dev_ptr)
+static void ipoib_cm_rx_completion(struct ib_cq *cq, void *dev_ptr)
{
struct net_device *dev = (struct net_device *) dev_ptr;
struct ipoib_dev_priv *priv = netdev_priv(dev);
@@ -550,7 +552,7 @@
spin_unlock_irqrestore(>tx_lock, flags);
}
-void ipoib_cm_tx_completion(struct ib_cq *cq, void *tx_ptr)
+static void ipoib_cm_tx_completion(struct ib_cq *cq, void *tx_ptr)
{
struct ipoib_cm_tx *tx = tx_ptr;
int n, i;
@@ -768,7 +770,8 @@
return 0;
}
-int ipoib_cm_tx_init(struct ipoib_cm_tx *p, u32 qpn, struct ib_sa_path_rec
*pathrec)
+static int ipoib_cm_tx_init(struct ipoib_cm_tx *p, u32 qpn,
+ struct ib_sa_path_rec *pathrec)
{
struct ipoib_dev_priv *priv = netdev_priv(p->dev);
int ret;
@@ -841,7 +844,7 @@
return ret;
}
-void ipoib_cm_tx_destroy(struct ipoib_cm_tx *p)
+static void ipoib_cm_tx_destroy(struct ipoib_cm_tx *p)
{
struct ipoib_dev_priv *priv = netdev_priv(p->dev);
struct ipoib_tx_buf *tx_req;
@@ -875,7 +878,8 @@
kfree(p);
}
-int ipoib_cm_tx_handler(struct ib_cm_id *cm_id, struct ib_cm_event *event)
+static int ipoib_cm_tx_handler(struct ib_cm_id *cm_id,
+ struct ib_cm_event *event)
{
struct ipoib_cm_tx *tx = cm_id->context;
struct ipoib_dev_priv *priv = netdev_priv(tx->dev);
@@ -960,7 +964,7 @@
}
}
-void ipoib_cm_tx_start(struct work_struct *work)
+static void ipoib_cm_tx_start(struct work_struct *work)
{
struct ipoib_dev_priv *priv =
container_of(work, struct ipoib_dev_priv, cm.start_task);
@@ -1003,7 +1007,7 @@
spin_unlock_irqrestore(>tx_lock, flags);
}
-void ipoib_cm_tx_reap(struct work_struct *work)
+static void ipoib_cm_tx_reap(struct work_struct *work)
{
struct ipoib_dev_priv *priv =
container_of(work, struct ipoib_dev_priv, cm.reap_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: 2.6.19 file content corruption on ext3
On Thu, 28 Dec 2006 17:38:38 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]> wrote: > in > the hope that somebody else is working on this corruption issue and is > interested.. What corruption issue? ;) I'm finding that the corruption happens trivially with your test app, but apparently doesn't happen at all with ext2 or ext3, data=writeback. Maybe it will happen with increased rarity, but the difference is quite stark. Removing the err = walk_page_buffers(handle, page_bufs, 0, PAGE_CACHE_SIZE, NULL, journal_dirty_data_fn); from ext3_ordered_writepage() fixes things up. The things which journal_submit_data_buffers() does after dropping all the locks are ... disturbing - I don't think we have sufficient tests in there to ensure that the buffer is still where we think it is after we retake locks (they're slippery little buggers). But that wouldn't explain it anyway. It's inefficient that journal_dirty_data() will put these locked, clean buffers onto BJ_SyncData instead of BJ_Locked, but journal_submit_data_buffers() seems to dtrt with them. So no theory yet. Maybe ext3 is just altering timing. But the difference is really large.. Disabling all the WB_SYNC_NONE stuff and making everything go synchronous everywhere has no effect. Disabling bdi_write_congested() has no effect. - 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.19 file content corruption on ext3
Btw,
much cleaned-up page tracing patch here, in case anybody cares (and
"test.c" attached, although I don't think it changed since last time).
The test.c output is a bit hard to read at times, since it will give
offsets in bytes as hex (ie "00a77664" means page frame 0a77, and byte
664h within that page), while the kernel output is obvioiusly the page
indexes (but the page fault _addresses_ can contain information about the
exact byte in a page, so you can match them up when some kernel event is
related to a page fault).
So both forms are necessary/logical, but it means that to match things up,
you often need to ignore the last three hex digits of the address that
"test.c" outputs.
This one also adds traces for the tags and the writeback activity, but
since I'm going out for birthday dinner, I won't have time to try to
actually analyse the trace I have.. Which is why I'm sending it out, in
the hope that somebody else is working on this corruption issue and is
interested..
Linus
diff --git a/fs/buffer.c b/fs/buffer.c
index 263f88e..f5e132a 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -722,6 +722,7 @@ int __set_page_dirty_buffers(struct page *page)
set_buffer_dirty(bh);
bh = bh->b_this_page;
} while (bh != head);
+ PAGE_TRACE(page, "dirtied buffers");
}
spin_unlock(>private_lock);
@@ -734,6 +735,7 @@ int __set_page_dirty_buffers(struct page *page)
__inc_zone_page_state(page, NR_FILE_DIRTY);
task_io_account_write(PAGE_CACHE_SIZE);
}
+ PAGE_TRACE(page, "setting TAG_DIRTY");
radix_tree_tag_set(>page_tree,
page_index(page), PAGECACHE_TAG_DIRTY);
}
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 350878a..0cf3dce 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -91,6 +91,14 @@
#define PG_nosave_free 18 /* Used for system suspend/resume */
#define PG_buddy 19 /* Page is free, on buddy lists */
+#define SetPageInteresting(page) set_bit(PG_arch_1, &(page)->flags)
+#define PageInteresting(page) test_bit(PG_arch_1, &(page)->flags)
+
+#define PAGE_TRACE(page, msg, arg...) do {
\
+ if (PageInteresting(page))
\
+ printk(KERN_DEBUG "PG %08lx: %s:%d " msg "\n",
\
+ (page)->index, __FILE__, __LINE__ ,##arg );
\
+} while (0)
#if (BITS_PER_LONG > 32)
/*
@@ -183,32 +191,38 @@ static inline void SetPageUptodate(struct page *page)
#define PageWriteback(page)test_bit(PG_writeback, &(page)->flags)
#define SetPageWriteback(page) \
do {\
- if (!test_and_set_bit(PG_writeback, \
- &(page)->flags))\
+ if (!test_and_set_bit(PG_writeback, &(page)->flags)) { \
+ PAGE_TRACE(page, "set writeback"); \
inc_zone_page_state(page, NR_WRITEBACK);\
+ } \
} while (0)
#define TestSetPageWriteback(page) \
({ \
int ret;\
ret = test_and_set_bit(PG_writeback,\
&(page)->flags);\
- if (!ret) \
+ if (!ret) { \
+ PAGE_TRACE(page, "set writeback"); \
inc_zone_page_state(page, NR_WRITEBACK);\
+ } \
ret;\
})
#define ClearPageWriteback(page) \
do {\
- if (test_and_clear_bit(PG_writeback,\
- &(page)->flags))\
+ if (test_and_clear_bit(PG_writeback, &(page)->flags)) { \
+ PAGE_TRACE(page, "end writeback"); \
dec_zone_page_state(page, NR_WRITEBACK);\
+ } \
} while (0)
#define TestClearPageWriteback(page) \
({
Re: 2.6.20-rc2: known unfixed regressions
Adrian Bunk <[EMAIL PROTECTED]> wrote: > This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19. Add that on SPARC64 boot fails due to missing /dev/root. Vanilla 2.6.19 and 2.6.19.1 work fine, before 2.6.20-rc1 it broke. I checked the initrds for both versions, the only difference "diff -Nur" finds between the unpacked initrds are the modules themselves (obviously). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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]: fake numa for x86_64 machines with big IO hole.
This patch resolves the issue of running with numa=fake=X on kernel
command line on x86_64 machines that have big IO hole. While
calculating the size of each node now we look at the total hole size in
that range. Previously there were nodes that only had IO holes in them
causing kernel boot problems. We now use the NODE_MIN_SIZE (64MB) as
the minimum size of memory that any node must have. We reduce the
number of allocated nodes if the number of nodes specified on kernel
command line results in any node getting memory smaller than
NODE_MIN_SIZE. This change allows the extra memory to be incremented in
NODE_MIN_SIZE granule and uniformly distribute among as many nodes
(called big nodes) as possible.
Signed-off-by: David Rientjes <[EMAIL PROTECTED]>
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
Signed-off-by: Rohit Seth <[EMAIL PROTECTED]>
--- linux-2.6.20-rc1-mm1.org/include/asm-x86_64/mmzone.h2006-12-28
16:04:19.0 -0800
+++ linux-2.6.20-rc1-mm1/include/asm-x86_64/mmzone.h2006-12-28
16:00:17.0 -0800
@@ -47,5 +47,10 @@ static inline __attribute__((pure)) int
extern int pfn_valid(unsigned long pfn);
#endif
+#ifdef CONFIG_NUMA_EMU
+#define NODE_MIN_SIZE (64*1024*1024)
+#define NODE_MIN_HASH_MASK (~(NODE_MIN_SIZE - 1ul))
+#endif
+
#endif
#endif
--- linux-2.6.20-rc1-mm1.org/include/asm-x86_64/e820.h 2006-12-28
16:04:19.0 -0800
+++ linux-2.6.20-rc1-mm1/include/asm-x86_64/e820.h 2006-12-28
15:59:19.0 -0800
@@ -46,6 +46,7 @@ extern void e820_mark_nosave_regions(voi
extern void e820_print_map(char *who);
extern int e820_any_mapped(unsigned long start, unsigned long end, unsigned
type);
extern int e820_all_mapped(unsigned long start, unsigned long end, unsigned
type);
+extern unsigned long e820_hole_size(unsigned long start, unsigned long end);
extern void e820_setup_gap(void);
extern void e820_register_active_regions(int nid,
--- linux-2.6.20-rc1-mm1.org/arch/x86_64/mm/numa.c 2006-12-28
16:04:19.0 -0800
+++ linux-2.6.20-rc1-mm1/arch/x86_64/mm/numa.c 2006-12-28 16:02:07.0
-0800
@@ -275,31 +275,111 @@ void __init numa_init_array(void)
}
#ifdef CONFIG_NUMA_EMU
+/* Numa emulation */
int numa_fake __initdata = 0;
-/* Numa emulation */
+/*
+ * This function is used to find out if the start and end correspond to
+ * different zones.
+ */
+int zone_cross_over(unsigned long start, unsigned long end)
+{
+ if ((start < (MAX_DMA32_PFN << PAGE_SHIFT)) &&
+ (end >= (MAX_DMA32_PFN << PAGE_SHIFT)))
+ return 1;
+ return 0;
+}
+
static int __init numa_emulation(unsigned long start_pfn, unsigned long
end_pfn)
{
- int i;
+ int i, big;
struct bootnode nodes[MAX_NUMNODES];
- unsigned long sz = ((end_pfn - start_pfn)< 1) {
- unsigned long x = 1;
- while ((x << 1) < sz)
- x <<= 1;
- if (x < sz/2)
- printk(KERN_ERR "Numa emulation unbalanced. Complain to
maintainer\n");
- sz = x;
- }
+ old_sz = sz;
+ /*
+* Round down to the nearest NODE_MIN_SIZE.
+*/
+ sz &= NODE_MIN_HASH_MASK;
+
+ /*
+* We ensure that each node is at least 64MB big. Smaller than this
+* size can cause VM hiccups.
+*/
+ if (sz == 0) {
+ printk(KERN_INFO"Not enough memory for %d nodes. Reducing "
+ "the number of nodes\n", numa_fake);
+ numa_fake = (max_addr - start - hole_size) / NODE_MIN_SIZE;
+ printk(KERN_INFO"Number of fake nodes will be = %d\n",
numa_fake);
+ sz = NODE_MIN_SIZE;
+ }
+ /*
+* Find out how many nodes can get an extra NODE_MIN_SIZE granule.
+* This logic ensures the extra memory gets distributed among as many
+* nodes as possible (as compared to one single node getting all that
+* extra memory.
+*/
+ big = ((old_sz - sz) * numa_fake) / NODE_MIN_SIZE;
+ printk(KERN_INFO"Fake node Size: %luMB hole_size: %luMB big nodes:
%d\n",
+ (sz >> 20), (hole_size >> 20), big);
memset(,0,sizeof(nodes));
+ end = start;
for (i = 0; i < numa_fake; i++) {
- nodes[i].start = (start_pfn<= max_addr) {
+ numa_fake = i - 1;
+ break;
+ }
+ start = nodes[i].start = end;
+ /*
+* Final node can have all the remaining memory.
+*/
if (i == numa_fake-1)
- sz = (end_pfn<= max_addr)
+ break;
+ }
+ /*
+* Look at the next node to make sure there is some real memory
+* to map. Bad things happen when the only memory present
+* in a zone on a fake node is IO
Re: [PATCH] remove 556 unneeded #includes of sched.h
On Fri, 29 Dec 2006 01:37:39 +0100 (CET) Tim Schmielau wrote: > On Thu, 28 Dec 2006, Randy Dunlap wrote: > > On Thu, 28 Dec 2006 21:48:30 + Russell King wrote: > > > On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote: > > > > On Thu, 28 Dec 2006 21:34:38 + Russell King wrote: > > > > > The whole "all*config" idea on ARM is utterly useless - you can _not_ > > > > > get build coverage that way. > > > > > > > > Uh, can J. Random Developer submit patches to the ARM build system > > > > for testing? > > > > > > Given that it takes about 8 to 12 hours to do a build cycle, that's > > > not practical. The only real solution is for us to accept that > > > breakage will occur (and be prepared to keep a steady stream of > > > fixes heading into Linus' tree - which has been ruled out by Linus) > > > or J. Random Developer has to build a set of affected ARM defconfigs > > > themselves. > > > > I guess I don't get it. Isn't that what we just went thru > > with the struct nightmare^W work_struct changes? > > But these header file changes are much simpler and more obvious... > > Well, I think it's practical to build all arm configs yourself. I'll do > that for my sched.h #include changes. It's been less that two hours since > I started the builds on two cpus and I already got 35 out of 59 configs. Yep, right, if I already had all of that cross-build stuff setup, it wouldn't be a big deal. But getting it all setup is a big deal (to me). > It's just that one has to be aware of it. Before Russell's post the > situation on arm seemed so confusing to me that I thought I'd just > compile allnoconfig, defconfig, allmodconfig and allyesconfig and let the > arm people figure out the rest. --- ~Randy - 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] remove 556 unneeded #includes of sched.h
On Thu, 28 Dec 2006, Randy Dunlap wrote: > On Thu, 28 Dec 2006 21:48:30 + Russell King wrote: > > On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote: > > > On Thu, 28 Dec 2006 21:34:38 + Russell King wrote: > > > > The whole "all*config" idea on ARM is utterly useless - you can _not_ > > > > get build coverage that way. > > > > > > Uh, can J. Random Developer submit patches to the ARM build system > > > for testing? > > > > Given that it takes about 8 to 12 hours to do a build cycle, that's > > not practical. The only real solution is for us to accept that > > breakage will occur (and be prepared to keep a steady stream of > > fixes heading into Linus' tree - which has been ruled out by Linus) > > or J. Random Developer has to build a set of affected ARM defconfigs > > themselves. > > I guess I don't get it. Isn't that what we just went thru > with the struct nightmare^W work_struct changes? > But these header file changes are much simpler and more obvious... Well, I think it's practical to build all arm configs yourself. I'll do that for my sched.h #include changes. It's been less that two hours since I started the builds on two cpus and I already got 35 out of 59 configs. It's just that one has to be aware of it. Before Russell's post the situation on arm seemed so confusing to me that I thought I'd just compile allnoconfig, defconfig, allmodconfig and allyesconfig and let the arm people figure out the rest. Tim - 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/
2.6.20-rc2-mm1: i386-idle-notifier again
On Thu, Dec 28, 2006 at 02:42:37AM -0800, Andrew Morton wrote: >... > Changes since 2.6.20-rc1-mm1: >... > +add-i386-idle-notifier-take-3.patch >... > x86/x86_64 updates >... As already said: - merges infrastructure without any users (the corresponding x86_64 code is now merged and bloating the kernel unused for nearly one year) - the planned user (perfmon) doesn't use the EXPORT_SYMBOL's that will bloat the kernel even if the code using this infrastructure will ever be merged Let's either get the user into -mm, too, or drop the infrastructure on all architectures until it's actually used. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.20-rc1 1/6] GPIO core
> Good afternoon. :)
Good after-midnight :-).
> > > +Identifying GPIOs
> > > +-
> > > +GPIOs are identified by unsigned integers in the range 0..MAX_INT. That
> > > +reserves "negative" numbers for other purposes like marking signals as
> > > +"not available on this board", or indicating faults.
> > > +
> > > +Platforms define how they use those integers, and usually #define symbols
> > > +for the GPIO lines so that board-specific setup code directly corresponds
> > > +to the relevant schematics. In contrast, drivers should only use GPIO
> >
> > Perhaps these should not be integers, then?
>
> Thing is, the platforms **DO** identify them as integers.
> Go through OMAP, PXA, StrongARM chip docs ... what you see is
> references to GPIO numbers, 0..MAX, and oh by the way those map to
> bit offsets within gpio controller banks.
Well. when you see (something) = gpio_number + 5 ... you most likely
have an error. That means that they are close to integers, but not
quite. I'd use
typedef int gpio_t;
...it also serves as a nice documentation.
> When they don't identify them as integers, as with AT91, AVR32, and
> S3C -- all of which present GPIOs as a lettered bank plus a bit offset
> within that bank, isn't that structure familiar -- then the Linux
> platform support already #defines them as integers. The naming matches
Great, except that mechanism should not #define them but "enum gpio {
} " them...
> > inside, allows you to typecheck, and allows expansion in (unlikely) case
> > where
> > more than int is needed? ...hotpluggable gpio pins?
>
> If some system wants that kind of infrastructure, it can easily
> implement it behind this API. There's the IDR infrastructure, for
No, that's a wrong way. I want you to admit that gpio numbers are
opaque cookies noone should look at, and use (something like)
gpio_t... so that we can teach sparse to check them.
> > > +The get/set calls have no error returns because "invalid GPIO" should
> > > have
> > > +been reported earlier in gpio_set_direction(). However, note that not
> > > all
> > > +platforms can read the value of output pins; those that can't should
> > > always
> > > +return zero. Also, these calls will be ignored for GPIOs that can't
> > > safely
> > > +be accessed without sleeping (see below).
> >
> > 'Silently ignored' is ugly. BUG() would be okay there.
>
> The reason for "silently ignored" is that we really don't want to be
> cluttering up the code (source or object) with logic to test for this
> kind of "can't happen" failure, especially since there's not going to
> be any way to _resolve_ such failures cleanly.
You may not want to clutter up code for one arch, but for some of them
maybe it is okay and welcome. Please do not document "silently
ignored" into API.
> And per Linus' rule about BUG(), "silently ignored" is clearly better
> than needlessly stopping the whole system.
You are perverting what Linus said. "Do not bother detecting errors"
is not what he had in mind.. but perhaps it should be WARN() not
BUG().
> > > +Those return either the corresponding number in the other namespace, or
> > > +else a negative errno code if the mapping can't be done. (For example,
> > > +some GPIOs can't used as IRQs.) It is an unchecked error to use a GPIO
> > > +number that hasn't been marked as an input using gpio_set_direction(), or
> >
> > It should be valid to do irqs on outputs,
>
> Good point -- it _might_ be valid to do that, on some platforms.
> Such things have been used as a software IRQ trigger, which can
> make bootstrapping some things easier.
>
> That's not incompatible with it being an error for portable code to
I believe your text suggests it _is_ incompatible. Plus that seems to
mean that architecture must not check for that error...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove 556 unneeded #includes of sched.h
On Thu, 28 Dec 2006 21:48:30 + Russell King wrote: > On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote: > > On Thu, 28 Dec 2006 21:34:38 + Russell King wrote: > > > The whole "all*config" idea on ARM is utterly useless - you can _not_ > > > get build coverage that way. > > > > Uh, can J. Random Developer submit patches to the ARM build system > > for testing? > > Given that it takes about 8 to 12 hours to do a build cycle, that's > not practical. The only real solution is for us to accept that > breakage will occur (and be prepared to keep a steady stream of > fixes heading into Linus' tree - which has been ruled out by Linus) > or J. Random Developer has to build a set of affected ARM defconfigs > themselves. I guess I don't get it. Isn't that what we just went thru with the struct nightmare^W work_struct changes? But these header file changes are much simpler and more obvious... > Or alternatively the guy who's running kautobuild needs an amount of > rather powerful donated hardware to stubstantially increase it's > throughput. > > Or cross-gcc needs to be optimised to compile faster. > > I don't see any of the above happening, so... --- ~Randy - 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] Use correct macros in raid code, not raw asm
On Thu, 2006-12-28 at 15:56 -0800, Andrew Morton wrote:
> On Fri, 29 Dec 2006 10:34:21 +1100
> Rusty Russell <[EMAIL PROTECTED]> wrote:
>
> > This make sure it's paravirtualized correctly when CONFIG_PARAVIRT=y.
> >
> > Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
> >
> > diff -r 4ff048622391 drivers/md/raid6x86.h
> > --- a/drivers/md/raid6x86.h Thu Dec 28 16:52:54 2006 +1100
> > +++ b/drivers/md/raid6x86.h Fri Dec 29 10:09:38 2006 +1100
> > @@ -75,13 +75,14 @@ static inline unsigned long raid6_get_fp
> > unsigned long cr0;
> >
> > preempt_disable();
> > - asm volatile("mov %%cr0,%0 ; clts" : "=r" (cr0));
> > + cr0 = read_cr0();
> > + clts();
> > return cr0;
> > }
> >
> > static inline void raid6_put_fpu(unsigned long cr0)
> > {
> > - asm volatile("mov %0,%%cr0" : : "r" (cr0));
> > + write_cr0(cr0);
> > preempt_enable();
> > }
> >
>
> Perhaps we also need:
>
> ---
> a/drivers/md/raid6x86.h~use-correct-macros-in-raid-code-not-raw-asm-include
> +++ a/drivers/md/raid6x86.h
> @@ -21,6 +21,8 @@
>
> #if defined(__i386__) || defined(__x86_64__)
>
> +#include
> +
The code looks like it's designed to be included from userspace for
testing; as it compiles without this include (and has no other
includes), I chose not to add it.
Linus makes a good point, but someone who actually knows the code
should, y'know, test it and stuff...
Rusty.
-
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.19 file content corruption on ext3
On Thu, 28 Dec 2006, Linus Torvalds wrote: > Ok, > with the ugly trace capture patch, I've actually captured this corruption > in action, I think. > > I did a full trace of all pages involved in one run, and picked one > corruption at random: > > Chunk 14465 corrupted (0-75) (01423fb4-01423fff) > Expected 129, got 0 > Written as (5126)9509(15017) > > That's the first 76 bytes of a chunk missing, and it's the last 76 bytes > on a page. It's page index 01423 in the mapped file, and bytes fb4-fff > within that file. > > There were four chunks written to that page: > > Writing chunk 14463/15800 (15%) (0142344c) (1) > Writing chunk 14462/15800 (30%) (01422e98) (2) (overflows into 1423) > Writing chunk 14464/15800 (32%) (01423a00) (3) > Writing chunk 14465/15800 (60%) (01423fb4) (4) <--- LOST! > > and the other three chunks checked out all right. > > And here's the annotated trace as it concerns that page: > > - here we write the first chunk to the page: > ** (1) do_no_page: mapping index 1423 at b7d1f44c (write) > ** Setting page 1423 dirty > > - something flushes it out to disk: > ** cpd_for_io: index 1423 > ** cleaning index 1423 at b7d1f000 > > - here we write the second chunk (which was split over the previous page >and the interesting one): > ** (2) Setting page 1422 dirty > ** (2) Setting page 1423 dirty > > - and here we do a cleaning event > ** cpd_for_io: index 1423 > ** cleaning index 1423 at b7d1f000 > > - here we write the third chunk: > ** (3) Setting page 1423 dirty > > - here we write the fourth chunk: > ** (4) NO DIRTY EVENT > > - and a third flush to disk: > ** cpd_for_io: index 1423 > ** cleaning index 1423 at b7d1f000 > > - here we unmap and flush: > ** Unmapped index 1423 at b7d1f000 > ** Removing index 1423 from page cache > > - here we remap to check: > ** do_no_page: mapping index 1423 at b7d1f000 (read) > ** Unmapped index 1423 at b7d1f000 > > - and finally, here I remove the file after the run: > ** Removing index 1423 from page cache > > Now, the important thing to see here is: > > - the missing write did not have a "Setting page 1423 dirty" event >associated with it. > > - but I can _see_ where the actual dirty event would be happening in the >logs, because I can see the dirty events of the other chunk writes >around it, so I know exactly where that fourth write happens. And >indeed, it _shouldn't_ get a dirty event, because the page is still >dirty from the write of chunk #3 to that page, which _did_ get a dirty >event. > >I can see that, because the testing app writes the log of the pages it >writes, and this is the log around the fourth and final write: > > ... > Writing chunk 5338/15800 (60%) (0076eb48) PFN: 76e/76f > Writing chunk 960/15800 (60%) (00156300)PFN: 156 > Writing chunk 14465/15800 (60%) (01423fb4) < > Writing chunk 8594/15800 (60%) (00bf74a8) PFN: bf7 > Writing chunk 556/15800 (60%) (000c62f0)PFN: c6 > Writing chunk 15190/15800 (60%) (01526678) PFN: 1526 > ... > >and I can match this up with the full log from the kernel, which looks >like this: > > Setting page 076e dirty > Setting page 076f dirty > Setting page 0156 dirty > Setting page 00c6 dirty > Setting page 1526 dirty > >so I know exactly where the missing writes (to our page at pfn 1423, >and the fpn-bf7 page) happened. > > - and the thing is, I can see a "cpd_for_io()" happening AFTER that >fourth write. Quite a long while after, in fact. So all of this looks >very fine indeed. We are not losing any dirty bits. > > - EVEN MORE INTERESTING: write 3 makes it onto disk, and it really uses >the SAME dirty bit as write 4 did (which didn't make it out to disk!). >The event that clears the dirty bit that write 3 did happens AFTER >write 4 has happened! > > So if we're not losing any dirty bits, what's going on? > > I think we have some nasty interaction with the buffer heads. In But are chunks 3 and 4 in separate buffer heads? Sorry could not see it immediately from the output you showed... It is just that there may be a different cause rather than buffer dirty state... A shot in the dark I know but it could perhaps be that a "COW for MAP_PRIVATE" like event happens when the page is dirty already thus the second write never actually makes it to the shared page thus it never gets written out. I am almost certainly totally barking up the wrong tree but I thought it may be worth mentioning just in case there was a slip in the COW logic or page
Re: [PATCH] Use correct macros in raid code, not raw asm
On Fri, 29 Dec 2006 10:34:21 +1100
Rusty Russell <[EMAIL PROTECTED]> wrote:
> This make sure it's paravirtualized correctly when CONFIG_PARAVIRT=y.
>
> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
>
> diff -r 4ff048622391 drivers/md/raid6x86.h
> --- a/drivers/md/raid6x86.h Thu Dec 28 16:52:54 2006 +1100
> +++ b/drivers/md/raid6x86.h Fri Dec 29 10:09:38 2006 +1100
> @@ -75,13 +75,14 @@ static inline unsigned long raid6_get_fp
> unsigned long cr0;
>
> preempt_disable();
> - asm volatile("mov %%cr0,%0 ; clts" : "=r" (cr0));
> + cr0 = read_cr0();
> + clts();
> return cr0;
> }
>
> static inline void raid6_put_fpu(unsigned long cr0)
> {
> - asm volatile("mov %0,%%cr0" : : "r" (cr0));
> + write_cr0(cr0);
> preempt_enable();
> }
>
Perhaps we also need:
--- a/drivers/md/raid6x86.h~use-correct-macros-in-raid-code-not-raw-asm-include
+++ a/drivers/md/raid6x86.h
@@ -21,6 +21,8 @@
#if defined(__i386__) || defined(__x86_64__)
+#include
+
#ifdef __x86_64__
typedef struct {
_
?
-
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.19 file content corruption on ext3
On Thu, 28 Dec 2006, Anton Altaparmakov wrote: > > But are chunks 3 and 4 in separate buffer heads? Sorry could not see it > immediately from the output you showed... No, this is a 4kB filesystem. A single bh per page. > It is just that there may be a different cause rather than buffer dirty > state... Sure. > A shot in the dark I know but it could perhaps be that a "COW for > MAP_PRIVATE" like event happens when the page is dirty already thus the > second write never actually makes it to the shared page thus it never gets > written out. There are no private mappings anywhere, and no forks. Just a single mmap (well, we unmap and remap in order to force the page cache to be invalidated properly with the posix_fadvise() thing, but that's literally the only user). 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: Want comments regarding patch
On Dec 28 2006 19:53, Arjan van de Ven wrote:
>On Thu, 2006-12-28 at 19:41 +0100, Daniel Marjamäki wrote:
>> Hello all!
>>
>> I sent a patch with this content:
>>
>> - for (i = 0; i < MAX_PIRQS; i++)
>> - pirq_entries[i] = -1;
>> + memset(pirq_entries, -1, sizeof(pirq_entries));
>>
>> I'd like to know if you have any comments to this change. It was
>> of course my intention to make the code shorter, simpler and
>> faster.
>
>personally I don't like the new code; memset only takes a byte as
>argument and while it probably is the same, that is now implicit
>behavior and no longer explicit. A reasonably good compiler will
>notice it's the same and generate the best code anyway, so I would
>really really suggest to go for the best readable code, which imo is
>the original code.
Then GCC is not a "reasonably good compiler". Considering
#define MAX 6400
struct foo {
int line[MAX];
};
void bar(struct foo *a) {
int i;
for(i = 0; i < MAX; ++i)
a->line[i] = -1;
}
void baz(struct foo *a) {
__builtin_memset(a->line, -1, sizeof(a->line));
}
`gcc -O3 -c test.c` will generate a classic loop rather than a repz
movsd for bar(). baz() will get a call to an extern memset(),
probably because gcc could not figure out how to make a repz for it
and hence thought it was better to use an external hand-crafted
memset.
-`J'
--
Re: [PATCH] Use correct macros in raid code, not raw asm
On Fri, 29 Dec 2006, Rusty Russell wrote: > > This make sure it's paravirtualized correctly when CONFIG_PARAVIRT=y. Why doesn't this code use "kernel_fpu_begin()" and "kernel_fpu_end()"? The raid6 code is crap, and slower. It does "fsave/frstor" or movaps or other crud, and the thing is, it shouldn't. It should just do kernel_fpu_begin/end(), which does it all right, and avoids saving any state at all unless it's being used by the user RIGHT NOW. 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: [Bug 7505] Linux-2.6.18 fails to boot on AMD64 machine
Could someone please test this?
From: Andrew Morton <[EMAIL PROTECTED]>
Various people have reported machines failing to boot since pci_bus_sem was
switched from a spinlock to an rwsem.
The reason for this is that these people had "ide=" on the kernel commandline,
and ide_setup() can end up calling PCI functions which do
down_read(_bus_sem).
Ard has worked out the call tree:
init/main.c start_kernel
kernel/params.c parse_args("Booting kernel"
kernel/params.c parse_one
drivers/ide/ide.c ide_setup
drivers/ide/ide.c init_ide_data
drivers/ide/ide.cinit_hwif_default
include/asm-i386/ide.hide_default_io_base(index)
drivers/pci/search.c pci_find_device
drivers/pci/search.cpci_find_subsys
down_read(_bus_sem);
down_read() will unconditionally enable interrupts and some early interrupt
(source unknown) comes in and whacks the machine, apparently because the LDT
isn't set up yet.
Fix that by avoiding taking the semaphore in the PCI code in this situation.
Cc: Ard -kwaak- van Breemen <[EMAIL PROTECTED]>
Cc: "Zhang, Yanmin" <[EMAIL PROTECTED]>
Cc: Chuck Ebbert <[EMAIL PROTECTED]>
Cc: Yinghai Lu <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Cc: "Eric W. Biederman" <[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/pci/search.c | 10 ++
1 files changed, 10 insertions(+)
diff -puN drivers/pci/search.c~pci-avoid-taking-pci_bus_sem-early-in-boot
drivers/pci/search.c
--- a/drivers/pci/search.c~pci-avoid-taking-pci_bus_sem-early-in-boot
+++ a/drivers/pci/search.c
@@ -259,6 +259,16 @@ pci_get_subsys(unsigned int vendor, unsi
struct pci_dev *dev;
WARN_ON(in_interrupt());
+
+ /*
+* pci_get_subsys() can be called on the ide_setup() path, super-early
+* in boot. But the down_read() will enable local interrupts, which
+* can cause some machines to crash. So here we detect that situation
+* and bail out early.
+*/
+ if (unlikely(list_empty(pci_devices)))
+ return NULL;
+
down_read(_bus_sem);
n = from ? from->global_list.next : pci_devices.next;
_
-
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] Use correct macros in raid code, not raw asm
This make sure it's paravirtualized correctly when CONFIG_PARAVIRT=y.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r 4ff048622391 drivers/md/raid6x86.h
--- a/drivers/md/raid6x86.h Thu Dec 28 16:52:54 2006 +1100
+++ b/drivers/md/raid6x86.h Fri Dec 29 10:09:38 2006 +1100
@@ -75,13 +75,14 @@ static inline unsigned long raid6_get_fp
unsigned long cr0;
preempt_disable();
- asm volatile("mov %%cr0,%0 ; clts" : "=r" (cr0));
+ cr0 = read_cr0();
+ clts();
return cr0;
}
static inline void raid6_put_fpu(unsigned long cr0)
{
- asm volatile("mov %0,%%cr0" : : "r" (cr0));
+ write_cr0(cr0);
preempt_enable();
}
-
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: moxa serial driver testing
Sergei Organov wrote: > Hi, Jiri! Hi. > I'm so sorry, I don't know what I smoked yesterday, but the latest > version you've sent me does not have this problem anymore! I think I YES! > copied compiled module to modules directory for different kernel and > thus tested old code all the time. BTW, should you tell me that the > ports are now called /dev/ttyMIx instead of /dev/ttyMx, I think I'd ttyM was reserved for isicom, and it caused many warnings in the kernel, when both isicom and mxser were built and loaded. The proper name for mxser is (and ever was) ttyMI -- sorry for not giving you a notice (I didn't realize the change). > notice my mistake earlier. Yes, in fact I didn't test any version where > ports are called /dev/ttyMIx until now! In particular, it means that > maybe some of the recent changes you've made yesterday based on my wrong > reports are not in fact required. I think those with ASYNC_CLOSING test in the isr is the one (but also wakeup spinlock change is requisite to go upstream). > Anyway, the only mxser-specific problem that currently remains for > me and that I didn't see before, is the following: > > # rmmod mxser_new > Trying to free already-free IRQ 58 > Trying to free nonexistent resource <9000-903f> > Trying to free nonexistent resource <8800-8800> Thanks, I'll fix this and let you know. Does this happed every time you try to unload it? thanks, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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.20-rc2: known unfixed regressions
On Thu, Dec 28, 2006 at 03:17:53PM -0800, Linus Torvalds wrote: > > > On Fri, 29 Dec 2006, Adrian Bunk wrote: > > > > In Linus' tree, it currently only depends on EXPERIMENTAL. > > > > It seems commit 009af1ff78bfc30b9a27807dd0207fc32848218a wasn't intended > > for Linus? > > I think we should just remove it. > > It's broken. > > Nobody cares. I agree, that's why I thought I had added a patch in the last PCI queue to you to just disable the config option and was going to rip out the code entirely for the next release. I'll make sure to add the config option patch to the next round of PCI patches to you. 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.20-rc2: known unfixed regressions
On Fri, 29 Dec 2006, Adrian Bunk wrote: > > In Linus' tree, it currently only depends on EXPERIMENTAL. > > It seems commit 009af1ff78bfc30b9a27807dd0207fc32848218a wasn't intended > for Linus? I think we should just remove it. It's broken. Nobody cares. If people want to do concurrent stuff at bootup, it should be the _other_ buses (like USB, IDE or SCSI or anything like that, that actually has operations that can delay) that end up asynchronous. And I think we could have some generic functionality for the drivers themselves to do their probing in parallel. But I think the PCI one was just a mistake. 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.20-rc2: known unfixed regressions
On Thu, Dec 28, 2006 at 02:57:06PM -0800, Greg KH wrote: > On Thu, Dec 28, 2006 at 11:39:09PM +0100, Adrian Bunk wrote: > > > > Subject: PCI_MULTITHREAD_PROBE breakage > > References : http://lkml.org/lkml/2006/12/12/21 > > Submitter : Ben Castricum <[EMAIL PROTECTED]> > > Caused-By : Greg Kroah-Hartman <[EMAIL PROTECTED]> > > commit 009af1ff78bfc30b9a27807dd0207fc32848218a > > Status : known to break many drivers; revert? > > PCI_MULTITHREAD_PROBE is now only able to be enabled if you also enable > CONFIG_BROKEN, so this can be removed from your list. In Linus' tree, it currently only depends on EXPERIMENTAL. It seems commit 009af1ff78bfc30b9a27807dd0207fc32848218a wasn't intended for Linus? > thanks, > > greg k-h cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.19 file content corruption on ext3
On Thu, 28 Dec 2006, David Miller wrote:
>
> What happens when we writeback, to the PTEs?
Not a damn thing.
We clear the PTE's _before_ we even start the write. The writeback does
nothing to them. If the user dirties the page while writeback is in
progress, we'll take the page fault and re-dirty it _again_.
> page_mkclean_file() iterates the VMAs and when it finds a shared
> one it goes:
>
> entry = ptep_clear_flush(vma, address, pte);
> entry = pte_wrprotect(entry);
> entry = pte_mkclean(entry);
>
> and that's fine, but that PTE is still marked writable, and
> I think that's key.
No it's not. It's right there. "pte_wrprotect(entry)". You even copied it
yourself.
> What does the fault path do in this situation?
>
> if (write_access) {
> if (!pte_write(entry))
> return do_wp_page(mm, vma, address,
> pte, pmd, ptl, entry);
So we call "do_wp_page()", and that does everythign right.
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.20-rc2: known unfixed regressions
On Thu, Dec 28, 2006 at 11:39:09PM +0100, Adrian Bunk wrote: > > Subject: PCI_MULTITHREAD_PROBE breakage > References : http://lkml.org/lkml/2006/12/12/21 > Submitter : Ben Castricum <[EMAIL PROTECTED]> > Caused-By : Greg Kroah-Hartman <[EMAIL PROTECTED]> > commit 009af1ff78bfc30b9a27807dd0207fc32848218a > Status : known to break many drivers; revert? PCI_MULTITHREAD_PROBE is now only able to be enabled if you also enable CONFIG_BROKEN, so this can be removed from your list. 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: [PATCHSET 1][PATCH 0/6] Filesystem AIO read/write
On Thu, 28 Dec 2006 13:53:08 +0530 Suparna Bhattacharya <[EMAIL PROTECTED]> wrote: > This patchset implements changes to make filesystem AIO read > and write asynchronous for the non O_DIRECT case. I did s/lock_page_slow/lock_page_blocking/g then merged all these into -mm, 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: 2.6.19 file content corruption on ext3
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Thu, 28 Dec 2006 14:37:37 -0800 (PST)
> So if we're not losing any dirty bits, what's going on?
What happens when we writeback, to the PTEs?
page_mkclean_file() iterates the VMAs and when it finds a shared
one it goes:
entry = ptep_clear_flush(vma, address, pte);
entry = pte_wrprotect(entry);
entry = pte_mkclean(entry);
and that's fine, but that PTE is still marked writable, and
I think that's key.
What does the fault path do in this situation?
if (write_access) {
if (!pte_write(entry))
return do_wp_page(mm, vma, address,
pte, pmd, ptl, entry);
entry = pte_mkdirty(entry);
}
It does nothing to update the page dirty state, because it's
writable, it just sets the PTE dirty bit and that's it. Should
it be setting the page dirty here for SHARED cases?
So until vmscan actually unmaps the PTE completely, we have this
window in which the application can write to the PTE and the
page dirty state doesn't get updated.
Perhaps something later cleans up after this, f.e. by rechecking the
PTE dirty bit at the end of I/O or when vmscan unmaps the page.
I guess that should handle things, but the above logic definitely
stood out to me.
-
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: scheduling while atomic, new libata code
On 12/28/06, Arnd Bergmann <[EMAIL PROTECTED]> wrote: On Thursday 28 December 2006 03:16, Jon Smirl wrote: > BUG: scheduling while atomic: hald-addon-stor/0x2000/5078 > [] __sched_text_start+0x5f9/0xb00 > [] net_rx_action+0xb3/0x180 > [] __do_softirq+0x72/0xe0 > [] do_IRQ+0x45/0x80 This doesn't seem to be related to libata at all. Like your first trace, you call schedule from a softirq context, which is always atomic. The only place where I can imagine this happening is the local_irq_enable() in there, which can be defined in different ways. Are you running with paravirt_ops, CONFIG_TRACE_IRQFLAGS_SUPPORT and/or kernel preemption enabled? Forgot this, # CONFIG_PARAVIRT is not set CPU is 2.8Mhz P4, no virtualization capabilities. Arnd <>< -- Jon Smirl [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: BUG: scheduling while atomic, new libata code
On 12/28/06, Arnd Bergmann <[EMAIL PROTECTED]> wrote: On Thursday 28 December 2006 03:16, Jon Smirl wrote: > BUG: scheduling while atomic: hald-addon-stor/0x2000/5078 > [] __sched_text_start+0x5f9/0xb00 > [] net_rx_action+0xb3/0x180 > [] __do_softirq+0x72/0xe0 > [] do_IRQ+0x45/0x80 This doesn't seem to be related to libata at all. Like your first trace, you call schedule from a softirq context, which is always atomic. The only place where I can imagine this happening is the local_irq_enable() in there, which can be defined in different ways. Are you running with paravirt_ops, CONFIG_TRACE_IRQFLAGS_SUPPORT and/or kernel preemption enabled? This is set, although I don't recall setting it. CONFIG_TRACE_IRQFLAGS_SUPPORT=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y Another odd thing I'm doing is simultaneously using a wired and wireless net at the same time. Arnd <>< -- Jon Smirl [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: [FSAIO][PATCH 3/8] Routines to initialize and test a wait bit key
On Thu, 28 Dec 2006 14:09:00 +0530
Suparna Bhattacharya <[EMAIL PROTECTED]> wrote:
> +#define init_wait_bit_key(waitbit, word, bit)
> \
> + do {\
> + (waitbit)->key.flags = word;\
> + (waitbit)->key.bit_nr = bit;\
> + } while (0)
> +
> +#define init_wait_bit_task(waitbit, tsk) \
> + do {\
> + (waitbit)->wait.private = tsk; \
> + (waitbit)->wait.func = wake_bit_function; \
> + INIT_LIST_HEAD(&(waitbit)->wait.task_list); \
> + } while (0)
Can we convert these to C functions (inlined or regular, probably inlined
would be better)?
-
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/
2.6.20-rc2: known unfixed regressions
This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: PCI_MULTITHREAD_PROBE breakage References : http://lkml.org/lkml/2006/12/12/21 Submitter : Ben Castricum <[EMAIL PROTECTED]> Caused-By : Greg Kroah-Hartman <[EMAIL PROTECTED]> commit 009af1ff78bfc30b9a27807dd0207fc32848218a Status : known to break many drivers; revert? Subject: Acer Extensa 3002 WLMi: 'shutdown -h now' reboots the system References : http://lkml.org/lkml/2006/12/25/40 Submitter : Berthold Cogel <[EMAIL PROTECTED]> Status : unknown Subject: i386: Oops in __find_get_block() References : http://lkml.org/lkml/2006/12/16/138 Submitter : Ben Collins <[EMAIL PROTECTED]> Daniel Holbach <[EMAIL PROTECTED]> Status : unknown Subject: ftp: get or put stops during file-transfer References : http://lkml.org/lkml/2006/12/16/174 Submitter : Komuro <[EMAIL PROTECTED]> Status : unknown Subject: forcedeth.c 0.59: problem with sideband managment References : http://bugzilla.kernel.org/show_bug.cgi?id=7684 Submitter : Michael Reske <[EMAIL PROTECTED]> Handled-By : Ayaz Abdulla <[EMAIL PROTECTED]> Status : problem is being debugged Subject: x86_64 boot failure: "IO-APIC + timer doesn't work" References : http://lkml.org/lkml/2006/12/16/101 Submitter : Tobias Diedrich <[EMAIL PROTECTED]> Caused-By : Andi Kleen <[EMAIL PROTECTED]> commit b026872601976f666bae77b609dc490d1834bf77 Handled-By : Yinghai Lu <[EMAIL PROTECTED]> "Eric W. Biederman" <[EMAIL PROTECTED]> Status : problem is being debugged Subject: kernel panics on boot (libata-sff) References : http://lkml.org/lkml/2006/12/3/99 http://lkml.org/lkml/2006/12/14/153 http://lkml.org/lkml/2006/12/24/33 Submitter : Alessandro Suardi <[EMAIL PROTECTED]> Caused-By : Alan Cox <[EMAIL PROTECTED]> commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f Handled-By : Alan Cox <[EMAIL PROTECTED]> Steve Wise <[EMAIL PROTECTED]> Alessandro Suardi <[EMAIL PROTECTED]> Status : people are working on a fix - 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] mm: fix page_mkclean_one
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Thu, 28 Dec 2006 12:14:31 -0800 (PST) > I get corruption - but the whole point is that it's very much pdflush that > should be writing these pages out. I think what might be happening is that pdflush writes them out fine, however we don't trap writes by the application _during_ that writeout. These corruptions look exactly as if: 1) pdflush begins writeback of page X 2) page goes to disk 3) application writes a chunk to the page 4) pdflush et al. think the page is clean, so it gets tossed, losing the writes done in #3 So there's a missing PTE change in there, so that we never get proper re-dirtying of the page if the application tries to write to the page during the writeback. It's something that will only occur with writeback and MAP_SHARED writable access to the file pages. That's why we never see this with normal filesystem writes, since those explicitly manage the page dirty state. I think the dirty balancing logic etc. isn't where the problems are, to me it's a PTE state update issue for sure. - 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.19 file content corruption on ext3
Ok, with the ugly trace capture patch, I've actually captured this corruption in action, I think. I did a full trace of all pages involved in one run, and picked one corruption at random: Chunk 14465 corrupted (0-75) (01423fb4-01423fff) Expected 129, got 0 Written as (5126)9509(15017) That's the first 76 bytes of a chunk missing, and it's the last 76 bytes on a page. It's page index 01423 in the mapped file, and bytes fb4-fff within that file. There were four chunks written to that page: Writing chunk 14463/15800 (15%) (0142344c) (1) Writing chunk 14462/15800 (30%) (01422e98) (2) (overflows into 1423) Writing chunk 14464/15800 (32%) (01423a00) (3) Writing chunk 14465/15800 (60%) (01423fb4) (4) <--- LOST! and the other three chunks checked out all right. And here's the annotated trace as it concerns that page: - here we write the first chunk to the page: ** (1) do_no_page: mapping index 1423 at b7d1f44c (write) ** Setting page 1423 dirty - something flushes it out to disk: ** cpd_for_io: index 1423 ** cleaning index 1423 at b7d1f000 - here we write the second chunk (which was split over the previous page and the interesting one): ** (2) Setting page 1422 dirty ** (2) Setting page 1423 dirty - and here we do a cleaning event ** cpd_for_io: index 1423 ** cleaning index 1423 at b7d1f000 - here we write the third chunk: ** (3) Setting page 1423 dirty - here we write the fourth chunk: ** (4) NO DIRTY EVENT - and a third flush to disk: ** cpd_for_io: index 1423 ** cleaning index 1423 at b7d1f000 - here we unmap and flush: ** Unmapped index 1423 at b7d1f000 ** Removing index 1423 from page cache - here we remap to check: ** do_no_page: mapping index 1423 at b7d1f000 (read) ** Unmapped index 1423 at b7d1f000 - and finally, here I remove the file after the run: ** Removing index 1423 from page cache Now, the important thing to see here is: - the missing write did not have a "Setting page 1423 dirty" event associated with it. - but I can _see_ where the actual dirty event would be happening in the logs, because I can see the dirty events of the other chunk writes around it, so I know exactly where that fourth write happens. And indeed, it _shouldn't_ get a dirty event, because the page is still dirty from the write of chunk #3 to that page, which _did_ get a dirty event. I can see that, because the testing app writes the log of the pages it writes, and this is the log around the fourth and final write: ... Writing chunk 5338/15800 (60%) (0076eb48) PFN: 76e/76f Writing chunk 960/15800 (60%) (00156300)PFN: 156 Writing chunk 14465/15800 (60%) (01423fb4) < Writing chunk 8594/15800 (60%) (00bf74a8) PFN: bf7 Writing chunk 556/15800 (60%) (000c62f0)PFN: c6 Writing chunk 15190/15800 (60%) (01526678) PFN: 1526 ... and I can match this up with the full log from the kernel, which looks like this: Setting page 076e dirty Setting page 076f dirty Setting page 0156 dirty Setting page 00c6 dirty Setting page 1526 dirty so I know exactly where the missing writes (to our page at pfn 1423, and the fpn-bf7 page) happened. - and the thing is, I can see a "cpd_for_io()" happening AFTER that fourth write. Quite a long while after, in fact. So all of this looks very fine indeed. We are not losing any dirty bits. - EVEN MORE INTERESTING: write 3 makes it onto disk, and it really uses the SAME dirty bit as write 4 did (which didn't make it out to disk!). The event that clears the dirty bit that write 3 did happens AFTER write 4 has happened! So if we're not losing any dirty bits, what's going on? I think we have some nasty interaction with the buffer heads. In particular, I don't think it's the dirty page bits that are broken (I _see_ that the PageDirty bit was set after write 4 was done to memory in the kernel traces). So I think that a real writeback just doesn't happen, because somebody has marked the buffer heads clean _after_ it started IO on them. I think "__mpage_writepage()" is buggy in this regard, for example. It even has a comment about its crapola behaviour: /* * Must try to add the page before marking the buffer clean or * the confused fail path above (OOM) will be very confused when * it finds all bh marked clean (i.e. it will not write anything) */ however, I don't think that particular thing explains it, because I don't think we use that function for the cases I'm looking
Re: [patch 2.6.20-rc1 6/6] input: ads7846 directly senses PENUP state
> > > I think these helpers just obfuscate the code, just call
> > > input_report_*() and input_sync() drectly like you used to do.
> >
> > Fair enough, I had a similar thought. Imre, could you do that update?
>
> Yes, the patch is against the OMAP tree.
Thanks ... still hoping that the OMAP tree will just be able
to pull down the kernel.org version of this driver soon!!
OK, here's an updated patch 6/6 that merges Imre's update.
Dmitry, that makes six patches you should have ... I updated
the hwmon patch (#3), and now this one (#6); #4 and #5 will
thus apply with some offsets.
If you don't have other issues, I'd like to see these get into
the 2.6.20 release ... except for that version of the hwmon patch,
everything has been in use for some time through the OMAP tree,
which AFAICT is right now the main user of this driver. (That'll
change a bit once Atmel's patches merge.)
- Dave
== CUT HERE
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wed Jul 5 19:18:32 2006 +0300
Input: ads7846: detect pen up from GPIO state
We can't depend on the pressure value to determine when the pen was
lifted, so use the GPIO line state instead. This also helps with
chips (like ads7843) that don't have pressure sensors.
Signed-off-by: Imre Deak <[EMAIL PROTECTED]>
Signed-off-by: Juha Yrjola <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: at91/drivers/input/touchscreen/ads7846.c
===
--- at91.orig/drivers/input/touchscreen/ads7846.c 2006-12-22
12:13:27.0 -0800
+++ at91/drivers/input/touchscreen/ads7846.c2006-12-28 14:19:51.0
-0800
@@ -441,11 +441,8 @@ static struct attribute_group ads7845_at
static void ads7846_rx(void *ads)
{
struct ads7846 *ts = ads;
- struct input_dev*input_dev = ts->input;
unsignedRt;
- unsignedsync = 0;
u16 x, y, z1, z2;
- unsigned long flags;
/* ads7846_rx_val() did in-place conversion (including byteswap) from
* on-the-wire format as part of debouncing to get stable readings.
@@ -459,7 +456,7 @@ static void ads7846_rx(void *ads)
if (x == MAX_12BIT)
x = 0;
- if (likely(x && z1 && !device_suspended(>spi->dev))) {
+ if (likely(x && z1)) {
/* compute touch pressure resistance using equation #2 */
Rt = z2;
Rt -= z1;
@@ -475,52 +472,42 @@ static void ads7846_rx(void *ads)
* once more the measurement
*/
if (ts->tc.ignore || Rt > ts->pressure_max) {
+#ifdef VERBOSE
+ pr_debug("%s: ignored %d pressure %d\n",
+ ts->spi->dev.bus_id, ts->tc.ignore, Rt);
+#endif
hrtimer_start(>timer, ktime_set(0, TS_POLL_PERIOD),
HRTIMER_REL);
return;
}
- /* NOTE: "pendown" is inferred from pressure; we don't rely on
-* being able to check nPENIRQ status, or "friendly" trigger modes
-* (both-edges is much better than just-falling or low-level).
-*
-* REVISIT: some boards may require reading nPENIRQ; it's
-* needed on 7843. and 7845 reads pressure differently...
+ /* NOTE: We can't rely on the pressure to determine the pen down
+* state, even this controller has a pressure sensor. The pressure
+* value can fluctuate for quite a while after lifting the pen and
+* in some cases may not even settle at the expected value.
*
-* REVISIT: the touchscreen might not be connected; this code
-* won't notice that, even if nPENIRQ never fires ...
+* The only safe way to check for the pen up condition is in the
+* timer by reading the pen signal state (it's a GPIO _and_ IRQ).
*/
- if (!ts->pendown && Rt != 0) {
- input_report_key(input_dev, BTN_TOUCH, 1);
- sync = 1;
- } else if (ts->pendown && Rt == 0) {
- input_report_key(input_dev, BTN_TOUCH, 0);
- sync = 1;
- }
-
if (Rt) {
- input_report_abs(input_dev, ABS_X, x);
- input_report_abs(input_dev, ABS_Y, y);
- sync = 1;
- }
-
- if (sync) {
- input_report_abs(input_dev, ABS_PRESSURE, Rt);
- input_sync(input_dev);
- }
-
-#ifdef VERBOSE
- if (Rt || ts->pendown)
- pr_debug("%s: %d/%d/%d%s\n", ts->spi->dev.bus_id,
- x, y, Rt, Rt ? "" : " UP");
+ if (!ts->pendown) {
+ input_report_key(ts->input, BTN_TOUCH, 1);
+ ts->pendown = 1;
+#ifdef VERBOSE
+ dev_dbg(>spi->dev, "DOWN\n");
#endif
+ }
+ input_report_abs(ts->input, ABS_X, x);
+
RE: Binary Drivers
On Thu, 28 Dec 2006, David Schwartz wrote: Patents don't provide any ability to keep things secret. Copyright doesn't apply to a creative work you made yourself, even if it describes the creative work of another in *functional* detail. in fact, to get a Patent you are required to explain the invention in sufficant detail for somone 'normally skilled' in the field to be able to duplicate it. the Patent protection is a reward for _not_ keeping thing secret and publicising the details. at least in that's how it's supposed to work. David Lang - 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] mm: fix page_mkclean_one
On Thu, 2006-12-28 at 11:45 -0800, Andrew Morton wrote: > On Thu, 28 Dec 2006 11:28:52 -0800 (PST) > Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > > > > > On Thu, 28 Dec 2006, Guillaume Chazarain wrote: > > > > > > The attached patch fixes the corruption for me. > > > > Well, that's a good hint, but it's really just a symptom. You effectively > > just made the test-program not even try to flush the data to disk, so the > > page cache would stay in memory, and you'd not see the corruption as well. > > > > So you basically disabled the code that tried to trigger the bug more > > easily. > > > > But the reason I say it's interesting is that "WB_SYNC_NONE" is very much > > implicated in mm/page-writeback.c, and if there is a bug triggered by > > WB_SYNC_NONE writebacks, then that would explain why page-writeback.c also > > fails.. > > > > It would be interesting to convert your app to do fsync() before > FADV_DONTNEED. That would take WB_SYNC_NONE out of the picture as well > (apart from pdflush activity). I did fdatasync(), tried remapping before unmapping... nogo here. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Binary Drivers
> Do we have a right to reverse engineer hardware, or they are protected by > patents or something similar that would prevent you from > publishing results > adn/or drivers (open source). As I understand the issues, you have the right to reverse engineer hardware except where the DMCA applies. I don't see any way a patent or similar could prevent you from publishing results. Again, the DMCA might. > Are there any restrictions in how you obtain information - signal > analyser, > disassembly of windows driver, etc. There are a few things that might be able to impose such a restriction on you. If none of these apply, I think you should be okay: Any EULA, shrink-wrap, or click-through type agreement that might apply to the software (whether the driver, OS, analyzer, or whatever). Also, any actual agreement you entered into. Patents don't provide any ability to keep things secret. Copyright doesn't apply to a creative work you made yourself, even if it describes the creative work of another in *functional* detail. IANAL, and I might have missed something. IMO, the DMCA or a driver EULA are the only things you really need to worry about. It's hard to see how the DMCA would apply if we're not talking about some kind of content protection scheme. DS - 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/
2.6.20-rc2: known regressions with patches available
This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19 with patches available If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: selinux networking: sleeping function called from invalid context References : http://lkml.org/lkml/2006/12/24/78 Submitter : "Adam J. Richter" <[EMAIL PROTECTED]> Caused-By : Paul Moore <[EMAIL PROTECTED]> Handled-By : Parag Warudkar <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2006/12/24/89 Status : patch available Subject: KVM Oops References : http://lkml.org/lkml/2006/12/27/171 Submitter : Parag Warudkar <[EMAIL PROTECTED]> Handled-By : Avi Kivity <[EMAIL PROTECTED]> Status : patch available Subject: drivers/macintosh/via-pmu-backlight.c compilation broken References : http://lkml.org/lkml/2006/12/24/49 Submitter : Andreas Schwab <[EMAIL PROTECTED]> Caused-By : Yu Luming <[EMAIL PROTECTED]> commit 519ab5f2be65b72cf12ae99c89752bbe79b44df6 Handled-By : Andreas Schwab <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2006/12/24/49 Status : patch available Subject: NULL dereference in ieee80211softmac_get_network_by_bssid_locked ieee80211softmac_wx.c typo: mutex_lock -> mutex_unlock References : http://bugzilla.kernel.org/show_bug.cgi?id=7657 http://lkml.org/lkml/2006/12/16/141 http://lkml.org/lkml/2006/12/24/43 Submitter : Michael Bommarito <[EMAIL PROTECTED]> Ben Collins <[EMAIL PROTECTED]> Martin Pitt <[EMAIL PROTECTED]> Handled-By : Michael Bommarito <[EMAIL PROTECTED]> Larry Finger <[EMAIL PROTECTED] Patch : http://bugzilla.kernel.org/show_bug.cgi?id=7657 Status : patches available Subject: BUG at drivers/scsi/scsi_lib.c:1118 by "pktsetup dvd /dev/sr0" References : http://bugzilla.kernel.org/show_bug.cgi?id=7667 Submitter : Laurent Riffard <[EMAIL PROTECTED]> Caused-By : Christoph Hellwig <[EMAIL PROTECTED]> commit 3b00315799d78f76531b71435fbc2643cd71ae4c Handled-By : Christoph Hellwig <[EMAIL PROTECTED]> Patch : http://bugzilla.kernel.org/show_bug.cgi?id=7667 Status : patch available - 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] remove 556 unneeded #includes of sched.h
On Thu, 28 Dec 2006, Russell King wrote: > I'm talking about cross-builds... I don't know the spec of the machine, > only that it's x86 based (I don't run it.) > > The last report at the beginning of this month said: 11 1/2 hours per > git snapshot, which is apparantly for building a total of about 115 > kernels covering all ARM defconfigs, MIPS, PPC, and i386. Ah, that sound reassuring: 115 kernels in 11.5 hours = 6 minutes per kernel. I just started building all arm defconfigs, and assabet_defconfig took about 7 minutes. So I don't seem to be that far off. Thanks, Tim - 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] remove 556 unneeded #includes of sched.h
On Thu, Dec 28, 2006 at 10:53:44PM +0100, Tim Schmielau wrote: > On Thu, 28 Dec 2006, Russell King wrote: > > Given that it takes about 8 to 12 hours to do a build cycle, that's > > My build cycle takes about 2 hours for 4 configs, on a decent AMD64 > system (running completely in tmpfs). Am I doing something wrong or are > you talking about native builds? I'm talking about cross-builds... I don't know the spec of the machine, only that it's x86 based (I don't run it.) The last report at the beginning of this month said: 11 1/2 hours per git snapshot, which is apparantly for building a total of about 115 kernels covering all ARM defconfigs, MIPS, PPC, and i386. -- 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] IPMI: fix some RCU problems
On Thu, Dec 28, 2006 at 12:24:22PM -0800, Randy Dunlap wrote:
> On Thu, 28 Dec 2006 11:55:04 -0800 Paul E. McKenney wrote:
>
> > list.h | 58 ++
> > 1 file changed, 58 insertions(+)
> >
> > diff -urpNa -X dontdiff linux-2.6.19/include/linux/list.h
> > linux-2.6.19-lpr/include/linux/list.h
> > --- linux-2.6.19/include/linux/list.h 2006-11-29 13:57:37.0
> > -0800
> > +++ linux-2.6.19-lpr/include/linux/list.h 2006-12-28 11:48:31.0
> > -0800
> > @@ -360,6 +360,64 @@ static inline void list_splice_init(stru
> > }
> >
> > /**
> > + * list_splice_init_rcu - splice an RCU-protected list into an existing
> > list.
> > + * @list the RCU-protected list to splice
> > + * @head the place in the list to splice the first list into
> > + * @sync function to sync: synchronize_rcu(), synchronize_sched(), ...
>
> @parameter: is kernel-doc syntax.
> I.e., please add a colon after each one of those.
Good point! :-/
Fixed below.
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---
list.h | 58 ++
1 file changed, 58 insertions(+)
diff -urpNa -X dontdiff linux-2.6.19/include/linux/list.h
linux-2.6.19-lpr/include/linux/list.h
--- linux-2.6.19/include/linux/list.h 2006-11-29 13:57:37.0 -0800
+++ linux-2.6.19-lpr/include/linux/list.h 2006-12-28 14:21:05.0
-0800
@@ -360,6 +360,64 @@ static inline void list_splice_init(stru
}
/**
+ * list_splice_init_rcu - splice an RCU-protected list into an existing list.
+ * @list: the RCU-protected list to splice
+ * @head: the place in the list to splice the first list into
+ * @sync: function to sync: synchronize_rcu(), synchronize_sched(), ...
+ *
+ * @head can be RCU-read traversed concurrently with this function.
+ *
+ * Note that this function blocks.
+ *
+ * Important note: the caller must take whatever action is necessary to
+ * prevent any other updates to @head. In principle, it is possible
+ * to modify the list as soon as sync() begins execution.
+ * If this sort of thing becomes necessary, an alternative version
+ * based on call_rcu() could be created. But only if -really-
+ * needed -- there is no shortage of RCU API members.
+ */
+static inline void list_splice_init_rcu(struct list_head *list,
+ struct list_head *head,
+ void (*sync)(void))
+{
+ struct list_head *first = list->next;
+ struct list_head *last = list->prev;
+ struct list_head *at = head->next;
+
+ might_sleep();
+ if (list_empty(head)) {
+ return;
+ }
+
+ /* "first" and "last" tracking list, so initialize it. */
+
+ INIT_LIST_HEAD(list);
+
+ /*
+* At this point, the list body still points to the source list.
+* Wait for any readers to finish using the list before splicing
+* the list body into the new list. Any new readers will see
+* an empty list.
+*/
+
+ sync();
+
+ /*
+* Readers are finished with the source list, so perform splice.
+* The order is important if the new list is global and accessible
+* to concurrent RCU readers. Note that RCU readers are not
+* permitted to traverse the prev pointers without excluding
+* this function.
+*/
+
+ last->next = at;
+ smp_wmb();
+ head->next = first;
+ first->prev = head;
+ at->prev = last;
+}
+
+/**
* list_entry - get the struct for this entry
* @ptr: the list_head pointer.
* @type: the type of the struct this is embedded in.
-
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: Regression in kernel linux-2.6.20-rc1/2: Problems with poweroff
On Tue, Dec 26, 2006 at 01:15:38AM +0100, Berthold Cogel wrote: > Hello! Hi Berthold! > 'shutdown -h now' doesn't work for my system (Acer Extensa 3002 WLMi) > with linux-2.6.20-rc kernels. The system reboots instead. > I've checked linux-2.6.19.1 with an almost identical .config file > (differences because of new or changed options). For pre 2.6.20 kernels > shutdown works for my computer. >... Thanks for your report. Please send: - the .config for 2.6.20-rc2 - the output of "dmesg -s 100" with 2.6.20-rc2 - the output of "dmesg -s 100" with 2.6.19 > Regards, > > Berthold Cogel cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.12-rc2] PNP: export pnp_bus_type
On Thursday 28 December 2006 2:05 am, Arjan van de Ven wrote: > > > Hmm, then maybe it'd be worth updating that patch I just sent so that > > the only change is to switch #includes for the extern decl ... i.e. to > > "export" it only to other statically linked kernel code, rather than to > > modules. I'll do that. > > > > My own question about that EXPORT_SYMBOL was whether it instead be > > an EXPORT_SYMBOL_GPL, but if either one costs bytes ... I'm happy to > > avoid that cost! > > no export if it's not *really* need is obviously superior to either of > those so yes I like the patch you're talking about already without even > having seen it ;) The change is trivial ... in pnp/driver.c strike the EXPORT_SYMBOL. So I won't bother posting it to this list; I hate wasting electrons. I sent the updated patch to Andrew, but evidently just missed his 2.6.20-rc2-mm1 cutoff. - Dave - 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.20-rc1 1/6] GPIO core
On Wednesday 27 December 2006 9:49 am, Pavel Machek wrote:
> Hi!
Good afternoon. :)
> > +Identifying GPIOs
> > +-
> > +GPIOs are identified by unsigned integers in the range 0..MAX_INT. That
> > +reserves "negative" numbers for other purposes like marking signals as
> > +"not available on this board", or indicating faults.
> > +
> > +Platforms define how they use those integers, and usually #define symbols
> > +for the GPIO lines so that board-specific setup code directly corresponds
> > +to the relevant schematics. In contrast, drivers should only use GPIO
>
> Perhaps these should not be integers, then?
Thing is, the platforms **DO** identify them as integers.
Go through OMAP, PXA, StrongARM chip docs ... what you see is
references to GPIO numbers, 0..MAX, and oh by the way those map to
bit offsets within gpio controller banks.
When they don't identify them as integers, as with AT91, AVR32, and
S3C -- all of which present GPIOs as a lettered bank plus a bit offset
within that bank, isn't that structure familiar -- then the Linux
platform support already #defines them as integers. The naming matches
chip docs, the _numbering_ works much the same as on OMAP, PXA, etc.
Fortunately, only OMAP1 seems to have that ugly many-to-many mapping
between chip pins and GPIOs. On other current platforms, once you
know the GPIO number you know the pin, and vice versa. (That does
not matter to drivers at all -- only board setup code talks "pins",
everything else talks about functions such as "GPIO" -- but hairy
board setup code can be a frelling HUGE time sink/waste.)
> typedef struct { int mydata } pin_t; prevents people from looking
> inside, allows you to typecheck, and allows expansion in (unlikely) case where
> more than int is needed? ...hotpluggable gpio pins?
If some system wants that kind of infrastructure, it can easily
implement it behind this API. There's the IDR infrastructure, for
example, to allocate integers and map them to "more than int" data
for internal uses.
I could very easily imagine platforms that support the spinlock-safe
accessors for the SOC-integrated GPIOs, e.g. numbered below N, and
have a more dynamic "plug in your own external GPIO controller" way
to support GPIOs on i2c expanders, multifunction chips, and suchlike;
with that plugin stuff built over IDR and structures with ops vectors.
> > +Spinlock-Safe GPIO access
> > +-
> > ...
> > +
> > + /* GPIO INPUT: return zero or nonzero */
> > + int gpio_get_value(unsigned gpio);
> > +
> > + /* GPIO OUTPUT */
> > + void gpio_set_value(unsigned gpio, int value);
> > +
> > ...
> > +
> > +The get/set calls have no error returns because "invalid GPIO" should have
> > +been reported earlier in gpio_set_direction(). However, note that not all
> > +platforms can read the value of output pins; those that can't should always
> > +return zero. Also, these calls will be ignored for GPIOs that can't safely
> > +be accessed without sleeping (see below).
>
> 'Silently ignored' is ugly. BUG() would be okay there.
The reason for "silently ignored" is that we really don't want to be
cluttering up the code (source or object) with logic to test for this
kind of "can't happen" failure, especially since there's not going to
be any way to _resolve_ such failures cleanly.
And per Linus' rule about BUG(), "silently ignored" is clearly better
than needlessly stopping the whole system.
And for spinlock-unsafe cases, like I2C based GPIO expanders;
> > +Platforms that support this type of GPIO distinguish them from other GPIOs
> > +by returning nonzero from this call:
> > +
> > + int gpio_cansleep(unsigned gpio);
>
> This is ugly :-(. But I don't see easy way around...
Me either. Folk said earlier they want an API that can get/set
both types of GPIO, mostly to support userspace tweaking/config APIs,
but the only way I can see to have one of those is to include a
predicate like gpio_cansleep() to distinguish the two types.
> > +GPIOs mapped to IRQs
> > +
> > +GPIO numbers are unsigned integers; so are IRQ numbers. These make up
> > +two logically distinct namespaces (GPIO 0 need not use IRQ 0). You can
> > +map between them using calls like:
> > +
> > + /* map GPIO numbers to IRQ numbers */
> > + int gpio_to_irq(unsigned gpio);
> > +
> > + /* map IRQ numbers to GPIO numbers */
> > + int irq_to_gpio(unsigned irq);
>
> . Don't we have irq_t already?
Nope. Such a type would likely get in the way of lowlevel IRQ
dispatch code too ...
> > +Those return either the corresponding number in the other namespace, or
> > +else a negative errno code if the mapping can't be done. (For example,
> > +some GPIOs can't used as IRQs.) It is an unchecked error to use a GPIO
> > +number that hasn't been marked as an input using gpio_set_direction(), or
>
> It should be valid to do irqs on outputs,
Good point -- it _might_ be valid to do that, on some platforms.
Such
Re: [PATCH] remove 556 unneeded #includes of sched.h
On Thu, 28 Dec 2006, Russell King wrote: > Given that it takes about 8 to 12 hours to do a build cycle, that's My build cycle takes about 2 hours for 4 configs, on a decent AMD64 system (running completely in tmpfs). Am I doing something wrong or are you talking about native builds? Tim - 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/
CAP_LINUX_IMMUTABLE question
CAP_LINUX_IMMUTABLE currently makes it impossible both to chattr +i or chattr -i. I think it would be convenient if there was someone to make it only illegal for chattr -i. So that I could still make files unchangeable, while not allowing myself to ever make them changeable again without the capability. I'm currently using CAP_LINUX_IMMUTABLE (along with CAP_SYS_RAWIO and CAP_SYS_MODULE) to make a poor-man's readonly bootable USB key for USB drives that don't have a physical R/W switch. (The priviledges are dropped in my initscripts). The only problem is that such a USB key isn't able to make a copy of itself because it can't remove the mutability of files which is a little inconvenient. :) I doubt it would be possible to change the semantics for CAP_LINUX_IMMUTABLE but would it be stupid of me to try to add a CAP_LINUX_MUTABLE flag that does what I want? Thanks, Aaron - 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.19-rc5 libata PATA ATAPI CDROM SiS 5513 NOT WORKING
Hello Alan, Jeff, Reading a paper on this new libata, I just want to try but failled yet for what said this thread "ATAPI CDROM" ;_(. I first test the latest stable 2.6.19.1 without luck, so I also want to try latest 2.6.20-rc2 unfortunately without more success. Here it was the test of new libata with 2.6.19.1: [snip] ata_piix :00:07.1: version 2.00ac6 ata1: PATA max UDMA/33 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 ata2: PATA max UDMA/33 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 scsi3 : ata_piix ata1.00: ATA-4, max UDMA/66, 29336832 sectors: LBA ata1.00: ata1: dev 0 multi count 16 ata1.01: ATAPI, max MWDMA1 ata1.00: configured for UDMA/33 ata1.01: qc timeout (cmd 0xa1) ata1.01: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.01: revalidation failed (errno=-5) ata1.01: limiting speed to PIO3 ata1: failed to recover some devices, retrying in 5 secs ata1: port is slow to respond, please be patient (Status 0xd0) ata1: port failed to respond (30 secs, Status 0xd0) ata1.01: qc timeout (cmd 0xa1) ata1.01: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.01: revalidation failed (errno=-5) ata1: failed to recover some devices, retrying in 5 secs ata1: port is slow to respond, please be patient (Status 0xd0) ata1: port failed to respond (30 secs, Status 0xd0) ata1.01: qc timeout (cmd 0xa1) ata1.01: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.01: revalidation failed (errno=-5) ata1.01: disabled ata1: failed to recover some devices, retrying in 5 secs ata1.00: failed to set xfermode (err_mask=0x40) ata1.00: limiting speed to UDMA/25 ata1: failed to recover some devices, retrying in 5 secs ata1: port is slow to respond, please be patient (Status 0xd0) ata1: port failed to respond (30 secs, Status 0xd0) ata1.00: configured for UDMA/25 scsi4 : ata_piix scsi 3:0:0:0: Direct-Access ATA QUANTUM FIREBALL A03. PQ: 0 ANSI: 5 SCSI device sdc: 29336832 512-byte hdwr sectors (15020 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back SCSI device sdc: 29336832 512-byte hdwr sectors (15020 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back sdc: sdc1 sdc2 < sdc5 sdc6 sdc7 sdc8 sdc9 sdc10 sdc11 sdc12 sdc13 sdc14 sdc15 > sd 3:0:0:0: Attached scsi disk sdc sd 3:0:0:0: Attached scsi generic sg2 type 0 [snip] And today with 2.6.20-rc2: ata_piix :00:07.1: version 2.00ac7 ata1: PATA max UDMA/33 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 ata2: PATA max UDMA/33 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 scsi3 : ata_piix ata1.00: ATA-4, max UDMA/66, 29336832 sectors: LBA ata1.00: ata1: dev 0 multi count 16 ata1.01: ATAPI, max MWDMA1 ata1.00: configured for UDMA/33 ata1.01: qc timeout (cmd 0xa1) ata1.01: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.01: revalidation failed (errno=-5) ata1.01: limiting speed to PIO3 ata1: failed to recover some devices, retrying in 5 secs ata1: port is slow to respond, please be patient (Status 0xd0) ata1: port failed to respond (30 secs, Status 0xd0) ata1.01: qc timeout (cmd 0xa1) ata1.01: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.01: revalidation failed (errno=-5) ata1: failed to recover some devices, retrying in 5 secs ata1: port is slow to respond, please be patient (Status 0xd0) ata1: port failed to respond (30 secs, Status 0xd0) ata1.01: qc timeout (cmd 0xa1) ata1.01: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.01: revalidation failed (errno=-5) ata1.01: disabled ata1: failed to recover some devices, retrying in 5 secs ata1.00: failed to set xfermode (err_mask=0x40) ata1.00: limiting speed to UDMA/25 ata1: failed to recover some devices, retrying in 5 secs ata1: port is slow to respond, please be patient (Status 0xd0) ata1: port failed to respond (30 secs, Status 0xd0) ata1.00: configured for UDMA/25 scsi4 : ata_piix scsi 3:0:0:0: Direct-Access ATA QUANTUM FIREBALL A03. PQ: 0 ANSI: 5 SCSI device sdc: 29336832 512-byte hdwr sectors (15020 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdc: 29336832 512-byte hdwr sectors (15020 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc1 sdc2 < sdc5 sdc6 sdc7 sdc8 sdc9 sdc10 sdc11 sdc12 sdc13 sdc14 sdc15 > sd 3:0:0:0: Attached scsi disk sdc sd 3:0:0:0: Attached scsi generic sg2 type 0 [snip] seems to look like same kind of pb this thread speak about (i.e. hd seems to works fine but not atapi cdrom (r/w)) but not sure? Any idea/advise? Tia, Joel PS0: I check that scsi cdrom was well selected PS1: with traditional ide support I get (with same 2.6.19.1 kernel): [snip] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller at PCI slot :00:07.1 PIIX4: chipset revision 1 PIIX4: not 100% native
Re: [PATCH] remove 556 unneeded #includes of sched.h
On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote: > On Thu, 28 Dec 2006 21:34:38 + Russell King wrote: > > The whole "all*config" idea on ARM is utterly useless - you can _not_ > > get build coverage that way. > > Uh, can J. Random Developer submit patches to the ARM build system > for testing? Given that it takes about 8 to 12 hours to do a build cycle, that's not practical. The only real solution is for us to accept that breakage will occur (and be prepared to keep a steady stream of fixes heading into Linus' tree - which has been ruled out by Linus) or J. Random Developer has to build a set of affected ARM defconfigs themselves. Or alternatively the guy who's running kautobuild needs an amount of rather powerful donated hardware to stubstantially increase it's throughput. Or cross-gcc needs to be optimised to compile faster. I don't see any of the above happening, so... -- 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: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Dave Jones wrote: On Wed, Dec 27, 2006 at 10:32:53PM +0100, Rene Herman wrote: The bug where the kernel repetitively emits "atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly" (sic) on a panic, thereby scrolling away the information that would help in seeing what exactly the problem was (ie, "Unable to mount root fs" or something) is still present in 2.6.20-rc2. Do you have a KVM ? Quite a few of those seem to tickle this printk. No, regular old PS/2 keyboard, directly connected. Due to that exact uneventfullness and having seen it reported before recently (*) I assumed everyone was seeing this. If not, I guess I can try to narrow it down. It's easy to test for anyone willing: just boot with "root=/dev/null" or something as a kernel param. The printk's are in sync with the panic code blinking the leds. (*) Here there was supposed to be a link to the post I was refferring to, but googling for it led to http://lkml.org/lkml/2006/11/13/300 Dmitry, could you ask Linus to pull the change? I find this to be an exceedingly annoying bug. It's just so incredibly silly, having one part of the kernel helpfully blink leds at you with another part going "hey, dude! don't do that!" 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: BUG: scheduling while atomic, new libata code
On Thursday 28 December 2006 03:16, Jon Smirl wrote: > BUG: scheduling while atomic: hald-addon-stor/0x2000/5078 > [] __sched_text_start+0x5f9/0xb00 > [] net_rx_action+0xb3/0x180 > [] __do_softirq+0x72/0xe0 > [] do_IRQ+0x45/0x80 This doesn't seem to be related to libata at all. Like your first trace, you call schedule from a softirq context, which is always atomic. The only place where I can imagine this happening is the local_irq_enable() in there, which can be defined in different ways. Are you running with paravirt_ops, CONFIG_TRACE_IRQFLAGS_SUPPORT and/or kernel preemption enabled? Arnd <>< - 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] remove 556 unneeded #includes of sched.h
On Thu, 28 Dec 2006, Russell King wrote: > To cover these, you need to build at least rpc_defconfig, lubbock_defconfig, > netwinder_defconfig, badge4_defconfig, cerf_defconfig, ...etc... OK, I'll try to do that. Do I need to build all the configs in arch/arm/configs? > The whole "all*config" idea on ARM is utterly useless - you can _not_ > get build coverage that way. Or shall I exclude the arm specific drivers for now? Tim - 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] remove 556 unneeded #includes of sched.h
On Thu, 28 Dec 2006 21:34:38 + Russell King wrote: > On Thu, Dec 28, 2006 at 10:18:12PM +0100, Tim Schmielau wrote: > > On Thu, 28 Dec 2006, Al Viro wrote: > > > > > Uh-huh. How much of build coverage have you got with it? > > > > Well, as said in the patch description, I compiled alpha, arm, i386, ia64, > > mips, powerpc, and x86_64 with allnoconfig, defconfig, allmodconfig, and > > allyesconfig as well as a few randconfigs on x86_64. I also checked that > > no new warnings were introduced by the patch. > > That would not have covered the following drivers in this patch on ARM > then: > > acorn/* > nwflash > i2c-iop3xx > i2c-s3c2410 > ether1 > ether3 > etherh > omap_cf > pxa2xx_lubbock > sa1100_badge4 > sa1100_cerf > sa1100_h3600 > sa1100_jornada720 > sa1100_neponset > sa1100_shannon > sa1100_simpad > acornscsi > arxescsi > cumana_1 > cumana_2 > ecoscsi > eesox > fas216 > oak > powertec > at91_udc > omap_udc > pxa2xx_udc > zaurus > > To cover these, you need to build at least rpc_defconfig, lubbock_defconfig, > netwinder_defconfig, badge4_defconfig, cerf_defconfig, ...etc... > > The whole "all*config" idea on ARM is utterly useless - you can _not_ > get build coverage that way. Uh, can J. Random Developer submit patches to the ARM build system for testing? --- ~Randy - 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.19 file content corruption on ext3
On Thu, Dec 28, 2006 at 01:24:30PM -0800, Linus Torvalds wrote: > On Thu, 28 Dec 2006, Linus Torvalds wrote: > > > > What we need now is actually looking at the source code, and people who > > understand the VM, I'm afraid. I'm gathering traces now that I have a good > > test-case. I'll post my trace tools once I've tested that they work, in > > case others want to help. > > Ok, I've got the traces, but quite frankly, I doubt anybody is crazy > enough to want to trawl through them. It's a bit painful, since we're > talking thousands of pages to trigger this problem. > > Also, I've used the PG_arch_1 flag, which is fine on x86[-64] and probably > ARM, but is used for other things on ia64, powerpc and sparc64. But here's > the patch in case anybody cares. PG_arch_1 is used on ARM to flag pages that need a dcache flush prior to hitting userspace, in the same way that sparc64 uses it. So ARM systems should not have this patch applied. -- 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] remove 556 unneeded #includes of sched.h
On Thu, Dec 28, 2006 at 10:18:12PM +0100, Tim Schmielau wrote: > On Thu, 28 Dec 2006, Al Viro wrote: > > > Uh-huh. How much of build coverage have you got with it? > > Well, as said in the patch description, I compiled alpha, arm, i386, ia64, > mips, powerpc, and x86_64 with allnoconfig, defconfig, allmodconfig, and > allyesconfig as well as a few randconfigs on x86_64. I also checked that > no new warnings were introduced by the patch. That would not have covered the following drivers in this patch on ARM then: acorn/* nwflash i2c-iop3xx i2c-s3c2410 ether1 ether3 etherh omap_cf pxa2xx_lubbock sa1100_badge4 sa1100_cerf sa1100_h3600 sa1100_jornada720 sa1100_neponset sa1100_shannon sa1100_simpad acornscsi arxescsi cumana_1 cumana_2 ecoscsi eesox fas216 oak powertec at91_udc omap_udc pxa2xx_udc zaurus To cover these, you need to build at least rpc_defconfig, lubbock_defconfig, netwinder_defconfig, badge4_defconfig, cerf_defconfig, ...etc... The whole "all*config" idea on ARM is utterly useless - you can _not_ get build coverage that way. -- 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: 2.6.20-rc2-mm1: INFO: possible recursive locking detected in con_close
Le 28.12.2006 11:42, Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc2/2.6.20-rc2-mm1/
Hello,
got this with 2.6.20-rc2-mm1, reverting
gregkh-driver-driver-core-fix-race-in-sysfs-between-sysfs_remove_file-and-read-write.patch
made it disappear.
=
[ INFO: possible recursive locking detected ]
2.6.20-rc2-mm1 #51
-
init/324 is trying to acquire lock:
(_inode_imutex_key){--..}, at: [] mutex_lock+0x1c/0x1f
but task is already holding lock:
(_inode_imutex_key){--..}, at: [] mutex_lock+0x1c/0x1f
other info that might help us debug this:
2 locks held by init/324:
#0: (tty_mutex){--..}, at: [] mutex_lock+0x1c/0x1f
#1: (_inode_imutex_key){--..}, at: [] mutex_lock+0x1c/0x1f
stack backtrace:
[] show_trace_log_lvl+0x1a/0x2f
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] __lock_acquire+0x116/0xb33
[] lock_acquire+0x56/0x6f
[] __mutex_lock_slowpath+0xdc/0x266
[] mutex_lock+0x1c/0x1f
[] sysfs_drop_dentry+0xb7/0x12b
[] sysfs_hash_and_remove+0x90/0x14a
[] sysfs_remove_file+0xd/0xf
[] device_remove_file+0x1f/0x2a
[] device_del+0x31/0x1c4
[] device_unregister+0xb/0x15
[] device_destroy+0x8b/0x91
[] vcs_remove_sysfs+0x1a/0x36
[] con_close+0x4c/0x60
[] release_dev+0x221/0x62a
[] tty_release+0x12/0x1c
[] __fput+0xb9/0x177
[] fput+0x31/0x35
[] filp_close+0x54/0x5c
[] put_files_struct+0x7c/0xb9
[] do_exit+0x219/0x72f
[] sys_exit_group+0x0/0x11
[] sys_exit_group+0xf/0x11
[] sysenter_past_esp+0x5f/0x99
===
--
laurent
-
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.19 file content corruption on ext3
On Thu, 28 Dec 2006, Linus Torvalds wrote:
>
> What we need now is actually looking at the source code, and people who
> understand the VM, I'm afraid. I'm gathering traces now that I have a good
> test-case. I'll post my trace tools once I've tested that they work, in
> case others want to help.
Ok, I've got the traces, but quite frankly, I doubt anybody is crazy
enough to want to trawl through them. It's a bit painful, since we're
talking thousands of pages to trigger this problem.
Also, I've used the PG_arch_1 flag, which is fine on x86[-64] and probably
ARM, but is used for other things on ia64, powerpc and sparc64. But here's
the patch in case anybody cares.
It wants a _big_ kernel buffer to capture all the crud into (which is why
I made the thing accept a bigger log buffer), and quite frankly, I'm not
at all sure that all the locking is ok (ie I could imagine that the
dcache-locking thing there in "is_interesting()" could deadlock, what do I
know..)
But I've captured some real data with this, which I'll describe
separately.
Linus
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 350878a..967dd80 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -91,6 +91,8 @@
#define PG_nosave_free 18 /* Used for system suspend/resume */
#define PG_buddy 19 /* Page is free, on buddy lists */
+#define SetPageInteresting(page) set_bit(PG_arch_1, &(page)->flags)
+#define PageInteresting(page) test_bit(PG_arch_1, &(page)->flags)
#if (BITS_PER_LONG > 32)
/*
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 5c26818..7735b83 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -79,7 +79,7 @@ config DEBUG_KERNEL
config LOG_BUF_SHIFT
int "Kernel log buffer size (16 => 64KB, 17 => 128KB)" if DEBUG_KERNEL
- range 12 21
+ range 12 24
default 17 if S390 || LOCKDEP
default 16 if X86_NUMAQ || IA64
default 15 if SMP
diff --git a/mm/filemap.c b/mm/filemap.c
index 8332c77..d6a0f56 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -116,6 +116,7 @@ void __remove_from_page_cache(struct page *page)
{
struct address_space *mapping = page->mapping;
+if (PageInteresting(page)) printk("Removing index %08x from page cache\n",
page->index);
radix_tree_delete(>page_tree, page->index);
page->mapping = NULL;
mapping->nrpages--;
@@ -421,6 +422,23 @@ int filemap_write_and_wait_range(struct address_space
*mapping,
return err;
}
+static noinline int is_interesting(struct address_space *mapping)
+{
+ struct inode *inode = mapping->host;
+ struct dentry *dentry;
+ int retval = 0;
+
+ spin_lock(_lock);
+ list_for_each_entry(dentry, >i_dentry, d_alias) {
+ if (strcmp(dentry->d_name.name, "mapfile"))
+ continue;
+ retval = 1;
+ break;
+ }
+ spin_unlock(_lock);
+ return retval;
+}
+
/**
* add_to_page_cache - add newly allocated pagecache pages
* @page: page to add
@@ -439,6 +457,9 @@ int add_to_page_cache(struct page *page, struct
address_space *mapping,
{
int error = radix_tree_preload(gfp_mask & ~__GFP_HIGHMEM);
+ if (is_interesting(mapping))
+ SetPageInteresting(page);
+
if (error == 0) {
write_lock_irq(>tree_lock);
error = radix_tree_insert(>page_tree, offset, page);
diff --git a/mm/memory.c b/mm/memory.c
index 563792f..14c9815 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -667,6 +667,8 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
tlb_remove_tlb_entry(tlb, pte, addr);
if (unlikely(!page))
continue;
+if (PageInteresting(page))
+ printk("Unmapped index %08x at %08x\n", page->index, addr);
if (unlikely(details) && details->nonlinear_vma
&& linear_page_index(details->nonlinear_vma,
addr) != page->index)
@@ -1605,6 +1607,7 @@ gotten:
*/
ptep_clear_flush(vma, address, page_table);
set_pte_at(mm, address, page_table, entry);
+if (PageInteresting(new_page)) printk("do_wp_page: mapping index %08x at
%08lx\n", new_page->index, address);
update_mmu_cache(vma, address, entry);
lru_cache_add_active(new_page);
page_add_new_anon_rmap(new_page, vma, address);
@@ -2249,6 +2252,7 @@ retry:
entry = mk_pte(new_page, vma->vm_page_prot);
if (write_access)
entry = maybe_mkwrite(pte_mkdirty(entry), vma);
+if (PageInteresting(new_page)) printk("do_no_page: mapping index %08x at %08lx
(%s)\n", new_page->index, address, write_access ? "write" : "read");
set_pte_at(mm, address,
Re: [patch] x86: Fix dev_to_node for x86 and x86_64
Ravikiran G Thirumalai wrote: Hi Andrew, dev_to_node() does not work as expected on x86 and x86_64 as pointed out earlier here: http://lkml.org/lkml/2006/11/7/10 Following patch fixes it, please apply. (Note: The fix depends on support for PCI domains for x86/x86_64) Thanks, I'll merge into my misc-2.6.git#pciseg repository, which is where Andrew gets his PCI domain support from. Jeff - 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] remove 556 unneeded #includes of sched.h
On Thu, 28 Dec 2006, Al Viro wrote: > Uh-huh. How much of build coverage have you got with it? Well, as said in the patch description, I compiled alpha, arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig, allmodconfig, and allyesconfig as well as a few randconfigs on x86_64. I also checked that no new warnings were introduced by the patch. > Note that "doesn't use symbols defined in sched.h" != "can remove > include of sched.h", which, in turn, is not the same as "removing it > doesn't cause problems on a couple of configs I've tried on amd64". Sure. But from my experience (I started posting these patches almost five years ago, inspired by a blog entry by davej) actually the only thing that prevents removing the sched.h include (other than using symbols defined there) is dereferencing current, which my scripts also check. Tim - 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] remove 556 unneeded #includes of sched.h
On Thu, 28 Dec 2006, Randy Dunlap wrote: > I'm half done with a patch to remove includes of smp_lock.h. > For the files that I have patched, I checked each source file > for all interfaces in smp_lock.h to verify that none of them > are used, so the #include is just waste. Yes, that's what I also did. And then I checked for all interfaces in all headers included indirectly through sched.h and not already included in the respective source file to see whether any of these includes are needed to keep the file compilable (although this time, amazingly few includes had to be added back - only 5 for all 556) Maybe I should have taken a look at my original patch descripions from last year, I admit the current one isn't very illuminating. Tim - 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] remove 556 unneeded #includes of sched.h
On Thu, Dec 28, 2006 at 09:58:17PM +0100, Tim Schmielau wrote: > On Thu, 28 Dec 2006, Andrew Morton wrote: > > > On Thu, 28 Dec 2006 21:27:40 +0100 (CET) > > Tim Schmielau <[EMAIL PROTECTED]> wrote: > > > > > After Al Viro (finally) succeeded in removing the sched.h #include in > > > module.h recently, it makes sense again to remove other superfluous > > > sched.h includes. > > > > Why are they "superfluous"? Because those compilation > > units pick up sched.h indirectly, via other includes? > > > > If so, is that a thing we want to do? > > No, there is nothing at all in these files that needs sched.h. I suppose > the includes are left over from times when more unrelated macros lived in > sched.h (fortunately much of that cruft got cleand up already). Uh-huh. How much of build coverage have you got with it? Note that "doesn't use symbols defined in sched.h" != "can remove include of sched.h", which, in turn, is not the same as "removing it doesn't cause problems on a couple of configs I've tried on amd64". - 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] x86: Fix dev_to_node for x86 and x86_64
Hi Andrew,
dev_to_node() does not work as expected on x86 and x86_64 as pointed out
earlier here:
http://lkml.org/lkml/2006/11/7/10
Following patch fixes it, please apply. (Note: The fix depends on support
for PCI domains for x86/x86_64)
Thanks,
Kiran
dev_to_node does not work as expected on x86_64 (and i386). This is because
node value returned by pcibus_to_node is initialized after a struct device
is created with current x86_64 code.
We need the node value initialized before the call to pci_scan_bus_parented,
as the generic devices are allocated and initialized
off pci_scan_child_bus, which gets called from pci_scan_bus_parented
The following patch does that using "pci_sysdata" introduced by the PCI
domain patches in -mm.
Signed-off-by: Alok N Kataria <[EMAIL PROTECTED]>
Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTECTED]>
Signed-off-by: Shai Fultheim <[EMAIL PROTECTED]>
Index: linux-2.6.20-rc1/arch/i386/pci/acpi.c
===
--- linux-2.6.20-rc1.orig/arch/i386/pci/acpi.c 2006-12-28 11:51:52.542775000
-0800
+++ linux-2.6.20-rc1/arch/i386/pci/acpi.c 2006-12-28 12:01:19.242775000
-0800
@@ -9,6 +9,7 @@ struct pci_bus * __devinit pci_acpi_scan
{
struct pci_bus *bus;
struct pci_sysdata *sd;
+ int pxm;
/* Allocate per-root-bus (not per bus) arch-specific data.
* TODO: leak; this memory is never freed.
@@ -30,15 +31,21 @@ struct pci_bus * __devinit pci_acpi_scan
}
#endif /* CONFIG_PCI_DOMAINS */
+ sd->node = -1;
+
+ pxm = acpi_get_pxm(device->handle);
+#ifdef CONFIG_ACPI_NUMA
+ if (pxm >= 0)
+ sd->node = pxm_to_node(pxm);
+#endif
+
bus = pci_scan_bus_parented(NULL, busnum, _root_ops, sd);
if (!bus)
kfree(sd);
#ifdef CONFIG_ACPI_NUMA
if (bus != NULL) {
- int pxm = acpi_get_pxm(device->handle);
if (pxm >= 0) {
- sd->node = pxm_to_node(pxm);
printk("bus %d -> pxm %d -> node %d\n",
busnum, pxm, sd->node);
}
-
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 patch] kconfig: remove the unused "requires" syntax
On Tue, Dec 19, 2006 at 06:53:22PM +0100, Roman Zippel wrote: > Hi, > > On Mon, 18 Dec 2006, Adrian Bunk wrote: > > > On Mon, Dec 18, 2006 at 11:41:59AM -0500, Robert P. J. Day wrote: > > > > > > Remove the note in the documentation that suggests people can use > > > "requires" for dependencies in Kconfig files. > > >... > > > > Considering that noone uses it, what about the patch below to also > > remove the implementation? > > Mostly to keep the noise in the generated files low I prefer to just add > some warning prints and I'll remove them later with some other syntax > changes. This would also give external trees the chance to fix any > possible usage first. How to add some warning prints? And what's the problem with changing the generated files? There doesn't seem to be much activity in this area, and the noise of changing the generated files doesn't seem to be a problem for me (except if anyone else is semnding patches for the same area at the same time. It's not as if this noise was big compared to the diff between two Linux releases... Regarding external trees: Do you know about anyone actually using it? The fact that we have zero usages in the kernel and that it doesn't have any additional functionality seems to be a strong hint noone knows about it. And if anyone really uses it, the fix is so trivial... > bye, Roman cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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] remove 556 unneeded #includes of sched.h
On Thu, 28 Dec 2006 12:46:44 -0800 Andrew Morton wrote: > On Thu, 28 Dec 2006 21:27:40 +0100 (CET) > Tim Schmielau <[EMAIL PROTECTED]> wrote: > > > After Al Viro (finally) succeeded in removing the sched.h #include in > > module.h recently, it makes sense again to remove other superfluous > > sched.h includes. > > Why are they "superfluous"? Because those compilation > units pick up sched.h indirectly, via other includes? I'm half done with a patch to remove includes of smp_lock.h. For the files that I have patched, I checked each source file for all interfaces in smp_lock.h to verify that none of them are used, so the #include is just waste. > If so, is that a thing we want to do? Nope. --- ~Randy - 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] remove 556 unneeded #includes of sched.h
On Thu, 28 Dec 2006, Andrew Morton wrote: > On Thu, 28 Dec 2006 21:27:40 +0100 (CET) > Tim Schmielau <[EMAIL PROTECTED]> wrote: > > > After Al Viro (finally) succeeded in removing the sched.h #include in > > module.h recently, it makes sense again to remove other superfluous > > sched.h includes. > > Why are they "superfluous"? Because those compilation > units pick up sched.h indirectly, via other includes? > > If so, is that a thing we want to do? No, there is nothing at all in these files that needs sched.h. I suppose the includes are left over from times when more unrelated macros lived in sched.h (fortunately much of that cruft got cleand up already). Tim - 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/
