Re: [PATCH][RFC] fast file mapping for loop
On Fri, Jan 11 2008, Mikulas Patocka wrote: > > So I looked at the code - it seems you build a full extent of the blocks > > in the file, filling holes as you go along. I initally did that as well, > > but that is to slow to be usable in real life. > > > > You also don't support sparse files, falling back to normal fs > > read/write paths. Supporting sparse files properly is a must, people > > generally don't want to prealloc a huge disk backing. > > How would you do sparse file support with passthrough loopback that > doesn't use pagecache? > > Holes are allocated at get_block function provided by each filesystem and > the function gets a buffer that is supposed to be in the pagecache. Now if > you want to allocate holes without pagecache, there's a problem --- new > interface to all filesystems is needed. > > It could be possible to use pagecache interface for filling holes and > passthrough interface for other requests --- but get_block is allowed to > move other blocks on the filesystem (and on UFS it really does), so > calling get_block to fill a hole could move other unrelated blocks which > would result in desychronized block map and corruption of both > filesystems. Please read the posted patch and the posts from Chris as well, it basically covers everything in your email. The patch, as posted, doesn't work if the fs moves blocks around. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86-64: disable the GART early v2
please check the one that can be applied to x86.git -mm
YH
[PATCH] x86-64: disable the GART early v2
For K8 system: 4G RAM with memory hole remapping enabled, or more than 4G RAM
installed.
when try to use kexec second kernel, and the first doesn't include
gart_shutdown.
the second kernel could have different aper position than the first kernel. and
second
kernel could use that hole as RAM that is still used by GART set by the first
kernel.
esp. when try to kexec 2.6.24 with sparse mem enable from previous kernel (from
RHEL 5
or SLES 10). the new kernel will use aper by GART (set by first kernel) for
vmemmap.
and after new kernel setting one new GART. the position will be real RAM. the
_mapcount
set is lost.
Bad page state in process 'swapper'
page:e2000e600020 flags:0x mapping:
mapcount:1 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Pid: 0, comm: swapper Not tainted 2.6.24-rc7-smp-gcdf71a10-dirty #13
Call Trace:
[] bad_page+0x63/0x8d
[] __free_pages_ok+0x7c/0x2a5
[] free_all_bootmem_core+0xd0/0x198
[] numa_free_all_bootmem+0x3b/0x76
[] mem_init+0x3b/0x152
[] start_kernel+0x236/0x2c2
[] _sinittext+0x11a/0x121
and
[e2000e60-e2000e7f] PMD ->81001c20 on node 0
phys addr is : 0x1c20
RHEL 5.1 kernel -53 said:
PCI-DMA: aperture base @ 1c00 size 65536 KB
new kernel said:
Mapping aperture over 65536 KB of RAM @ 3c00
So try to disable that GART as early as possible.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
index 52d2bea..6e7af45 100644
--- a/arch/x86/kernel/aperture_64.c
+++ b/arch/x86/kernel/aperture_64.c
@@ -218,6 +218,73 @@ static __u32 __init search_agp_bridge(u32 *order, int
*valid_agp)
return 0;
}
+void __init early_gart_iommu_disable(void)
+{
+ /*
+* disable it in case it is enabled before, esp for kexec/kdump,
+* previous kernel already enable that. otherwise memset called
+* by allocate_aperture/__alloc_bootmem_nopanic cause restart.
+* or second kernel have different position for GART hole. and new
+* kernel could use hole as RAM that is still used by GART set by
+* first kernel
+*/
+ int fix, num;
+ u32 ctl;
+ u32 aper_size, aper_alloc = 0, aper_order = 0, last_aper_order = 0;
+ u64 aper_base, last_aper_base = 0;
+ int valid_agp = 0;
+
+ if (!early_pci_allowed())
+ return;
+
+ fix = 0;
+ for (num = 24; num < 32; num++) {
+ if (!early_is_k8_nb(read_pci_config(0, num, 3, 0x00)))
+ continue;
+
+ aper_order = (read_pci_config(0, num, 3, 0x90) >> 1) & 7;
+ aper_size = (32 * 1024 * 1024) << aper_order;
+ aper_base = read_pci_config(0, num, 3, 0x94) & 0x7fff;
+ aper_base <<= 25;
+
+ if (!aperture_valid(aper_base, aper_size)) {
+ fix = 1;
+ break;
+ }
+
+ if ((last_aper_order && aper_order != last_aper_order) ||
+ (last_aper_base && aper_base != last_aper_base)) {
+ fix = 1;
+ break;
+ }
+ last_aper_order = aper_order;
+ last_aper_base = aper_base;
+ }
+
+ if (!fix)
+ return;
+
+ aper_alloc = search_agp_bridge(_order, _agp);
+
+ if (aper_alloc) {
+ /*
+* could get aper later or before from the AGP bridge,
+* so it is safe
+*/
+ return;
+ }
+
+ for (num = 24; num < 32; num++) {
+ if (!early_is_k8_nb(read_pci_config(0, num, 3, 0x00)))
+ continue;
+
+ ctl = read_pci_config(0, num, 3, 0x90);
+ ctl &= ~1;
+ write_pci_config(0, num, 3, 0x90, ctl);
+ }
+
+}
+
void __init gart_iommu_hole_init(void)
{
u32 aper_size, aper_alloc = 0, aper_order = 0, last_aper_order = 0;
diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
index 998ce03..da82065 100644
--- a/arch/x86/kernel/setup_64.c
+++ b/arch/x86/kernel/setup_64.c
@@ -54,6 +54,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -358,6 +359,8 @@ void __init setup_arch(char **cmdline_p)
discover_ebda();
+ early_gart_iommu_disable();
+
init_memory_mapping(0, (end_pfn_map << PAGE_SHIFT));
if (efi_enabled)
efi_init();
diff --git a/include/asm-x86/gart.h b/include/asm-x86/gart.h
index f704c50..2ca68c6 100644
--- a/include/asm-x86/gart.h
+++ b/include/asm-x86/gart.h
@@ -9,6 +9,7 @@ extern int iommu_detected;
extern void gart_iommu_init(void);
extern void gart_iommu_shutdown(void);
extern void __init gart_parse_options(char *);
+extern void
Re: [x86/mm] vsyscall_fn fault in early startup
* Roland McGrath <[EMAIL PROTECTED]> wrote:
> I bisected my startup problem down to:
i fixed this in my tree yesterday but was held up by another problem
from uploading it. The patch below should apply to the tree you have.
Ingo
-->
Subject: x86: fix sched_clock()
From: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
arch/x86/kernel/rtc.c | 12
include/asm-x86/msr.h | 11 ++-
2 files changed, 10 insertions(+), 13 deletions(-)
Index: linux-x86.q/arch/x86/kernel/rtc.c
===
--- linux-x86.q.orig/arch/x86/kernel/rtc.c
+++ linux-x86.q/arch/x86/kernel/rtc.c
@@ -195,15 +195,3 @@ int update_persistent_clock(struct times
{
return set_rtc_mmss(now.tv_sec);
}
-
-unsigned long long __vsyscall_fn native_read_tsc(void)
-{
- DECLARE_ARGS(val, low, high);
-
- rdtsc_barrier();
- asm volatile("rdtsc" : EAX_EDX_RET(val, low, high));
- rdtsc_barrier();
-
- return EAX_EDX_VAL(val, low, high);
-}
-EXPORT_SYMBOL_GPL(native_read_tsc);
Index: linux-x86.q/include/asm-x86/msr.h
===
--- linux-x86.q.orig/include/asm-x86/msr.h
+++ linux-x86.q/include/asm-x86/msr.h
@@ -91,7 +91,16 @@ static inline int native_write_msr_safe(
return err;
}
-extern unsigned long long native_read_tsc(void);
+static __always_inline unsigned long long native_read_tsc(void)
+{
+ DECLARE_ARGS(val, low, high);
+
+ rdtsc_barrier();
+ asm volatile("rdtsc" : EAX_EDX_RET(val, low, high));
+ rdtsc_barrier();
+
+ return EAX_EDX_VAL(val, low, high);
+}
static inline unsigned long long native_read_pmc(int counter)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] x86_64 early_idt_handler improvements
* Roland McGrath <[EMAIL PROTECTED]> wrote: > It's not too pretty, but I found this made the "PANIC: early > exception" messages become much more reliably useful: 1. print the > vector number, 2. print the %cs value, 3. handle error-code-pushing vs > non-pushing vectors. thanks, applied. since these printouts are only useful if we have early-printk capabilities enabled, i made it dependent on CONFIG_EARLY_PRINTK. I also made EARLY_PRINTK selectable on 64-bit as well. (for some unknown reason it was unconditionally built into 64-bit (unlike 32-bit where it is selectable on EMBEDDED)) Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 05/19] split LRU lists into anon & file sets
Hi Rik
> @@ -1128,64 +1026,65 @@ static void shrink_active_list(unsigned
(snip)
> + /*
> + * For sorting active vs inactive pages, we'll use the 'anon'
> + * elements of the local list[] array and sort out the file vs
> + * anon pages below.
> + */
> while (!list_empty(_hold)) {
> + lru = LRU_INACTIVE_ANON;
> cond_resched();
> page = lru_to_page(_hold);
> list_del(>lru);
> - if (page_mapped(page)) {
> - if (!reclaim_mapped ||
> - (total_swap_pages == 0 && PageAnon(page)) ||
> - page_referenced(page, 0, sc->mem_cgroup)) {
> - list_add(>lru, [LRU_ACTIVE]);
> - continue;
> - }
> - } else if (TestClearPageReferenced(page)) {
> - list_add(>lru, [LRU_ACTIVE]);
> - continue;
> - }
> - list_add(>lru, [LRU_INACTIVE]);
> + if (page_referenced(page, 0, sc->mem_cgroup))
> + lru = LRU_ACTIVE_ANON;
> + list_add(>lru, [lru]);
> }
Why drop (total_swap_pages == 0 && PageAnon(page)) condition?
in embedded sysmtem,
CONFIG_NORECLAIM is OFF (because almost embedded cpu is 32bit) and
that anon move to inactive list is meaningless because it doesn't have swap.
below code is more good, may be.
but I don't understand yet why ignore page_referenced() result at anon page ;-)
- kosaki
---
mm/vmscan.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.24-rc6-mm1-rvr/mm/vmscan.c
===
--- linux-2.6.24-rc6-mm1-rvr.orig/mm/vmscan.c 2008-01-11 13:59:12.0
+0900
+++ linux-2.6.24-rc6-mm1-rvr/mm/vmscan.c2008-01-11 16:16:44.0
+0900
@@ -1147,7 +1147,7 @@ static void shrink_active_list(unsigned
}
if (page_referenced(page, 0, sc->mem_cgroup)) {
- if (file)
+ if (file || (total_swap_pages == 0))
/* Referenced file pages stay active. */
lru = LRU_ACTIVE_ANON;
else
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: CPA patchset
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > I think you have it fundamentally backwards: the best for > > > performance is WB + cflush. What would WC offer for performance > > > that cflush cannot do? > > > > Cached requires the cache line to be read first before you can write > > it. > > nonsense, and you should know it. It is perfectly possible to > construct fully written cachelines, without reading the cacheline > first. MOVDQ is SSE1 so on basically in every CPU today - and it is 16 > byte aligned and can generate full cacheline writes, _without_ filling > in the cacheline first. Bulk ops (string ops, etc.) will do full > cacheline writes too, without filling in the cacheline. Especially > with high performance 3D ops we do _NOT_ need any funky reads from > anywhere because 3D software can stream a lot of writes out: we > construct a full frame or a portion of a frame, or upload vertices or > shader scripts, textures, etc. > > ( also, _even_ when there is a cache fill pending on for a partially > written cacheline, that might go on in parallel and it is not > necessarily holding up the CPU unless it has an actual data dependency > on that. ) btw., that's not to suggest that WC does not have its place - but it's not where you think it is. Write-Combining can be very useful for devices that are behind a slow or a high-latency transport, such as PCI, and which are mapped UnCached today. Such as a networking card (or storage card) descriptor rings. New entries in the TX ring are typically constructed on the CPU side without knowing anything about their contents (and hence no need to read them, the drivers typically shadow the ring on the host side already, it is required for good UC performance today), so the new descriptors can be streamed out efficiently with WC, instead of generating lots of small UC accesses. But these descriptor rings have constant size, they have a fixed place in the aperture and are ioremap()ed once during device init and that's it. No high-frequency change_page_attributes() usage is done or desired here. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[x86/mm] vsyscall_fn fault in early startup
I bisected my startup problem down to: 197e4989b0404996dfe3ab091c1398e4c2813d44 is first bad commit commit 197e4989b0404996dfe3ab091c1398e4c2813d44 Author: Ingo Molnar <[EMAIL PROTECTED]> Date: Wed Jan 9 13:31:06 2008 +0100 x86: mark native_read_tsc() as __vsyscall_fn Andi Kleen reported the following breakage: the 64-bit vdso faulted because native_read_tsc() is not a vsyscall-fn. Mark it as such. Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> Without that commit, it gets past early startup and boots fine, but of course then init crashes in the vDSO just as Andi reported. Apparently this one: commit 715cf488c640ef4bed6c971660251d8d6cba4fbb Author: Ingo Molnar <[EMAIL PROTECTED]> Date: Wed Jan 9 13:31:06 2008 +0100 x86: map vsyscalls early enough map vsyscalls early enough. This is important if a __vsyscall_fn function is used by other kernel code too. Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> is not really doing its job. It's not early enough for the use I'm hitting. Thanks to qemu-gdbserver, I have this handy backtrace for the early startup case even though it dies too hard to print one. 0xff60010d is really _read_tsc+0 though gdb reports the name of the preceding symbol (vread_tsc). #0 early_idt_handler () at /home/roland/redhat/linux/2.6/arch/x86/kernel/head_64.S:289 #1 0x0010 in ?? () #2 0xff60010d in vread_tsc () at /home/roland/redhat/linux/2.6/arch/x86/kernel/tsc_64.c:308 #3 0x80258cec in __lock_acquire (lock=0x806f4bf8, subclass=0, trylock=0, read=0, check=2, hardirqs_off=1, ip=18446744071564512884) at /home/roland/redhat/linux/2.6/kernel/lockdep.c:2416 #4 0x802598f2 in lock_acquire (lock=0x806ea460, subclass=1, trylock=3340, read=131072, check=-1, ip=18446744071564405679) at /home/roland/redhat/linux/2.6/kernel/lockdep.c:2703 #5 0x8054de4f in _spin_lock (lock=0x806f4be0) at /home/roland/redhat/linux/2.6/kernel/spinlock.c:180 #6 0x80254e74 in clockevents_register_notifier ( nb=0x806f4c80) at /home/roland/redhat/linux/2.6/kernel/time/clockevents.c:114 #7 0x807dc1f4 in tick_init () at /home/roland/redhat/linux/2.6/kernel/time/tick-common.c:390 #8 0x807c9811 in start_kernel () at /home/roland/redhat/linux/2.6/init/main.c:531 #9 0x807c9110 in x86_64_start_kernel ( real_mode_data=0x92dc0 ) at /home/roland/redhat/linux/2.6/arch/x86/kernel/head64.c:73 So with lockdep et al turned on, tick_init leads to native_read_tsc. setup_arch is after tick_init, so not early enough. I don't know if map_vsyscall needs too much stuff to come much earlier than it is. It might be best just to let native_read_tsc be inlined ;-) Thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: CPA patchset
* Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > but that's not too smart: why dont they use WB plus cflush > > > > instead? > > > > > > Because they need to access it WC for performance. > > > > I think you have it fundamentally backwards: the best for > > performance is WB + cflush. What would WC offer for performance that > > cflush cannot do? > > Cached requires the cache line to be read first before you can write > it. nonsense, and you should know it. It is perfectly possible to construct fully written cachelines, without reading the cacheline first. MOVDQ is SSE1 so on basically in every CPU today - and it is 16 byte aligned and can generate full cacheline writes, _without_ filling in the cacheline first. Bulk ops (string ops, etc.) will do full cacheline writes too, without filling in the cacheline. Especially with high performance 3D ops we do _NOT_ need any funky reads from anywhere because 3D software can stream a lot of writes out: we construct a full frame or a portion of a frame, or upload vertices or shader scripts, textures, etc. ( also, _even_ when there is a cache fill pending on for a partially written cacheline, that might go on in parallel and it is not necessarily holding up the CPU unless it has an actual data dependency on that. ) but that's totally besides the point anyway. WC or WB accesses, if a 3D app or a driver does high-freq change_page_attr() calls, it will _lose_ the performance game: > > also, it's irrelevant to change_page_attr() call frequency. Just map > > in everything from the card and use it. In graphics, if you remap > > anything on the fly and it's not a slowpath you've lost the > > performance game even before you began it. > > The typical case would be lots of user space DRI clients supplying > their own buffers on the fly. There's not really a fixed pool in this > case, but it all varies dynamically. In some scenarios that could > happen quite often. in what scenarios? Please give me in-tree examples of such high-freq change_page_attr() cases, where the driver authors would like to call it with high frequency but are unable to do it and see performance problems due to the WBINVD. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] XFS update for 2.6.24-rc8
Please pull from the for-linus branch: git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus This will update the following files: fs/xfs/linux-2.6/xfs_file.c | 16 ++-- 1 files changed, 10 insertions(+), 6 deletions(-) through these commits: commit aea6ad0ce5e215ce99fe9e3edd9268f696862d8f Author: Christoph Hellwig <[EMAIL PROTECTED]> Date: Thu Jan 10 16:43:26 2008 +1100 [XFS] fix unaligned access in readdir This patch should fix the issue seen on Alpha with unaligned accesses in the new readdir code. By aligning each dirent to sizeof(u64) we'll avoid unaligned accesses. To make doubly sure we're not hitting problems also rearrange struct hack_dirent to avoid holes. SGI-PV: 975411 SGI-Modid: xfs-linux-melb:xfs-kern:30302a Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]> Signed-off-by: Lachlan McIlroy <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64 early_idt_handler improvements
Probably true that it's not worth the space. I couldn't figure a way to do it that doesn't use at least 8 bytes per vector. Of course, the vectors >= 32 are never interesting, so 256 bytes of dispatch table could cover it. Anyway, I think it's fine just to have the patch on hand to enable for a particular debugging session, which is what I wrote it for. Maybe it could be a config option. Thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On Fri, 11 Jan 2008 02:19:07 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: > > I see a PnP resume _consists_ of setting the resources so I can see the test > implementation wise, but yes, conceptually it seems this test shouldn't be > present. So just like the attached then? > > Pierre, what was the idea here? Added the other SOBs to the CC as well... > You assume there was an idea? ;) I don't remember why things were done the way they were. And I can't find any clues in the correspondence around the issue. So your guess is as good as mine. Rgds Pierre signature.asc Description: PGP signature
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
At Thu, 10 Jan 2008 23:02:53 +0100, Harald Dunkel wrote: > > Takashi Iwai wrote: > > > > Hm... Just to be sure, try the patch below. It's a clean up patch > > that I'd like to apply later. > > > > Sorry, no sound. OK, but I'd like to know whether this makes no regression to rc6. Could you check? Also, what exactly did you test? "No sound" means that no sound from the headphone / line-out or from the speaker? One interesting test would be to increase the value of udelay() in the reverted patch. What happens if it's set to 500? > > The perex/alsa.git mm branch on kernel.org has many fixes. Could you > > give it a try, too? > > > > This version seems to work. But AFAICS it just reverts hda_intel.c back > to rc6 again, so this is no surprise. Use mm branch. The main branch is just an old Linus tree. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: 100% io-wait with 2.6.24-rcX
Am Freitag, 11. Januar 2008 schrieb Joerg Platte: > konqueror 987jplatte mem REG8,6 2590525 > 1336104 /var/tmp/kdecache-jplatte/ksycoca > konqueror 987jplatte 12r REG8,6 2590525 > 1336104 /var/tmp/kdecache-jplatte/ksycoca > konqueror 987jplatte 13u REG8,7 579 > 97731 /tmp/kde-jplatte/konqueror-crash-Jv2u8a.log > konqueror 987jplatte 14u REG8,7 128289 > 97734 /tmp/kde-jplatte/khtmlcacheA7VjAa.tmp (deleted) > konqueror 987jplatte 16u REG8,743334 > 97750 /tmp/kde-jplatte/khtmlcacheZUNlsc.tmp (deleted) > konqueror 987jplatte 22u REG8,7 797 > 97751 /tmp/kde-jplatte/khtmlcache76bZYa.tmp (deleted) > konqueror 987jplatte 27u REG8,7 102347 > 97735 /tmp/kde-jplatte/khtmlcacheMhlDJb.tmp (deleted) > konqueror 987jplatte 31u REG8,7 354 > 97738 /tmp/kde-jplatte/khtmlcacheq21uoc.tmp (deleted) > konqueror 987jplatte 32u REG8,7 1360 > 97742 /tmp/kde-jplatte/khtmlcacheo2Ms2a.tmp (deleted) > konqueror 987jplatte 34u REG8,7 6378 > 97745 /tmp/kde-jplatte/khtmlcacheLETtgc.tmp (deleted) > konqueror 987jplatte 35u REG8,797350 > 97746 /tmp/kde-jplatte/khtmlcache5jit8a.tmp (deleted) > konqueror 987jplatte 36u REG8,7 354 > 97747 /tmp/kde-jplatte/khtmlcache7VBSNa.tmp (deleted) > konqueror 987jplatte 37u REG8,7 1360 > 97748 /tmp/kde-jplatte/khtmlcachetSNbub.tmp (deleted) > konqueror 987jplatte 38u REG8,7 6073 > 97749 /tmp/kde-jplatte/khtmlcacheKAKhuc.tmp (deleted) Fengguang, a few minutes after killing this konqueror process the high iowait load has disappeared. Lets see if it'll come back... regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 001/001] ipv4: enable use of 240/4 address space
From: Vince Fuller <[EMAIL PROTECTED]> Date: Mon, 7 Jan 2008 17:10:57 -0800 > from Vince Fuller <[EMAIL PROTECTED]> > > This set of diffs modify the 2.6.20 kernel to enable use of the 240/4 > (aka "class-E") address space as consistent with the Internet Draft > draft-fuller-240space-00.txt. > > Signed-off-by: Vince Fuller <[EMAIL PROTECTED]> There has been more than 90K worth of changes to the files you are changing since 2.6.20 It is generally unwise to submit patches against such old kernel versions, they rarely apply, so please respin your patch against more current sources. Please also remove the trailing whitespace, like the one found here: +#defineIN_CLASSE_HOST (0x & ~IN_CLASSE_NET) + +/* ^ Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64 early_idt_handler improvements
Roland McGrath <[EMAIL PROTECTED]> writes: > It's not too pretty, but I found this made the "PANIC: early exception" > messages become much more reliably useful: 1. print the vector number, > 2. print the %cs value, 3. handle error-code-pushing vs non-pushing vectors. For what do you need cs? It should be always the same for early boot. > > Signed-off-by: Roland McGrath <[EMAIL PROTECTED]> > --- > arch/x86/kernel/head64.c |6 -- > arch/x86/kernel/head_64.S | 34 ++ > 2 files changed, 34 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c > index 4a1c135..000 100644 > --- a/arch/x86/kernel/head64.c > +++ b/arch/x86/kernel/head64.c > @@ -48,6 +48,8 @@ static void __init copy_bootdata(char *r > } > } > > +extern const char early_idt_handlers[IDT_ENTRIES][10]; I don't think that minor improvement is worth that much memory (several KB for the array and some more for all the handlers) Also in my experience it is not that difficult to work out from which vector the exception came from. There are not that many variants anyways; it's near always #GP or #PF. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] constify the name passed to platform_device_register_simple
This name is just passed to platform_device_alloc which has its parameter
declared const.
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
drivers/base/platform.c |2 +-
include/linux/platform_device.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index fb56092..3408699 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -360,7 +360,7 @@ EXPORT_SYMBOL_GPL(platform_device_unregister);
* the Linux driver model. In particular, when such drivers are built
* as modules, they can't be "hotplugged".
*/
-struct platform_device *platform_device_register_simple(char *name, int id,
+struct platform_device *platform_device_register_simple(const char *name, int
id,
struct resource *res,
unsigned int num)
{
struct platform_device *pdev;
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index e808043..3261681 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -35,7 +35,7 @@ extern struct resource *platform_get_resource_byname(struct
platform_device *, u
extern int platform_get_irq_byname(struct platform_device *, char *);
extern int platform_add_devices(struct platform_device **, int);
-extern struct platform_device *platform_device_register_simple(char *, int id,
+extern struct platform_device *platform_device_register_simple(const char *,
int id,
struct resource *, unsigned int);
extern struct platform_device *platform_device_alloc(const char *name, int id);
--
1.5.3.8
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 05/19] split LRU lists into anon & file sets
Hi Rik
> +static inline int is_file_lru(enum lru_list l)
> +{
> + BUILD_BUG_ON(LRU_INACTIVE_FILE != 2 || LRU_ACTIVE_FILE != 3);
> + return (l/2 == 1);
> +}
below patch is a bit cleanup proposal.
i think LRU_FILE is more clarify than "/2".
What do you think it?
Index: linux-2.6.24-rc6-mm1-rvr/include/linux/mmzone.h
===
--- linux-2.6.24-rc6-mm1-rvr.orig/include/linux/mmzone.h2008-01-11
11:10:30.0 +0900
+++ linux-2.6.24-rc6-mm1-rvr/include/linux/mmzone.h 2008-01-11
14:40:31.0 +0900
@@ -147,7 +147,7 @@
static inline int is_file_lru(enum lru_list l)
{
BUILD_BUG_ON(LRU_INACTIVE_FILE != 2 || LRU_ACTIVE_FILE != 3);
- return (l/2 == 1);
+ return !!(l & LRU_FILE);
}
struct per_cpu_pages {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][FIX] Bluetooth: always send explicit hci_ll wake-up acks
From: Ohad Ben-Cohen <[EMAIL PROTECTED]> Date: Mon, 7 Jan 2008 18:22:48 +0200 (IST) > In the (rare) event of simultaneous mutual wake up requests, > do send the chip an explicit wake-up ack. This is required > for Texas Instruments's BRF6350 chip. > > Signed-off-by: Ohad Ben-Cohen <[EMAIL PROTECTED]> Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] split MMC_CAP_4_BIT_DATA
On Jan 11, 2008 1:17 AM, Bryan Wu <[EMAIL PROTECTED]> wrote: > On Jan 10, 2008 7:57 PM, Pierre Ossman <[EMAIL PROTECTED]> wrote: > > On Thu, 10 Jan 2008 17:22:55 +0800 > > "Bryan Wu" <[EMAIL PROTECTED]> wrote: > > > > > > > > At page 4-3 of ADSP-BF54x Blackfin(R) Processor Peripheral Hardware > > > Reference, there is a table which guide us the SDH controller does not > > > support 4-bit mode MMC card. Please found the table picture in the > > > attachment or get the document at: > > > http://www.analog.com/UploadedFiles/Associated_Docs/61460151169789ADSP_BF54x_Blackfin_Processor_Peripheral_Hardware_Reference.pdf > > > > > > > Ok, but this just means the controller wasn't designed with 4-bit MMC in > > mind. As several other "SD-only" controller have been tested with modern > > MMC cards without a problem, this is not sufficient to explain any problem. > > > > This should be some HW design issue and BF54x including SDH controller > is in mass production. > There is no chance to change the silicon, we just wanna use software > driver to workaround this issue. > So Mike's patch is here. > > > > > > > Thanks, actually we are not yet convinced by our hardware designer > > > why BF54x SDH does not support 4-bit MMC. > > > > > > > Please keep me informed on how it progresses. I'd like an at least > > plausible explanation, preferably also some empirical data, before I'm > > ready to accept Mike's patch. > > > > We were told this is an hardware design issue, so please help us to > workaround it in software side with Mike's patch. > And how do you think my suggestion to Mike's patch, > #define MMC_CAP_4_BIT_DATA ( MMC_CAP_SD_4_BIT_DATA | MMC_CAP_MMC_4_BIT_DATA) > Then no need to change other MMC host drivers i can send an updated patch as needed. i think Bryan's suggestion here is a good one. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bluetooth : rfcomm tty BUG_ON() code fix
From: Dave Young <[EMAIL PROTECTED]> Date: Mon, 7 Jan 2008 13:41:22 +0800 > 1) In tty.c the BUG_ON at line 115 will never be called, because the the > before list_del_init in this same function. > 115 BUG_ON(!list_empty(>list)); > So move the list_del_init to rfcomm_dev_del > > 2) The rfcomm_dev_del could be called from diffrent path > (rfcomm_tty_hangup/rfcomm_dev_state_change/rfcomm_release_dev), > So add another BUG_ON when the rfcomm_dev_del is called more than one time. > > Signed-off-by: Dave Young <[EMAIL PROTECTED]> Applied, thanks 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] split MMC_CAP_4_BIT_DATA
On Jan 10, 2008 7:57 PM, Pierre Ossman <[EMAIL PROTECTED]> wrote: > On Thu, 10 Jan 2008 17:22:55 +0800 > "Bryan Wu" <[EMAIL PROTECTED]> wrote: > > > > > At page 4-3 of ADSP-BF54x Blackfin(R) Processor Peripheral Hardware > > Reference, there is a table which guide us the SDH controller does not > > support 4-bit mode MMC card. Please found the table picture in the > > attachment or get the document at: > > http://www.analog.com/UploadedFiles/Associated_Docs/61460151169789ADSP_BF54x_Blackfin_Processor_Peripheral_Hardware_Reference.pdf > > > > Ok, but this just means the controller wasn't designed with 4-bit MMC in > mind. As several other "SD-only" controller have been tested with modern MMC > cards without a problem, this is not sufficient to explain any problem. > This should be some HW design issue and BF54x including SDH controller is in mass production. There is no chance to change the silicon, we just wanna use software driver to workaround this issue. So Mike's patch is here. > > > > Thanks, actually we are not yet convinced by our hardware designer > > why BF54x SDH does not support 4-bit MMC. > > > > Please keep me informed on how it progresses. I'd like an at least plausible > explanation, preferably also some empirical data, before I'm ready to accept > Mike's patch. > We were told this is an hardware design issue, so please help us to workaround it in software side with Mike's patch. And how do you think my suggestion to Mike's patch, #define MMC_CAP_4_BIT_DATA ( MMC_CAP_SD_4_BIT_DATA | MMC_CAP_MMC_4_BIT_DATA) Then no need to change other MMC host drivers Thanks Regards, -Bryan Wu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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_64 early_idt_handler improvements
It's not too pretty, but I found this made the "PANIC: early exception"
messages become much more reliably useful: 1. print the vector number,
2. print the %cs value, 3. handle error-code-pushing vs non-pushing vectors.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/head64.c |6 --
arch/x86/kernel/head_64.S | 34 ++
2 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 4a1c135..000 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -48,6 +48,8 @@ static void __init copy_bootdata(char *r
}
}
+extern const char early_idt_handlers[IDT_ENTRIES][10];
+
void __init x86_64_start_kernel(char * real_mode_data)
{
int i;
@@ -59,7 +61,7 @@ void __init x86_64_start_kernel(char * r
zap_identity_mappings();
for (i = 0; i < IDT_ENTRIES; i++)
- set_intr_gate(i, early_idt_handler);
+ set_intr_gate(i, _idt_handlers[i]);
load_idt((const struct desc_ptr *)_descr);
early_printk("Kernel alive\n");
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index c31b1c9..000 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -267,14 +267,40 @@ init_rsp:
bad_address:
jmp bad_address
+.macro early_idt_tramp first, last
+ .ifgt \last-\first
+ early_idt_tramp \first, \last-1
+ .endif
+ movl $\last,%esi
+ jmp early_idt_handler
+.endm
+
+ .globl early_idt_handlers
+early_idt_handlers:
+ early_idt_tramp 0, 63
+ early_idt_tramp 64, 127
+ early_idt_tramp 128, 191
+ early_idt_tramp 192, 255
+
ENTRY(early_idt_handler)
cmpl $2,early_recursion_flag(%rip)
jz 1f
incl early_recursion_flag(%rip)
- xorl %eax,%eax
- movq 8(%rsp),%rsi # get rip
- movq (%rsp),%rdx
GET_CR2_INTO_RCX
+ movq %rcx,%r9
+ xorl %r8d,%r8d # zero for error code
+ movl %esi,%ecx # get vector number
+ # Test %ecx against mask of vectors that push error code.
+ cmpl $31,%ecx
+ ja 0f
+ movl $1,%eax
+ salq %cl,%rax
+ testl $0x27d00,%eax
+ je 0f
+ popq %r8# get error code
+0: movq 0(%rsp),%rcx # get ip
+ movq 8(%rsp),%rdx # get cs
+ xorl %eax,%eax
leaq early_idt_msg(%rip),%rdi
call early_printk
cmpl $2,early_recursion_flag(%rip)
@@ -291,7 +317,7 @@ early_recursion_flag:
.long 0
early_idt_msg:
- .asciz "PANIC: early exception rip %lx error %lx cr2 %lx\n"
+ .asciz "PANIC: early exception %02lx rip %lx:%lx error %lx cr2 %lx\n"
early_idt_ripmsg:
.asciz "RIP %s\n"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: 100% io-wait with 2.6.24-rcX
Am Freitag, 11. Januar 2008 schrieb Fengguang Wu: > Joerg, what's the output of `dumpe2fs /dev/sda7` and `lsof|grep /tmp`? Fengang, here is the output (kernel 2.6.24-rc7 without your patches): Filesystem volume name: TMP Last mounted on: Filesystem UUID: e23ae961-bbdc-44bc-b662-f28f7314939b Filesystem magic number: 0xEF53 Filesystem revision #:1 (dynamic) Filesystem features: has_journal resize_inode dir_index filetype sparse_super large_file Filesystem flags: signed directory hash Default mount options:(none) Filesystem state: not clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 244320 Block count: 487966 Reserved block count: 24398 Free blocks: 468728 Free inodes: 244162 First block: 0 Block size: 4096 Fragment size:4096 Reserved GDT blocks: 119 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 16288 Inode blocks per group: 509 Filesystem created: Thu Feb 8 18:46:19 2007 Last mount time: Thu Jan 10 11:09:35 2008 Last write time: Fri Jan 11 06:12:58 2008 Mount count: 25 Maximum mount count: 39 Last checked: Tue Dec 11 22:07:03 2007 Check interval: 15552000 (6 months) Next check after: Sun Jun 8 23:07:03 2008 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Journal inode:8 Default directory hash: tea Directory Hash Seed: 79e271e9-b874-4e11-92b0-cdb36d07e1c1 Journal backup: inode blocks Journal size: 32M Group 0: (Blocks 0-32767) Primary superblock at 0, Group descriptors at 1-1 Reserved GDT blocks at 2-120 Block bitmap at 121 (+121), Inode bitmap at 122 (+122) Inode table at 123-631 (+123) 23926 free blocks, 16275 free inodes, 2 directories Free blocks: 638-10239, 16384, 18444-30719, 30721-32767 Free inodes: 14-16288 Group 1: (Blocks 32768-65535) Backup superblock at 32768, Group descriptors at 32769-32769 Reserved GDT blocks at 32770-32888 Block bitmap at 32889 (+121), Inode bitmap at 32890 (+122) Inode table at 32891-33399 (+123) 32135 free blocks, 16287 free inodes, 1 directories Free blocks: 33400-57343, 57345-65535 Free inodes: 16290-32576 Group 2: (Blocks 65536-98303) Block bitmap at 65536 (+0), Inode bitmap at 65537 (+1) Inode table at 65538-66046 (+2) 32256 free blocks, 16286 free inodes, 1 directories Free blocks: 66047-96255, 96257-98303 Free inodes: 32579-48864 Group 3: (Blocks 98304-131071) Backup superblock at 98304, Group descriptors at 98305-98305 Reserved GDT blocks at 98306-98424 Block bitmap at 98425 (+121), Inode bitmap at 98426 (+122) Inode table at 98427-98935 (+123) 32135 free blocks, 16286 free inodes, 1 directories Free blocks: 98936-120831, 120833-131071 Free inodes: 48867-65152 Group 4: (Blocks 131072-163839) Block bitmap at 131072 (+0), Inode bitmap at 131073 (+1) Inode table at 131074-131582 (+2) 32256 free blocks, 16287 free inodes, 1 directories Free blocks: 131583-133119, 133121-163839 Free inodes: 65154-81440 Group 5: (Blocks 163840-196607) Backup superblock at 163840, Group descriptors at 163841-163841 Reserved GDT blocks at 163842-163960 Block bitmap at 163961 (+121), Inode bitmap at 163962 (+122) Inode table at 163963-164471 (+123) 32135 free blocks, 16286 free inodes, 1 directories Free blocks: 164472-182271, 182273-196607 Free inodes: 81443-97728 Group 6: (Blocks 196608-229375) Block bitmap at 196608 (+0), Inode bitmap at 196609 (+1) Inode table at 196610-197118 (+2) 32087 free blocks, 16265 free inodes, 1 directories Free blocks: 197119-200703, 200705-210943, 210945-210951, 210970-210975, 210988-215039, 215041-215047, 215058-215071, 215090-217087, 217089-219135, 219137-219143, 219177-219199, 219226-219255, 219257-219263, 219265-219271, 219274-219279, 219305-219335, 219337-219343, 219345-219351, 219354-219359, 219371-219383, 219385-227327, 227331-229375 Free inodes: 97752-114016 Group 7: (Blocks 229376-262143) Backup superblock at 229376, Group descriptors at 229377-229377 Reserved GDT blocks at 229378-229496 Block bitmap at 229497 (+121), Inode bitmap at 229498 (+122) Inode table at 229499-230007 (+123) 32134 free blocks, 16278 free inodes, 1 directories Free blocks: 230008-253951, 253953-260095, 260097-262143 Free inodes: 114022, 114025-114027, 114031-130304 Group 8: (Blocks 262144-294911) Block bitmap at 262144 (+0), Inode bitmap at 262145 (+1) Inode table at 262146-262654 (+2) 29809 free blocks, 16193 free inodes, 17 directories Free blocks: 262661-264191, 264244, 264250, 264263, 264272, 264281, 264288-266239, 266870-266871, 266877-268287, 268289-270335, 270965-274431, 274434-282623, 282625-290815, 291897-292863,
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
Alexander wrote: Hello! The problem described at https://bugzilla.redhat.com/show_bug.cgi?id=351451 and at http://ubuntuforums.org/showthread.php?t=655772 and supposedly fixed by the patch http://kerneltrap.org/mailarchive/linux-kernel/2007/11/25/445094 is still there. I have compiled 2.6.24-rc7 kernel and booted my PC with it just to find out that my SATA DVD-RW is There's this patch which was intended to fix it: http://lkml.org/lkml/2007/11/22/148 which hasn't been merged yet. I see now that there was some further discussion from someone saying that didn't fix the problem for them, which I wasn't CCed on.. It looks like in their case, libata is receiving SGs with DMA addresses above 4GB even though the block layer bounce limit is set to 32-bit. That's the mechanism that sata_nv depends on to ensure that it gets proper addresses when accessing ATAPI devices where it is limited to 32-bit DMA.. Could that be breaking or insufficient somehow? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bsg : Add support for io vectors in bsg
On Thu, 10 Jan 2008 16:46:05 -0500 Pete Wyckoff <[EMAIL PROTECTED]> wrote: > Is there another async I/O mechanism? Userspace builds the CDBs, > just needs some way to drop them in SCSI ML. BSG is almost perfect > for this, but doesn't do iovec, leading to lots of memcpy. syslets? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: 100% io-wait with 2.6.24-rcX
On Thu, Jan 10, 2008 at 11:03:05AM +0100, Joerg Platte wrote: > Am Donnerstag, 10. Januar 2008 schrieb Fengguang Wu: > > > problem, because the iowait problem disappeared today after the regular > > > Debian update. I'll try to install the old package versions to make it > > > show up again. Maybe that helps to debug it. > > > > Thank you. I'm running sid, ext2 as rootfs now ;-) > > The error is back and I'm getting thousands of messages like this with the > patched kernel: > > mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3936 0 0 wc _M > > tw 1024 sk 0 > requeue_io 301: inode 81441 size 0 at 08:07(sda7) > mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3936 0 0 wc _M > > tw 1024 sk 2 > requeue_io 301: inode 81441 size 0 at 08:07(sda7) > mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3936 0 0 wc _M > > tw 1024 sk 2 > requeue_io 301: inode 81441 size 0 at 08:07(sda7) Joerg, what's the output of `dumpe2fs /dev/sda7` and `lsof|grep /tmp`? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: More breakage in native_rdtsc out of line in git-x86
On Jan 10, 2008 2:37 AM, Paolo Ciarrocchi <[EMAIL PROTECTED]> wrote: > On 1/10/08, Andi Kleen <[EMAIL PROTECTED]> wrote: > > > I'm already cloning the branches; the problem is not getting conflicts etc. > > when updating. > > Isn't git pull --force what you are looking for? > > Ciao, > -- > Paolo > http://paolo.ciarrocchi.googlepages.com/ > Actually...no, it wouldn't help. Conflicts will coming up and only the solution for now is to use remote tracking as Harvey wrote in prev mail. (btw, git pull that would not conflict is when it called with '-s ours' but that is not good) - Cyrill - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it possible to change IRQ for certain device?
Jan Marek wrote: Hello lkml, I have problem with my computer: I have motherboard with AMD690G chipset and nVidia VGA card. But I cannot set BIOS, to assign for VGA unique IRQ. VGA card is sharing IRQ with two ohci_hcd (USB 1.1 controllers). But when I want use for X proprietary nvidia driver, X didn't work with this errors: In dmesg: NVRM: RmInitAdapter failed! (0x23:0x:678) NVRM: rm_init_adapter(0) failed and in /var/log/Xorg.0.log: (II) Setting vga for screen 0. (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32 (==) NVIDIA(0): RGB weight 888 (==) NVIDIA(0): Default visual is TrueColor (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0) (**) NVIDIA(0): Enabling RENDER acceleration (II) NVIDIA(0): Support for GLX with the Damage and Composite X extensions is (II) NVIDIA(0): enabled. (EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device PCI:1:0:0. (EE) NVIDIA(0): Please see the COMMON PROBLEMS section in the README for (EE) NVIDIA(0): additional information. (EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device! (EE) NVIDIA(0): *** Aborting *** (II) UnloadModule: "nvidia" (II) UnloadModule: "fb" (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found I've found in README for NVIDIA, that VGA has to have unique IRQ. I've tried to set INTERRUPT_LINE and INTERRUPT_PIN with setpci tool, set pci=routeirq, pci=noacpi as the kernel boot parameters, but IRQ is still the same. Is there a way to change IRQ for VGA (or for ohci_hcd instead of VGA) directly in Linux? The kernel has no control over IRQ assignments. Often they are hardwired in the motherboard and can't be changed at all. You could check for any relevant BIOS settings (Assign IRQ to VGA, also see if it has an APIC mode setting that needs to be enabled). -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: INITIO scsi driver fails to work properly
On Fri, 2008-01-04 at 02:18 +0200, Filippos Papadopoulos wrote:
> First of all let me wish a happy new year.
> I come back from the vacations and i compiled the initio driver with
>
> #define DEBUG_INTERRUPT 1
> #define DEBUG_QUEUE 1
> #define DEBUG_STATE 1
> #define INT_DISC1
>
> I used the sources from 2.6.24-rc6-git9 kernel. At kernel boot time the initio
> driver prints the following:
>
> " scsi: Initio INI-9X00U/UW SCSI device driver
> Find scb at c0c0
> Append pend scb c0c0;"
>
> After 3 seconds the whole system freezes there and i have to reboot.
>
>
>
> P.S here is the info from 'lspci -vv' running 2.6.16.13 kernel:
>
> "00:08.0 SCSI storage controller: Initio Corporation 360P (rev 02)
> Subsystem: Unknown device 9292:0202
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
> >TAbort- SERR- Latency: 32, Cache Line Size 08
> Interrupt: pin A routed to IRQ 11
> Region 0: I/O ports at d000 [size=256]
This proves the BAR0 to be non zero, but I also take it from your report
that the
initio: I/O port range 0x0 is busy.
message is also gone?
> Region 1: Memory at ef00 (32-bit, non-prefetchable) [size=4K]
> [virtual] Expansion ROM at 5000 [disabled] [size=128K]
> "
I think there's still one remaining bug from the sg_list conversion,
namely that cblk->sglen is never set, but it is used to count the number
of elements in the sg array. Could you try this patch (on top of
everything else) and see if the problem is finally fixed?
Thanks,
James
---
diff --git a/drivers/scsi/initio.c b/drivers/scsi/initio.c
index 01bf018..d038459 100644
--- a/drivers/scsi/initio.c
+++ b/drivers/scsi/initio.c
@@ -2603,6 +2603,7 @@ static void initio_build_scb(struct initio_host * host,
struct scsi_ctrl_blk * c
nseg = scsi_dma_map(cmnd);
BUG_ON(nseg < 0);
if (nseg) {
+ cblk->sglen = nseg;
dma_addr = dma_map_single(>pci_dev->dev, >sglist[0],
sizeof(struct sg_entry) *
TOTAL_SG_ENTRY,
DMA_BIDIRECTIONAL);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 0/3] UCC TDM driver for MPC83xx platforms
Hello All
I am waiting for more feedback on the patches.
If there are no objections please consider them for 2.6.25.
With Regards
Poonam
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Aggrwal Poonam
Sent: Monday, December 10, 2007 5:23 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Gala Kumar
Cc: Barkowski Michael; Phillips Kim; Kalra Ashish; Cutler Richard
Subject: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
There are three patches
[PATCH 1/3] drivers/misc : UCC TDM driver for mpc83xx platforms. This
driver is usable in VoIP iind of applications to interface with SLIC
kind of devices to exchange TDM voice samples.
[PATCH 2/3] arch/ : Platform changes
- device tree entries for UCC TDM driver for MPC8323ERDB platform.
- QE changes related to TDM , like,
1) Modified ucc_fast_init so that it can be used by fast UCC
based TDM driver. Mainly changes have been made to configure TDM clocks
and Fsyncs.
2) Modified get_brg_clk so that it can return the input frequncy
and input source of any BRG by reading the corresponding entries from
device tree.
3) Added new nodes brg and clocks in the device tree which
represent input clocks for different BRGs.
4) Modified qe_setbrg accordingly.
- new device tree entries added for "clocks" and "brg"
[PATCH 3/3] Documentation
- Modified Documentation to explain the device tree entries related to
UCC TDM driver and the new nodes added("clocks" and "brg")
The patch applies over a merge of galak's for-2.6.25 plus for-2.6.24
plus of_doc_update branches.
In brief the steps were
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
powerpc-galak git checkout -b for-2.6.25 origin/for-2.6.25 git checkout
-b for-2.6.24 origin/for-2.6.24 git checkout -b of_doc_update
origin/of_doc_update
git pull . for-2.6.24# merge the other two
git pull . for-2.6.25
git checkout -b tdm # clean slate for tdm rebase work
Also after applying the patches changes have to be made corresponding to
Tabi's patch "qe: add function qe_clock_source".
The driver has been tested with a VoIP stack and application on
MPC8323ERDB.
With Regards
Poonam
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the
body of a message to [EMAIL PROTECTED] More majordomo info at
http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: r8169 and out of space
Francois Romieu wrote: Alistair John Strachan <[EMAIL PROTECTED]> : [..] No, we have not diagnosed the cause of the problem, beyond the swiotlb usage. I'm adding the r8169 maintainer, linux-net and linux-kernel to CC, to pass on your information, I hope you don't mind. swiotlb fragmentation perhaps ? Switching the driver to be page based on Rx would help then. [...] I have a Abit AB9 Pro motherboard with Intel P965 chipset, 4gb of memory, and two onboard r8169. Which r8169 model exactly ? I seem to have been wrong about the kernel update fixing my mtu issue. I am not 100% sure, but I think 7200 works if the forcedeth system is sending, but not if the r8169 system is sending. I tried a mtu of 3000, and basically the same errors, but I did noticed something interesting. Note the three different byte sizes. DMA: Out of SW-IOMMU space for 2410 bytes at device :03:00.0 DMA: Out of SW-IOMMU space for 3014 bytes at device :03:00.0 DMA: Out of SW-IOMMU space for 3014 bytes at device :03:00.0 DMA: Out of SW-IOMMU space for 3022 bytes at device :03:00.0 On a side note, leaving the mtu at 1500 seems to work without error, and I get about the same performance. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 0/3] UCC TDM driver for MPC83xx platforms
Hello All
I am waiting for more feedback on the patches.
If there are no objections please consider them for 2.6.25.
With Regards
Poonam
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Aggrwal Poonam
Sent: Monday, December 10, 2007 5:23 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Gala Kumar
Cc: Barkowski Michael; Phillips Kim; Kalra Ashish; Cutler Richard
Subject: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
There are three patches
[PATCH 1/3] drivers/misc : UCC TDM driver for mpc83xx platforms. This
driver is usable in VoIP iind of applications to interface with SLIC
kind of devices to exchange TDM voice samples.
[PATCH 2/3] arch/ : Platform changes
- device tree entries for UCC TDM driver for MPC8323ERDB platform.
- QE changes related to TDM , like,
1) Modified ucc_fast_init so that it can be used by fast UCC
based TDM driver. Mainly changes have been made to configure TDM clocks
and Fsyncs.
2) Modified get_brg_clk so that it can return the input frequncy
and input source of any BRG by reading the corresponding entries from
device tree.
3) Added new nodes brg and clocks in the device tree which
represent input clocks for different BRGs.
4) Modified qe_setbrg accordingly.
- new device tree entries added for "clocks" and "brg"
[PATCH 3/3] Documentation
- Modified Documentation to explain the device tree entries related to
UCC TDM driver and the new nodes added("clocks" and "brg")
The patch applies over a merge of galak's for-2.6.25 plus for-2.6.24
plus of_doc_update branches.
In brief the steps were
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
powerpc-galak git checkout -b for-2.6.25 origin/for-2.6.25 git checkout
-b for-2.6.24 origin/for-2.6.24 git checkout -b of_doc_update
origin/of_doc_update
git pull . for-2.6.24# merge the other two
git pull . for-2.6.25
git checkout -b tdm # clean slate for tdm rebase work
Also after applying the patches changes have to be made corresponding to
Tabi's patch "qe: add function qe_clock_source".
The driver has been tested with a VoIP stack and application on
MPC8323ERDB.
With Regards
Poonam
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the
body of a message to [EMAIL PROTECTED] More majordomo info at
http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 10/19] No Reclaim LRU Infrastructure
Hi Rik > +config NORECLAIM > + bool "Track non-reclaimable pages (EXPERIMENTAL; 64BIT only)" > + depends on EXPERIMENTAL && 64BIT > + help > + Supports tracking of non-reclaimable pages off the [in]active lists > + to avoid excessive reclaim overhead on large memory systems. Pages > + may be non-reclaimable because: they are locked into memory, they > + are anonymous pages for which no swap space exists, or they are anon > + pages that are expensive to unmap [long anon_vma "related vma" list.] Why do you select to default is NO ? I think this is really improvement and no one of 64bit user hope turn off without NORECLAIM developer :) - kosaki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Make the 32 bit Frame Pointer backtracer fall back to traditional
On Thu, 10 Jan 2008 08:36:57 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 9 Jan 2008, Arjan van de Ven wrote:
> >
> > + if (valid_stack_ptr(tinfo, frame, sizeof(*frame)))
> > + while (valid_stack_ptr(tinfo, frame,
> > sizeof(*frame))) {
>
> Why?
>
> Why not just make this something like the appended instead?
ok having poked at this a ton more (and thought about it during a bori^long
meeting),
your approach is really hard to make work nicely with things like irq stacks.
HOWEVER, we can do even better! (well in my tired opinion anyway)
What I like most so far is the following idea: We walk the stack using BOTH
methods,
and just mark the entries we find as either "reliable as per stack frames" or
as "unreliable".
This way we walk the entire stack, get all the data no matter how corrupt EBP
or the frames end up,
yet we do get an indication on which parts are probably noise for the case of a
reliable stack
frame setup.
I coded it, it's not all that bad, the output looks like:
Pid: 0, comm: swapper Not tainted 2.6.24-rc7 #17
[] show_trace_log_lvl+0x1a/0x2f
[] show_trace+0x12/0x14
[] dump_stack+0x6a/0x70
[] backtrace_test_timer+0x23/0x25 [backtracetest]
[] run_timer_softirq+0x11b/0x17c
[] .backtrace_test_timer+0x0/0x25 [backtracetest]
[] .trace_hardirqs_on+0x101/0x13b
[] .backtrace_test_timer+0x0/0x25 [backtracetest]
[] __do_softirq+0x42/0x94
[] do_softirq+0x50/0xb6
[] .handle_edge_irq+0x0/0xfa
[] irq_exit+0x37/0x67
[] do_IRQ+0x9a/0xaf
[] common_interrupt+0x2e/0x34
[] .write_watchdog_counter32+0x5/0x48
[] .acpi_idle_enter_simple+0x167/0x1da
[] cpuidle_idle_call+0x52/0x78
[] cpu_idle+0x46/0x60
[] rest_init+0x43/0x45
[] start_kernel+0x279/0x27f
[] .unknown_bootoption+0x0/0x1a4
===
where I used a "." to indicate potentially-unreliable (this I'm not very happy
with, but I can print anything I want on either side of the function; ideas
welcome).
The code is relatively simple as well, it looks more or less like this:
@@ -119,24 +119,31 @@ static inline unsigned long print_contex
{
#ifdef CONFIG_FRAME_POINTER
struct stack_frame *frame = (struct stack_frame *)ebp;
+
+ /*
+* if EBP is "deeper" into the stack than the actual stack pointer,
+* we need to rewind the stack pointer a little to start at the
+* first stack frame, but only if EBP is in this stack frame.
+*/
+ if (stack > (unsigned long *) ebp)
+ && valid_stack_ptr(tinfo, frame, sizeof(*frame)) {
+ stack = (unsigned long *) ebp;
+ }
+
+ while (valid_stack_ptr(tinfo, stack, sizeof(*stack))) {
unsigned long addr;
+ addr = *stack;
+ if (__kernel_text_address(addr)) {
+ if ((unsigned long) stack == ebp + 4) {
+ /* we have a stack frame based hit */
+ ops->address(data, addr, 1);
+ frame = frame->next_frame;
+ ebp = (unsigned long) frame;
+ } else {
+ /*
+* it looks like a kernel function, but
+* it doesn't match a stack frame,
+* print it as unreliable
+*/
+ ops->address(data, addr, 0);
+ }
+ }
+ stack++;
}
I need to go clean up the patch and split it up into 2 pieces (one for the
capability to print unreliable trace entries, and the second the chunk above to
actually walk the stack). I'm also going to try to remove some of the casts
in the code.
What do you think of this approach instead of your proposal?
--
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sh updates for 2.6.24-rc7
Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.24.git Which contains: Carmelo Amoroso (1): sh: Fix argument page dcache flushing regression. Paul Mundt (1): sh: Force __access_ok() to obey address space limit. include/asm-sh/cacheflush.h |6 ++ include/asm-sh/uaccess.h| 42 +++--- 2 files changed, 21 insertions(+), 27 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] checkpatch.pl: allow piping
A little feature addition to allow checkpatch.pl to check patches piped
into it, in addition to specific file arguments.
Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
---
scripts/checkpatch.pl | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
Index: linux-2.6.23/scripts/checkpatch.pl
===
--- linux-2.6.23.orig/scripts/checkpatch.pl
+++ linux-2.6.23/scripts/checkpatch.pl
@@ -24,6 +24,7 @@ my $file = 0;
my $check = 0;
my $summary = 1;
my $mailback = 0;
+my $piped = (-t STDIN) ? 0 : 1;
my $root;
GetOptions(
'q|quiet+' => \$quiet,
@@ -43,7 +44,7 @@ GetOptions(
my $exit = 0;
-if ($#ARGV < 0) {
+if ($#ARGV < 0 && !$piped) {
print "usage: $P [options] patchfile\n";
print "version: $V\n";
print "options: -q => quiet\n";
@@ -181,6 +182,18 @@ if ($tree && -f "$root/$removal") {
}
my @rawlines = ();
+
+if ($piped) {
+ while () {
+ chomp;
+ push(@rawlines, $_);
+ }
+ if (!process("", @rawlines)) {
+ $exit = 1;
+ }
+ @rawlines = ();
+}
+
for my $filename (@ARGV) {
if ($file) {
open(FILE, "diff -u /dev/null $filename|") ||
--
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: STT_FUNC for assembler checksum and semaphore ops" in git-x86
Andi Kleen wrote: > On Thu, Jan 10, 2008 at 04:59:52PM -0800, John Reiser wrote: > >>Andi Kleen wrote: >> >>>But actually checking the default implementation in linkage.h already >>>implements size: [snip] >> >>>Are you sure it doesn't work? Your patch should be not needed. If it's >>>still wrong then just ENDPROCs() need to be added. >> >>The ENDPROCs() were not used everywhere. Some code used just END() instead, >>while other code used nothing. um/sys-i386/checksum.S didn't #include > > > END() is fine too since it contains .size too: > > #ifndef END > #define END(name) \ > .size name, .-name > #endif > > >>diff --git a/arch/x86/lib/semaphore_32.S b/arch/x86/lib/semaphore_32.S >>index 444fba4..e2c6e0d 100644 >>--- a/arch/x86/lib/semaphore_32.S >>+++ b/arch/x86/lib/semaphore_32.S >>@@ -49,7 +49,7 @@ ENTRY(__down_failed) >> ENDFRAME >> ret >> CFI_ENDPROC >>- END(__down_failed) >>+ ENDPROC(__down_failed) > > > I don't think these change makes sense given the definition of END() > shown above. > > The only change that would make sense is adding END() (or ENDPROC()) > to a function that doesn't have either of them yet. No. The pseudo op ".type name, @function" appears only in ENDPROC; it does not appear in END. So changing END to ENDPROC *does* alter the Elf32_Sym for 'name'. Just END produces STT_NOTYPE; ENDPROC produces STT_FUNC. A static analysis tool can get the info it wants much more easily if all subroutines are marked as STT_FUNC. In theory the tool could sort the symbols, notice the disjoint coverage of the address space by the .size intervals of consecutive symbols that are the targets of a CALL instruction, and thus deduce that ".type foo, @function" *should* have been specified. But this is a heuristic, and it fails on boundaries where assembly code is invoked via trap, interrupt, or exception (anything other than CALL). Instead, specify STT_FUNC for each subroutine in the first place. That requires .type, which means ENDPROC (not END) from linux/linkage.h. -- John Reiser, [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: Serverworks Oops with the very latest git kernel...
On Thu, 2008-01-10 at 21:24 -0500, Jeff Garzik wrote: > Trond Myklebust wrote: > > Hi, > > > > I'm getting the following Oops on boot with kernel 2.6.24-rc7-g88fb61e4. > > > > Starting udev: BUG: unable to handle kernel paging request at virtual > > address 2d6d3a65 > > printing eip: c04e1af1 *pde = > > Oops: [#1] PREEMPT SMP > > Modules linked in: evdev evbug rtc_cmos pcspkr floppy rtc_core rtc_lib > > shpchp pci_hotplug serverworks tg3 generic i2c_piix4 i2c_core > > > > Pid: 1820, comm: modprobe Not tainted (2.6.24-rc7-g88fb61e4 #2) > > EIP: 0060:[] EFLAGS: 00210286 CPU: 0 > > EIP is at strstr+0x11/0x34 > > EAX: EBX: 2d6d3a65 ECX: EDX: 2d6d3a65 > > ESI: c0513f75 EDI: 2d6d3a65 EBP: f65bccec ESP: f65bcce0 > > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 > > Process modprobe (pid: 1820, ti=f65bc000 task=f795a2f0 task.ti=f65bc000) > > Stack: f8921a44 0001 f65bcd00 c054a0b9 f892e394 f892e080 > > f892e5f8 > >f65bcd20 f892133b c04d7c9d f892da80 f891d339 f892e394 f892e080 > > f892e5f8 > >f65bcd64 f891d11f f891d339 f891bc38 f892e080 0001 > > > > Call Trace: > > [] show_trace_log_lvl+0x1a/0x2f > > [] show_stack_log_lvl+0x9d/0xa5 > > [] show_registers+0xa3/0x1df > > [] die+0x121/0x204 > > [] do_page_fault+0x557/0x63e > > [] error_code+0x72/0x78 > > [] dmi_check_system+0x2f/0x58 > > [] ide_acpi_init+0x28/0x195 [ide_core] > > [] hwif_init+0x324/0x37c [ide_core] > > [] ide_device_add+0x3b/0xa6 [ide_core] > > [] ide_setup_pci_device+0x36/0x40 [ide_core] > > [] svwks_init_one+0x5b/0x62 [serverworks] > > [] pci_device_probe+0x39/0x5b > > [] driver_probe_device+0xe9/0x16a > > [] __driver_attach+0x6c/0xa5 > > [] bus_for_each_dev+0x36/0x5b > > [] driver_attach+0x19/0x1b > > [] bus_add_driver+0x73/0x1aa > > [] driver_register+0x67/0x6c > > [] __pci_register_driver+0x56/0x83 > > [] svwks_ide_init+0x17/0x19 [serverworks] > > [] sys_init_module+0x15da/0x1715 > > [] sysenter_past_esp+0x5f/0xa5 > > === > > Code: e5 89 c1 89 c8 eb 06 80 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 5d c3 > > 90 90 90 55 89 e5 57 56 53 89 c6 89 d3 31 c0 83 c9 ff 89 > > EIP: [] strstr+0x11/0x34 SS:ESP 0068:f65bcce0 > > ---[ end trace f0316f1e9ff3 ]--- > > udevd-event[1819]: run_program: '/sbin/modprobe' abnormal exit > > > > > > Any ideas? As far as I can see, 2.6.24-rc7 itself is good, so I suspect > > the recent merge by Bart. > > > > I've set up a bugzilla entry for the regression on > > http://bugzilla.kernel.org/show_bug.cgi?id=9728 > > Does this patch fix it? > > Looks like an unterminated DMI table... Yup. That seems to have solved it. Thanks Jeff! Trond -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 05/19] split LRU lists into anon & file sets
Hi Rik
> -static inline long mem_cgroup_calc_reclaim_inactive(struct mem_cgroup *mem,
> - struct zone *zone, int priority)
> +static inline long mem_cgroup_calc_reclaim(struct mem_cgroup *mem,
> + struct zone *zone, int priority,
> + int active, int file)
> {
> return 0;
> }
it can't compile if memcgroup turn off.
because current mem_cgroup_calc_reclaim type is below.
long mem_cgroup_calc_reclaim(struct mem_cgroup *mem, struct zone *zone,
int priority, enum lru_list lru)
after patched below, it can compile.
I hope you don't think unpleasant by a trivial point out.
regard.
- kosaki
Index: linux-2.6.24-rc6-mm1-rvr/include/linux/memcontrol.h
===
--- linux-2.6.24-rc6-mm1-rvr.orig/include/linux/memcontrol.h2008-01-11
11:10:16.0 +0900
+++ linux-2.6.24-rc6-mm1-rvr/include/linux/memcontrol.h 2008-01-11
12:08:29.0 +0900
@@ -168,9 +168,8 @@
{
}
-static inline long mem_cgroup_calc_reclaim(struct mem_cgroup *mem,
- struct zone *zone, int priority,
- int active, int file)
+static inline long mem_cgroup_calc_reclaim(struct mem_cgroup *mem, struct zone
*zone,
+ int priority, enum lru_list lru)
{
return 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: [PATCH] [Coding Style]: fs/ext{3,4}/ext{3,4}_jbd{,2}.c
On Fri, Jan 11, 2008 at 12:42:40PM +0900, Paul Mundt wrote: > How about throwing out hand-rolled debug printk wrappers for the > brain-damage they are and using the ones the kernel provides > instead? Sounds great! //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] [Coding Style]: fs/ext{3,4}/ext{3,4}_jbd{,2}.c
On Fri, Jan 11, 2008 at 04:09:45AM +0100, Peter Stuge wrote:
> On Thu, Jan 10, 2008 at 10:03:58PM +0100, Roel Kluin wrote:
> > -#define DEBUG(x,args...) printk(__FUNCTION__ ": " x,##args)
> > +#define DEBUG(x, args...) printk("%s: ", __func__, x, ##args)
>
> Can this really be expected to work when x contains conversions?
>
> How about:
>
> #define DEBUG(x, args...) printk("%s: " x, __func__, ##args)
>
How about throwing out hand-rolled debug printk wrappers for the
brain-damage they are and using the ones the kernel provides instead?
dev_dbg() and pr_debug() both manage to get these semantics right, and
you can even bury the #define DEBUG underneath some Kconfig silliness if
you're the kind of person that leans that way.
Maybe we can just amend checkpatch to delete a patch out of protest if it
introduces printk() wrappers..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] PCI: change procfs interface to use unlocked_ioctl instead of ioctl
Change drivers/pci/proc.c to use the unlocked_ioctl handler instead of
the ioctl one.
Signed-off-by: Sergio Luis <[EMAIL PROTECTED]>
proc.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index 716439e..8ac5880 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include "pci.h"
@@ -202,15 +203,17 @@ struct pci_filp_private {
int write_combine;
};
-static int proc_bus_pci_ioctl(struct inode *inode, struct file *file,
unsigned int cmd, unsigned long arg)
+static long proc_bus_pci_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
+struct inode *inode = file->f_path.dentry->d_inode;
const struct proc_dir_entry *dp = PDE(inode);
struct pci_dev *dev = dp->data;
#ifdef HAVE_PCI_MMAP
struct pci_filp_private *fpriv = file->private_data;
#endif /* HAVE_PCI_MMAP */
-int ret = 0;
+long ret = 0;
+lock_kernel();
switch (cmd) {
case PCIIOC_CONTROLLER:
ret = pci_domain_nr(dev->bus);
@@ -239,6 +242,7 @@ static int proc_bus_pci_ioctl(struct inode *inode,
struct file *file, unsigned i
break;
};
+unlock_kernel();
return ret;
}
@@ -291,7 +295,7 @@ static const struct file_operations
proc_bus_pci_operations = {
.llseek= proc_bus_pci_lseek,
.read= proc_bus_pci_read,
.write= proc_bus_pci_write,
-.ioctl= proc_bus_pci_ioctl,
+.unlocked_ioctl= proc_bus_pci_ioctl,
#ifdef HAVE_PCI_MMAP
.open= proc_bus_pci_open,
.release= proc_bus_pci_release,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 11/11 ] Change drm_ioctl as an unlocked_ioctl function : via
Register drm_ioctl as an unlocked_ioctl function.
Signed-off-by: Nikanth Karthikesan <[EMAIL PROTECTED]>
---
diff --git a/drivers/char/drm/via_drv.c b/drivers/char/drm/via_drv.c
index 2d4957a..a8041c5 100644
--- a/drivers/char/drm/via_drv.c
+++ b/drivers/char/drm/via_drv.c
@@ -62,7 +62,7 @@ static struct drm_driver driver = {
.owner = THIS_MODULE,
.open = drm_open,
.release = drm_release,
-.ioctl = drm_ioctl,
+.unlocked_ioctl = drm_ioctl,
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 8/11 ] Change drm_ioctl as an unlocked_ioctl function : savage
Register drm_ioctl as an unlocked_ioctl function.
Signed-off-by: Nikanth Karthikesan <[EMAIL PROTECTED]>
---
diff --git a/drivers/char/drm/savage_drv.c b/drivers/char/drm/savage_drv.c
index eee52aa..021de44 100644
--- a/drivers/char/drm/savage_drv.c
+++ b/drivers/char/drm/savage_drv.c
@@ -50,7 +50,7 @@ static struct drm_driver driver = {
.owner = THIS_MODULE,
.open = drm_open,
.release = drm_release,
-.ioctl = drm_ioctl,
+.unlocked_ioctl = drm_ioctl,
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 9/11 ] Change drm_ioctl as an unlocked_ioctl function : sis
Register drm_ioctl as an unlocked_ioctl function.
Signed-off-by: Nikanth Karthikesan <[EMAIL PROTECTED]>
---
diff --git a/drivers/char/drm/sis_drv.c b/drivers/char/drm/sis_drv.c
index 7dacc64..1bbde29 100644
--- a/drivers/char/drm/sis_drv.c
+++ b/drivers/char/drm/sis_drv.c
@@ -80,7 +80,7 @@ static struct drm_driver driver = {
.owner = THIS_MODULE,
.open = drm_open,
.release = drm_release,
-.ioctl = drm_ioctl,
+.unlocked_ioctl = drm_ioctl,
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 10/11 ] Change drm_ioctl as an unlocked_ioctl function : tdfx
Register drm_ioctl as an unlocked_ioctl function.
Signed-off-by: Nikanth Karthikesan <[EMAIL PROTECTED]>
---
diff --git a/drivers/char/drm/tdfx_drv.c b/drivers/char/drm/tdfx_drv.c
index 012ff2e..ec5a43e 100644
--- a/drivers/char/drm/tdfx_drv.c
+++ b/drivers/char/drm/tdfx_drv.c
@@ -48,7 +48,7 @@ static struct drm_driver driver = {
.owner = THIS_MODULE,
.open = drm_open,
.release = drm_release,
-.ioctl = drm_ioctl,
+.unlocked_ioctl = drm_ioctl,
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 7/11 ] Change drm_ioctl as an unlocked_ioctl function : Radeon
Register drm_ioctl as an unlocked_ioctl function.
Signed-off-by: Nikanth Karthikesan <[EMAIL PROTECTED]>
---
diff --git a/drivers/char/drm/radeon_drv.c b/drivers/char/drm/radeon_drv.c
index 349ac3d..6d7588c 100644
--- a/drivers/char/drm/radeon_drv.c
+++ b/drivers/char/drm/radeon_drv.c
@@ -85,7 +85,7 @@ static struct drm_driver driver = {
.owner = THIS_MODULE,
.open = drm_open,
.release = drm_release,
-.ioctl = drm_ioctl,
+.unlocked_ioctl = drm_ioctl,
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
diff --git a/drivers/char/drm/radeon_ioc32.c b/drivers/char/drm/radeon_ioc32.c
index 56decda..f095048 100644
--- a/drivers/char/drm/radeon_ioc32.c
+++ b/drivers/char/drm/radeon_ioc32.c
@@ -92,8 +92,8 @@ static int compat_radeon_cp_init(struct file *file, unsigned
int cmd,
>gart_textures_offset))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_RADEON_CP_INIT, (unsigned long)init);
+ return drm_ioctl(file, DRM_IOCTL_RADEON_CP_INIT,
+(unsigned long)init);
}
typedef struct drm_radeon_clear32 {
@@ -125,8 +125,8 @@ static int compat_radeon_cp_clear(struct file *file,
unsigned int cmd,
>depth_boxes))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_RADEON_CLEAR, (unsigned long)clr);
+ return drm_ioctl(file, DRM_IOCTL_RADEON_CLEAR,
+(unsigned long)clr);
}
typedef struct drm_radeon_stipple32 {
@@ -149,8 +149,8 @@ static int compat_radeon_cp_stipple(struct file *file,
unsigned int cmd,
>mask))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_RADEON_STIPPLE, (unsigned long)request);
+ return drm_ioctl(file, DRM_IOCTL_RADEON_STIPPLE,
+(unsigned long)request);
}
typedef struct drm_radeon_tex_image32 {
@@ -204,8 +204,8 @@ static int compat_radeon_cp_texture(struct file *file,
unsigned int cmd,
>data))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_RADEON_TEXTURE, (unsigned long)request);
+ return drm_ioctl(file, DRM_IOCTL_RADEON_TEXTURE,
+(unsigned long)request);
}
typedef struct drm_radeon_vertex2_32 {
@@ -238,8 +238,8 @@ static int compat_radeon_cp_vertex2(struct file *file,
unsigned int cmd,
>prim))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_RADEON_VERTEX2, (unsigned long)request);
+ return drm_ioctl(file, DRM_IOCTL_RADEON_VERTEX2,
+(unsigned long)request);
}
typedef struct drm_radeon_cmd_buffer32 {
@@ -268,8 +268,8 @@ static int compat_radeon_cp_cmdbuf(struct file *file,
unsigned int cmd,
>boxes))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_RADEON_CMDBUF, (unsigned long)request);
+ return drm_ioctl(file, DRM_IOCTL_RADEON_CMDBUF,
+(unsigned long)request);
}
typedef struct drm_radeon_getparam32 {
@@ -293,8 +293,8 @@ static int compat_radeon_cp_getparam(struct file *file,
unsigned int cmd,
>value))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_RADEON_GETPARAM, (unsigned long)request);
+ return drm_ioctl(file, DRM_IOCTL_RADEON_GETPARAM,
+(unsigned long)request);
}
typedef struct drm_radeon_mem_alloc32 {
@@ -322,8 +322,8 @@ static int compat_radeon_mem_alloc(struct file *file,
unsigned int cmd,
>region_offset))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_RADEON_ALLOC, (unsigned long)request);
+ return drm_ioctl(file, DRM_IOCTL_RADEON_ALLOC,
+(unsigned long)request);
}
typedef struct drm_radeon_irq_emit32 {
@@ -345,8 +345,8 @@ static int compat_radeon_irq_emit(struct file *file,
unsigned int cmd,
>irq_seq))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_RADEON_IRQ_EMIT, (unsigned long)request);
+ return drm_ioctl(file, DRM_IOCTL_RADEON_IRQ_EMIT,
+(unsigned
[PATCH 5/11 ] Change drm_ioctl as an unlocked_ioctl function : mga
Register drm_ioctl as an unlocked_ioctl function.
Signed-off-by: Nikanth Karthikesan <[EMAIL PROTECTED]>
---
diff --git a/drivers/char/drm/mga_drv.c b/drivers/char/drm/mga_drv.c
index 5572939..be31707 100644
--- a/drivers/char/drm/mga_drv.c
+++ b/drivers/char/drm/mga_drv.c
@@ -67,7 +67,7 @@ static struct drm_driver driver = {
.owner = THIS_MODULE,
.open = drm_open,
.release = drm_release,
-.ioctl = drm_ioctl,
+.unlocked_ioctl = drm_ioctl,
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
diff --git a/drivers/char/drm/mga_ioc32.c b/drivers/char/drm/mga_ioc32.c
index 30d0047..a4581d9 100644
--- a/drivers/char/drm/mga_ioc32.c
+++ b/drivers/char/drm/mga_ioc32.c
@@ -100,8 +100,7 @@ static int compat_mga_init(struct file *file, unsigned int
cmd,
if (err)
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_MGA_INIT, (unsigned long)init);
+ return drm_ioctl(file, DRM_IOCTL_MGA_INIT, (unsigned long)init);
}
typedef struct drm_mga_getparam32 {
@@ -125,8 +124,8 @@ static int compat_mga_getparam(struct file *file, unsigned
int cmd,
>value))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_MGA_GETPARAM, (unsigned long)getparam);
+ return drm_ioctl(file, DRM_IOCTL_MGA_GETPARAM,
+(unsigned long)getparam);
}
typedef struct drm_mga_drm_bootstrap32 {
@@ -166,9 +165,8 @@ static int compat_mga_dma_bootstrap(struct file *file,
unsigned int cmd,
|| __put_user(dma_bootstrap32.agp_size, _bootstrap->agp_size))
return -EFAULT;
- err = drm_ioctl(file->f_path.dentry->d_inode, file,
- DRM_IOCTL_MGA_DMA_BOOTSTRAP,
- (unsigned long)dma_bootstrap);
+ err = drm_ioctl(file, DRM_IOCTL_MGA_DMA_BOOTSTRAP,
+ (unsigned long)dma_bootstrap);
if (err)
return err;
@@ -224,7 +222,7 @@ long mga_compat_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
if (fn != NULL)
ret = (*fn) (filp, cmd, arg);
else
- ret = drm_ioctl(filp->f_path.dentry->d_inode, filp, cmd, arg);
+ ret = drm_ioctl(filp, cmd, arg);
unlock_kernel();
return ret;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 6/11 ] Change drm_ioctl as an unlocked_ioctl function : r128
Register drm_ioctl as an unlocked_ioctl function.
Signed-off-by: Nikanth Karthikesan <[EMAIL PROTECTED]>
---
diff --git a/drivers/char/drm/r128_drv.c b/drivers/char/drm/r128_drv.c
index 6108e75..b2a16a7 100644
--- a/drivers/char/drm/r128_drv.c
+++ b/drivers/char/drm/r128_drv.c
@@ -62,7 +62,7 @@ static struct drm_driver driver = {
.owner = THIS_MODULE,
.open = drm_open,
.release = drm_release,
-.ioctl = drm_ioctl,
+.unlocked_ioctl = drm_ioctl,
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
diff --git a/drivers/char/drm/r128_ioc32.c b/drivers/char/drm/r128_ioc32.c
index d3cb676..1f3c5e5 100644
--- a/drivers/char/drm/r128_ioc32.c
+++ b/drivers/char/drm/r128_ioc32.c
@@ -95,8 +95,8 @@ static int compat_r128_init(struct file *file, unsigned int
cmd,
>agp_textures_offset))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_R128_INIT, (unsigned long)init);
+ return drm_ioctl(file, DRM_IOCTL_R128_INIT,
+(unsigned long)init);
}
typedef struct drm_r128_depth32 {
@@ -129,8 +129,8 @@ static int compat_r128_depth(struct file *file, unsigned
int cmd,
>mask))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_R128_DEPTH, (unsigned long)depth);
+ return drm_ioctl(file, DRM_IOCTL_R128_DEPTH,
+(unsigned long)depth);
}
@@ -153,8 +153,8 @@ static int compat_r128_stipple(struct file *file, unsigned
int cmd,
>mask))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_R128_STIPPLE, (unsigned long)stipple);
+ return drm_ioctl(file, DRM_IOCTL_R128_STIPPLE,
+(unsigned long)stipple);
}
typedef struct drm_r128_getparam32 {
@@ -178,8 +178,8 @@ static int compat_r128_getparam(struct file *file, unsigned
int cmd,
>value))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_R128_GETPARAM, (unsigned long)getparam);
+ return drm_ioctl(file, DRM_IOCTL_R128_GETPARAM,
+(unsigned long)getparam);
}
drm_ioctl_compat_t *r128_compat_ioctls[] = {
@@ -214,7 +214,7 @@ long r128_compat_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
if (fn != NULL)
ret = (*fn) (filp, cmd, arg);
else
- ret = drm_ioctl(filp->f_path.dentry->d_inode, filp, cmd, arg);
+ ret = drm_ioctl(filp, cmd, arg);
unlock_kernel();
return ret;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 3/11 ] Change drm_ioctl as an unlocked_ioctl function : i830
Register drm_ioctl as an unlocked_ioctl function.
Signed-off-by: Nikanth Karthikesan <[EMAIL PROTECTED]>
---
diff --git a/drivers/char/drm/i830_dma.c b/drivers/char/drm/i830_dma.c
index 69a363e..2f82480 100644
--- a/drivers/char/drm/i830_dma.c
+++ b/drivers/char/drm/i830_dma.c
@@ -117,7 +117,7 @@ static int i830_mmap_buffers(struct file *filp, struct
vm_area_struct *vma)
static const struct file_operations i830_buffer_fops = {
.open = drm_open,
.release = drm_release,
- .ioctl = drm_ioctl,
+ .unlocked_ioctl = drm_ioctl,
.mmap = i830_mmap_buffers,
.fasync = drm_fasync,
};
diff --git a/drivers/char/drm/i830_drv.c b/drivers/char/drm/i830_drv.c
index 389597e..44f990b 100644
--- a/drivers/char/drm/i830_drv.c
+++ b/drivers/char/drm/i830_drv.c
@@ -70,7 +70,7 @@ static struct drm_driver driver = {
.owner = THIS_MODULE,
.open = drm_open,
.release = drm_release,
-.ioctl = drm_ioctl,
+.unlocked_ioctl = drm_ioctl,
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 4/11 ] Change drm_ioctl as an unlocked_ioctl function : i915
Register drm_ioctl as an unlocked_ioctl function.
Signed-off-by: Nikanth Karthikesan <[EMAIL PROTECTED]>
---
diff --git a/drivers/char/drm/i915_drv.c b/drivers/char/drm/i915_drv.c
index 85bcc27..70a882e 100644
--- a/drivers/char/drm/i915_drv.c
+++ b/drivers/char/drm/i915_drv.c
@@ -64,7 +64,7 @@ static struct drm_driver driver = {
.owner = THIS_MODULE,
.open = drm_open,
.release = drm_release,
-.ioctl = drm_ioctl,
+.unlocked_ioctl = drm_ioctl,
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
diff --git a/drivers/char/drm/i915_ioc32.c b/drivers/char/drm/i915_ioc32.c
index 1fe68a2..f8b1d68 100644
--- a/drivers/char/drm/i915_ioc32.c
+++ b/drivers/char/drm/i915_ioc32.c
@@ -66,9 +66,8 @@ static int compat_i915_batchbuffer(struct file *file,
unsigned int cmd,
>cliprects))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_I915_BATCHBUFFER,
-(unsigned long)batchbuffer);
+ return drm_ioctl(file, DRM_IOCTL_I915_BATCHBUFFER,
+(unsigned long)batchbuffer);
}
typedef struct _drm_i915_cmdbuffer32 {
@@ -102,8 +101,8 @@ static int compat_i915_cmdbuffer(struct file *file,
unsigned int cmd,
>cliprects))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_I915_CMDBUFFER, (unsigned long)cmdbuffer);
+ return drm_ioctl(file, DRM_IOCTL_I915_CMDBUFFER,
+(unsigned long)cmdbuffer);
}
typedef struct drm_i915_irq_emit32 {
@@ -125,8 +124,8 @@ static int compat_i915_irq_emit(struct file *file, unsigned
int cmd,
>irq_seq))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_I915_IRQ_EMIT, (unsigned long)request);
+ return drm_ioctl(file, DRM_IOCTL_I915_IRQ_EMIT,
+(unsigned long)request);
}
typedef struct drm_i915_getparam32 {
int param;
@@ -149,8 +148,8 @@ static int compat_i915_getparam(struct file *file, unsigned
int cmd,
>value))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_I915_GETPARAM, (unsigned long)request);
+ return drm_ioctl(file, DRM_IOCTL_I915_GETPARAM,
+(unsigned long)request);
}
typedef struct drm_i915_mem_alloc32 {
@@ -178,8 +177,8 @@ static int compat_i915_alloc(struct file *file, unsigned
int cmd,
>region_offset))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_I915_ALLOC, (unsigned long)request);
+ return drm_ioctl(file, DRM_IOCTL_I915_ALLOC,
+(unsigned long)request);
}
drm_ioctl_compat_t *i915_compat_ioctls[] = {
@@ -215,7 +214,7 @@ long i915_compat_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
if (fn != NULL)
ret = (*fn) (filp, cmd, arg);
else
- ret = drm_ioctl(filp->f_path.dentry->d_inode, filp, cmd, arg);
+ ret = drm_ioctl(filp, cmd, arg);
unlock_kernel();
return ret;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/11 ] Change drm_ioctl as an unlocked_ioctl function : i810
Register drm_ioctl as an unlocked_ioctl function.
Signed-off-by: Nikanth Karthikesan <[EMAIL PROTECTED]>
---
diff --git a/drivers/char/drm/i810_dma.c b/drivers/char/drm/i810_dma.c
index eb381a7..e3adbf3 100644
--- a/drivers/char/drm/i810_dma.c
+++ b/drivers/char/drm/i810_dma.c
@@ -115,7 +115,7 @@ static int i810_mmap_buffers(struct file *filp, struct
vm_area_struct *vma)
static const struct file_operations i810_buffer_fops = {
.open = drm_open,
.release = drm_release,
- .ioctl = drm_ioctl,
+ .unlocked_ioctl = drm_ioctl,
.mmap = i810_mmap_buffers,
.fasync = drm_fasync,
};
diff --git a/drivers/char/drm/i810_drv.c b/drivers/char/drm/i810_drv.c
index fabb9a8..c1e0275 100644
--- a/drivers/char/drm/i810_drv.c
+++ b/drivers/char/drm/i810_drv.c
@@ -59,7 +59,7 @@ static struct drm_driver driver = {
.owner = THIS_MODULE,
.open = drm_open,
.release = drm_release,
-.ioctl = drm_ioctl,
+.unlocked_ioctl = drm_ioctl,
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Splice(): exports for module programmers
Just a couple of quick questions if anyone can shed light regarding functions exported for modules relating to splice(): * Is there a particular reason why the useful helper __splice_from_pipe is exported, but not the locking equivalent splice_from_pipe or its equally useful helper splice_to_pipe? * Similarly is there anything wrong with exporting the generic pipe-buffer operations (e.g. generic_pipe_buf_map) to save effort writing modules which implement splice_read and splice_write? Are these unexported because they are unstable and not yet considered suitable for use, or simply because nobody's written a module that splice()s yet? Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/11 ] Change drm_ioctl as an unlocked_ioctl function
The ioctl handlers are called with the BKL held, where as unlocked_ioctl
handlers are not. The drm_ioctl function is registered as an ioctl
handler. But it does not need the BKL to be held. Changing drm_ioctl to
register as an unlocked_ioctl function.
Signed-off-by: Nikanth Karthikesan <[EMAIL PROTECTED]>
---
diff --git a/drivers/char/drm/drmP.h b/drivers/char/drm/drmP.h
index dde02a1..e5570b8 100644
--- a/drivers/char/drm/drmP.h
+++ b/drivers/char/drm/drmP.h
@@ -833,8 +833,8 @@ static inline int drm_mtrr_del(int handle, unsigned long
offset,
/* Driver support (drm_drv.h) */
extern int drm_init(struct drm_driver *driver);
extern void drm_exit(struct drm_driver *driver);
-extern int drm_ioctl(struct inode *inode, struct file *filp,
-unsigned int cmd, unsigned long arg);
+extern long drm_ioctl(struct file *filp, unsigned int cmd,
+unsigned long arg);
extern long drm_compat_ioctl(struct file *filp,
unsigned int cmd, unsigned long arg);
extern int drm_lastclose(struct drm_device *dev);
diff --git a/drivers/char/drm/drm_drv.c b/drivers/char/drm/drm_drv.c
index 44a4626..7938153 100644
--- a/drivers/char/drm/drm_drv.c
+++ b/drivers/char/drm/drm_drv.c
@@ -438,7 +438,6 @@ static int drm_version(struct drm_device *dev, void *data,
/**
* Called whenever a process performs an ioctl on /dev/drm.
*
- * \param inode device inode.
* \param file_priv DRM file private.
* \param cmd command.
* \param arg user argument.
@@ -447,8 +446,7 @@ static int drm_version(struct drm_device *dev, void *data,
* Looks up the ioctl function in the ::ioctls table, checking for root
* previleges if so required, and dispatches to the respective function.
*/
-int drm_ioctl(struct inode *inode, struct file *filp,
- unsigned int cmd, unsigned long arg)
+long drm_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
struct drm_file *file_priv = filp->private_data;
struct drm_device *dev = file_priv->head->dev;
diff --git a/drivers/char/drm/drm_ioc32.c b/drivers/char/drm/drm_ioc32.c
index 2286f33..3b35263 100644
--- a/drivers/char/drm/drm_ioc32.c
+++ b/drivers/char/drm/drm_ioc32.c
@@ -102,8 +102,8 @@ static int compat_drm_version(struct file *file, unsigned
int cmd,
>desc))
return -EFAULT;
- err = drm_ioctl(file->f_path.dentry->d_inode, file,
- DRM_IOCTL_VERSION, (unsigned long)version);
+ err = drm_ioctl(file, DRM_IOCTL_VERSION,
+(unsigned long)version);
if (err)
return err;
@@ -143,8 +143,7 @@ static int compat_drm_getunique(struct file *file, unsigned
int cmd,
>unique))
return -EFAULT;
- err = drm_ioctl(file->f_path.dentry->d_inode, file,
- DRM_IOCTL_GET_UNIQUE, (unsigned long)u);
+ err = drm_ioctl(file, DRM_IOCTL_GET_UNIQUE, (unsigned long)u);
if (err)
return err;
@@ -172,8 +171,7 @@ static int compat_drm_setunique(struct file *file, unsigned
int cmd,
>unique))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_SET_UNIQUE, (unsigned long)u);
+ return drm_ioctl(file, DRM_IOCTL_SET_UNIQUE, (unsigned long)u);
}
typedef struct drm_map32 {
@@ -203,8 +201,7 @@ static int compat_drm_getmap(struct file *file, unsigned
int cmd,
if (__put_user(idx, >offset))
return -EFAULT;
- err = drm_ioctl(file->f_path.dentry->d_inode, file,
- DRM_IOCTL_GET_MAP, (unsigned long)map);
+ err = drm_ioctl(file, DRM_IOCTL_GET_MAP, (unsigned long)map);
if (err)
return err;
@@ -244,8 +241,7 @@ static int compat_drm_addmap(struct file *file, unsigned
int cmd,
|| __put_user(m32.flags, >flags))
return -EFAULT;
- err = drm_ioctl(file->f_path.dentry->d_inode, file,
- DRM_IOCTL_ADD_MAP, (unsigned long)map);
+ err = drm_ioctl(file, DRM_IOCTL_ADD_MAP, (unsigned long)map);
if (err)
return err;
@@ -282,8 +278,7 @@ static int compat_drm_rmmap(struct file *file, unsigned int
cmd,
if (__put_user((void *)(unsigned long)handle, >handle))
return -EFAULT;
- return drm_ioctl(file->f_path.dentry->d_inode, file,
-DRM_IOCTL_RM_MAP, (unsigned long)map);
+ return drm_ioctl(file, DRM_IOCTL_RM_MAP, (unsigned long)map);
}
typedef struct drm_client32 {
@@ -312,8 +307,8 @@ static int compat_drm_getclient(struct file *file, unsigned
int cmd,
if (__put_user(idx, >idx))
return -EFAULT;
- err = drm_ioctl(file->f_path.dentry->d_inode, file,
- DRM_IOCTL_GET_CLIENT, (unsigned
Re: [PATCH] [Coding Style]: fs/ext{3,4}/ext{3,4}_jbd{,2}.c
On Thu, Jan 10, 2008 at 10:03:58PM +0100, Roel Kluin wrote:
> -#define DEBUG(x,args...) printk(__FUNCTION__ ": " x,##args)
> +#define DEBUG(x, args...)printk("%s: ", __func__, x, ##args)
Can this really be expected to work when x contains conversions?
How about:
#define DEBUG(x, args...) printk("%s: " x, __func__, ##args)
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: kexec fail
On Jan 8, 2008 2:36 PM, Yinghai Lu <[EMAIL PROTECTED]> wrote: > > On Jan 8, 2008 12:15 AM, Yinghai Lu <[EMAIL PROTECTED]> wrote: > > > > On Jan 7, 2008 9:50 PM, Christoph Lameter <[EMAIL PROTECTED]> wrote: > > > On Mon, 7 Jan 2008, Yinghai Lu wrote: > > > > > > > try to kexec 2.6.23 from RHEL 5.1, will get > > > > Your BIOS doesn't leave a aperture memory hole > > > > Please enable the IOMMU option in the BIOS setup > > > > This costs you 64 MB of RAM ==> reboot > > > > > > > > but 2.6.24-rc7 kexec 2.6.24-rc7 is ok. > > > > > > BUG in 2.6.23 kexec? > > > > > > > > > > yeah, that is more worse. it will cause reboot. > > > > change mem model from CONFIG_SPARSEMEM_MANUL to > CONFIG_DISCONTIGMEM_MANUAL it will work. find the cause. because two kernel has different addr for GART aper. and second kernel will put vmemmap in the GART set by first kernel. http://lkml.org/lkml/2008/1/10/517 YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-64: disable the GART early
this one is against to linus tree.
in case some one need to use kexec to new kernel from old kernel with
gart_shutdown.
YH
[PATCH] x86-64: disable the GART early
For K8 system: 4G RAM with memory hole remapping enabled, or more than 4G RAM
installed.
when try to use kexec second kernel, and the first doesn't include
gart_shutdown.
the second kernel could have different aper position than the first kernel. and
second
kernel could use that hole as RAM that is still used by GART set by the first
kernel.
esp. when try to kexec 2.6.24 with sparse mem enable from previous kernel (from
RHEL 5
or SLES 10). the new kernel will use aper by GART (set by first kernel) for
vmemmap.
and after new kernel setting one new GART. the position will be real RAM. the
_mapcount
set is lost.
Bad page state in process 'swapper'
page:e2000e600020 flags:0x mapping:
mapcount:1 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Pid: 0, comm: swapper Not tainted 2.6.24-rc7-smp-gcdf71a10-dirty #13
Call Trace:
[] bad_page+0x63/0x8d
[] __free_pages_ok+0x7c/0x2a5
[] free_all_bootmem_core+0xd0/0x198
[] numa_free_all_bootmem+0x3b/0x76
[] mem_init+0x3b/0x152
[] start_kernel+0x236/0x2c2
[] _sinittext+0x11a/0x121
and
[e2000e60-e2000e7f] PMD ->81001c20 on node 0
phys addr is : 0x1c20
RHEL 5.1 kernel -53 said:
PCI-DMA: aperture base @ 1c00 size 65536 KB
new kernel said:
Mapping aperture over 65536 KB of RAM @ 3c00
So try to disable that GART as early as possible.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
Index: linux-2.6/arch/x86/kernel/aperture_64.c
===
--- linux-2.6.orig/arch/x86/kernel/aperture_64.c
+++ linux-2.6/arch/x86/kernel/aperture_64.c
@@ -204,6 +204,73 @@ static __u32 __init search_agp_bridge(u3
return 0;
}
+void __init early_gart_iommu_disable(void)
+{
+ /*
+* disable it in case it is enabled before, esp for kexec/kdump,
+* previous kernel already enable that. otherwise memset called
+* by allocate_aperture/__alloc_bootmem_nopanic cause restart.
+* or second kernel have different position for GART hole. and new
+* kernel could use hole as RAM that is still used by GART set by
+* first kernel
+*/
+ int fix, num;
+ u32 ctl;
+u32 aper_size, aper_alloc = 0, aper_order = 0, last_aper_order = 0;
+u64 aper_base, last_aper_base = 0;
+int valid_agp = 0;
+
+if (!early_pci_allowed())
+return;
+
+ fix = 0;
+for (num = 24; num < 32; num++) {
+if (!early_is_k8_nb(read_pci_config(0, num, 3, 0x00)))
+continue;
+
+aper_order = (read_pci_config(0, num, 3, 0x90) >> 1) & 7;
+aper_size = (32 * 1024 * 1024) << aper_order;
+aper_base = read_pci_config(0, num, 3, 0x94) & 0x7fff;
+aper_base <<= 25;
+
+if (!aperture_valid(aper_base, aper_size)) {
+fix = 1;
+break;
+}
+
+if ((last_aper_order && aper_order != last_aper_order) ||
+(last_aper_base && aper_base != last_aper_base)) {
+fix = 1;
+break;
+}
+last_aper_order = aper_order;
+last_aper_base = aper_base;
+}
+
+ if (!fix)
+ return;
+
+ aper_alloc = search_agp_bridge(_order, _agp);
+
+ if (aper_alloc) {
+ /*
+* could get aper later or before from the AGP bridge,
+* so it is safe
+*/
+ return;
+ }
+
+ for (num = 24; num < 32; num++) {
+ if (!early_is_k8_nb(read_pci_config(0, num, 3, 0x00)))
+ continue;
+
+ ctl = read_pci_config(0, num, 3, 0x90);
+ ctl &= ~1;
+ write_pci_config(0, num, 3, 0x90, 0);
+ }
+
+}
+
void __init gart_iommu_hole_init(void)
{
int fix, num;
Index: linux-2.6/arch/x86/kernel/setup_64.c
===
--- linux-2.6.orig/arch/x86/kernel/setup_64.c
+++ linux-2.6/arch/x86/kernel/setup_64.c
@@ -256,6 +256,8 @@ static void discover_ebda(void)
ebda_size = 64*1024;
}
+extern void early_gart_iommu_disable(void);
+
void __init setup_arch(char **cmdline_p)
{
printk(KERN_INFO "Command line: %s\n", boot_command_line);
@@ -309,6 +311,8 @@ void __init setup_arch(char **cmdline_p)
discover_ebda();
+ early_gart_iommu_disable();
+
init_memory_mapping(0, (end_pfn_map << PAGE_SHIFT));
dmi_scan_machine();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Re: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On 11-01-08 02:36, Zachary Amsden wrote: FWIW, I fixed the problem locally by recompiling, changing port 80 to port 84 in io.h; works great, and doesn't conflict with any occupied ports. Might not give you a "proper" delay though. 0xed should be a better choice... 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: CONFIG_NO_HZ breaks blktrace timestamps
On Thu, 2008-01-10 at 23:44 +0100, Guillaume Chazarain wrote: > David Dillow <[EMAIL PROTECTED]> wrote: > > > At the moment, I'm not sure how to track this farther, or how to fix it > > properly. Any advice would be appreciated. > > Just out of curiosity, could you try the appended cumulative patch and > report .clock_warps, .clock_overflows and .clock_underflows as you did. With those patches, CONFIG_NO_HZ works just fine. Patched kernel, nohz=off: now at 214257.820809 msecs .clock : 214212.727559 .idle_clock: 0.00 .prev_clock_raw: 244569.402345 .clock_warps : 0 .clock_overflows : 577 .clock_underflows : 213887 .clock_deep_idle_events: 4 .clock_max_delta : 0.999830 Patched kernel, nohz=on: now at 248931.524381 msecs .clock : 248745.808465 .idle_clock: 0.00 .prev_clock_raw: 270911.098507 .clock_warps : 0 .clock_overflows : 69 .clock_underflows : 784 .clock_deep_idle_events: 4 .clock_max_delta : 100.639397 Running my disk test, blktrace is getting the proper timestamps now with CONFIG_NO_HZ. Thanks! -- Dave Dillow National Center for Computational Science Oak Ridge National Laboratory (865) 241-6602 office -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: hwclock failure in x86.git
I'm no expert, but I happened to notice this go by.
> The first thing I notice about the path is that ioport_32.c and the unified
> ioport.c use __clear_bit,
> while ioport_64.c uses clear_bit.
That doesn't seem too critical.
> +#ifdef CONFIG_X86_32
> +asmlinkage long sys_iopl(unsigned long regsp)
> +{
> + volatile struct pt_regs *regs = (struct pt_regs *)
> + unsigned int level = regs->bx;
> + unsigned int old = (regs->flags >> 12) & 3;
> +
> + if (level > 3)
> + return -EINVAL;
> + /* Trying to gain more privileges? */
> + if (level > old) {
> + if (!capable(CAP_SYS_RAWIO))
> + return -EPERM;
> + }
> + regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) | (level << 12);
> +
> + return 0;
> +}
> -asmlinkage long sys_iopl(unsigned long regsp)
> -{
> - volatile struct pt_regs *regs = (struct pt_regs *)
> - unsigned int level = regs->bx;
> - unsigned int old = (regs->flags >> 12) & 3;
> - struct thread_struct *t = >thread;
> -
> - if (level > 3)
> - return -EINVAL;
> - /* Trying to gain more privileges? */
> - if (level > old) {
> - if (!capable(CAP_SYS_RAWIO))
> - return -EPERM;
> - }
> -
> - t->iopl = level << 12;
> - regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) | t->iopl;
> - set_iopl_mask(t->iopl);
> -
> - return 0;
> -}
Is it OK that we lost the different final steps of those two functions?
It looks like someone might have missed the differing tail sections of
the function when copying and pasting and updating just the start of the
functions?
Sorry if I missed why this is OK and intended, I didn't read very closely.
- z
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: STT_FUNC for assembler checksum and semaphore ops" in git-x86
On Thu, Jan 10, 2008 at 04:59:52PM -0800, John Reiser wrote: > Andi Kleen wrote: > > But actually checking the default implementation in linkage.h already > > implements size: [snip] > > > Are you sure it doesn't work? Your patch should be not needed. If it's > > still wrong then just ENDPROCs() need to be added. > > The ENDPROCs() were not used everywhere. Some code used just END() instead, > while other code used nothing. um/sys-i386/checksum.S didn't #include END() is fine too since it contains .size too: #ifndef END #define END(name) \ .size name, .-name #endif > diff --git a/arch/x86/lib/semaphore_32.S b/arch/x86/lib/semaphore_32.S > index 444fba4..e2c6e0d 100644 > --- a/arch/x86/lib/semaphore_32.S > +++ b/arch/x86/lib/semaphore_32.S > @@ -49,7 +49,7 @@ ENTRY(__down_failed) > ENDFRAME > ret > CFI_ENDPROC > - END(__down_failed) > + ENDPROC(__down_failed) I don't think these change makes sense given the definition of END() shown above. The only change that would make sense is adding END() (or ENDPROC()) to a function that doesn't have either of them yet. Since you seem to do nop changes something is wrong with your testing procedure? -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 0/7] convert semaphore to mutex in struct class
On Jan 11, 2008 2:39 AM, Greg KH <[EMAIL PROTECTED]> wrote: > On Thu, Jan 10, 2008 at 05:48:43PM +0800, Dave Young wrote: > > The patches are done on my side, please help to check. > > Along with all of the other comments from people, I have a few. > > > This is the first one of the series about driver core changes. > > If this one is accepted and there's no other problem I will post the others > > for maintainer's review (they need your comment and help because I don't > > know well about the specific driver logic). > > > > Thanks a lot in advance. > > --- > > > > 1. convert class semaphore to mutex. > > 2. add class iterater functions to encapsulate the detail of class > > devices/children list iterating : > > class_for_each_device > > class_find_device > > class_for_each_child > > class_find_child > > No, please create 1 patch per type-of-change. > > So in this case you would have a series of patches: > 1) add the class iterator functions > 2-n) convert the existing places in the kernel using the > class->semaphore to use the new iterator functions > n+1) convert class semaphore to mutex, which should only touch > the driver core Thanks, you are quite right. I will do it when I update the patch next time. > > That way everything builds along the way, and it's easy to understand > and review. > > Oh, and please start a new thread when you create a new patch like this > so it doesn't get burried in people's inboxes... Will do when the new patch available. > > thanks, > > greg k-h > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] convert semaphore to mutex in struct class
On Jan 10, 2008 11:41 PM, Alan Stern <[EMAIL PROTECTED]> wrote: > On Thu, 10 Jan 2008, Dave Young wrote: > > > Hi, > > The patches are done on my side, please help to check. > > > > This is the first one of the series about driver core changes. > > If this one is accepted and there's no other problem I will post the others > > for maintainer's review (they need your comment and help because I don't > > know well about the specific driver logic). > > Before spending too much time on all these conversions, shouldn't you > first determine whether they will work with the lockdep checker? In > one of your earlier messages there was a clear indication that they > will not. Thanks. I managed to build and boot ok with lockdep config options except the apm_power which need to be cross compiled. But not sure whether there's something which are not hit yet. > > Alan Stern > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 0/7] convert semaphore to mutex in struct class
On Jan 10, 2008 9:23 PM, Cornelia Huck <[EMAIL PROTECTED]> wrote:
> On Thu, 10 Jan 2008 17:48:43 +0800,
> Dave Young <[EMAIL PROTECTED]> wrote:
>
> Please add a kerneldoc comment for each of the new interfaces.
Will do.
>
> > +int class_for_each_device(struct class *class, void *data,
> > +int (*fn)(struct device *, void *))
> > +{
> > + struct device *dev;
> > + int error = 0;
> > +
> > + if (!class)
> > + return -EINVAL;
> > + mutex_lock(>mutex);
> > + list_for_each_entry(dev, >devices, node) {
> > + error = fn(dev, data);
>
> Hm, the equivalent _for_each_device() functions all elevate the
> device's refcount while calling fn(). I wonder whether we want this
> here as well?
Thanks for comment.
Hm, I'm not sure about this. Greg, what's your opinion?
>
> > + if (error)
> > + break;
> > + }
> > + mutex_unlock(>mutex);
> > +
> > + return error;
> > +}
> > +EXPORT_SYMBOL_GPL(class_for_each_device);
> > +
> > +struct device *class_find_device(struct class *class, void *data,
> > +int (*match)(struct device *, void *))
> > +{
> > + struct device *dev;
> > +
> > + if (!class)
> > + return NULL;
> > +
> > + mutex_lock(>mutex);
> > + list_for_each_entry(dev, >devices, node)
> > + if (match(dev, data) && get_device(dev))
>
> First get the reference and then drop it if the match function returns
> 0 to make this analogous to the other _find_device() functions?
It's just like other _find_device() functions. Are these more get/put
really needed?
>
> > + break;
> > + mutex_unlock(>mutex);
> > +
> > + return dev;
> > +}
> > +EXPORT_SYMBOL_GPL(class_find_device);
> > +
> > +int class_for_each_child(struct class *class, void *data,
> > +int (*fn)(struct class_device *, void *))
>
> Haven't looked at the callers, but isn't it better to convert them to
> use struct device instead so we don't need to introduce new
> class_device api?
The drivers/scsi/hosts.c need it.
>
> > +{
> > + struct class_device *dev;
> > + int error = 0;
> > +
> > + if (!class)
> > + return -EINVAL;
> > + mutex_lock(>mutex);
> > + list_for_each_entry(dev, >children, node) {
> > + error = fn(dev, data);
>
> Same comment as above concerning reference counts.
>
> > + if (error)
> > + break;
> > + }
> > + mutex_unlock(>mutex);
> > +
> > + return error;
> > +}
> > +EXPORT_SYMBOL_GPL(class_for_each_child);
> > +
> > +struct class_device *class_find_child(struct class *class, void *data,
> > +int (*match)(struct class_device *, void
> > *))
> > +{
> > + struct class_device *dev;
> > +
> > + if (!class)
> > + return NULL;
> > +
> > + mutex_lock(>mutex);
> > + list_for_each_entry(dev, >children, node)
> > + if (match(dev, data) && class_device_get(dev))
>
> And here.
>
>
> > + break;
> > + mutex_unlock(>mutex);
> > +
> > + return dev;
> > +}
> > +EXPORT_SYMBOL_GPL(class_find_child);
> > +
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: hwclock failure in x86.git
On Thu, 10 Jan 2008 17:13:51 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Kevin Winchester wrote:
> > H. Peter Anvin wrote:
> >> Kevin Winchester wrote:
> >>> My first time building and booting the mm branch of x86.git was pretty
> >>> successful. The only error I noticed was the following in my dmesg:
> >>>
> >>> hwclock[622] general protection ip:804b226 sp:bff43e30 error:0
> >>>
> >>> I'm not sure exactly how to debug this. I could bisect, but there seems
> >>> to be some useful debug information in there, so there might be
> >>> something better to try first.
> >>>
> >> That's a userspace IP; it implies the userspace hwclock binary did
> >> something bad, or the kernel didn't permit it to do something it should
> >> have. The best thing to do would probably to strace hwclock and see
> >> what it did when it died.
> >>
> >
> > Unfortunately, but the time I can get a chance to run hwclock, the
> > problem seems to have fixed itself. I tried booting into single user
> > mode, but `/etc/init.d/hwclock.sh restart` succeeds once I have my prompt.
> >
>
> The other thing you can do is to download the debug information and
> source code for hwclock from your particular distro, and find out
> exactly what operation inside the hwclock binary is triggering the segfault.
>
> The only other option is to bisect.
>
The first thing I notice about the path is that ioport_32.c and the unified
ioport.c use __clear_bit,
while ioport_64.c uses clear_bit.
>From include/asm-x86/bitops.h:
static inline void clear_bit(int nr, volatile void *addr)
{
asm volatile(LOCK_PREFIX "btr %1,%0"
: ADDR
: "Ir" (nr));
}
static inline void __clear_bit(int nr, volatile void *addr)
{
asm volatile("btr %1,%0" : ADDR : "Ir" (nr));
}
so it looks like we removed a lock prefix for the 64-bit case. Was that
intentional? Since I'm building for 32-bit, I'm not sure why I was affected,
so maybe my problem is different. Ingo, didn't you have a script somewhere to
test the before and after of unification patches (or am I remembering something
else)?
commit 4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b
Author: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wed Jan 9 13:31:11 2008 +0100
x86: ioport_{32|64}.c unification
ioport_{32|64}.c unification.
This patch unifies the code from the ioport_32.c and ioport_64.c files.
Tested and working fine with i386 and x86_64 kernels.
Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 8b4a8de..91a1795 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -10,7 +10,7 @@ CFLAGS_vsyscall_64.o := $(PROFILING) -g0
obj-y := process_$(BITS).o signal_$(BITS).o entry_$(BITS).o
obj-y += traps_$(BITS).o irq_$(BITS).o
-obj-y += time_$(BITS).o ioport_$(BITS).o ldt.o
+obj-y += time_$(BITS).o ioport.o ldt.o
obj-y += setup_$(BITS).o i8259_$(BITS).o
obj-$(CONFIG_X86_32) += sys_i386_32.o i386_ksyms_32.o
obj-$(CONFIG_X86_64) += sys_x86_64.o x8664_ksyms_64.o
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
new file mode 100644
index 000..e723ff3
--- /dev/null
+++ b/arch/x86/kernel/ioport.c
@@ -0,0 +1,150 @@
+/*
+ * This contains the io-permission bitmap code - written by obz, with changes
+ * by Linus. 32/64 bits code unification by Miguel Botón.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Set EXTENT bits starting at BASE in BITMAP to value TURN_ON. */
+static void set_bitmap(unsigned long *bitmap, unsigned int base,
+ unsigned int extent, int new_value)
+{
+ unsigned int i;
+
+ for (i = base; i < base + extent; i++) {
+ if (new_value)
+ __set_bit(i, bitmap);
+ else
+ __clear_bit(i, bitmap);
+ }
+}
+
+/*
+ * this changes the io permissions bitmap in the current task.
+ */
+asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int turn_on)
+{
+ struct thread_struct * t = >thread;
+ struct tss_struct * tss;
+ unsigned int i, max_long, bytes, bytes_updated;
+
+ if ((from + num <= from) || (from + num > IO_BITMAP_BITS))
+ return -EINVAL;
+ if (turn_on && !capable(CAP_SYS_RAWIO))
+ return -EPERM;
+
+ /*
+* If it's the first ioperm() call in this thread's lifetime, set the
+* IO bitmap up. ioperm() is much less timing critical than clone(),
+* this is why we delay this operation until now:
+*/
+ if (!t->io_bitmap_ptr) {
+ unsigned long *bitmap = kmalloc(IO_BITMAP_BYTES, GFP_KERNEL);
+
+
Re: Serverworks Oops with the very latest git kernel...
Trond Myklebust wrote:
Hi,
I'm getting the following Oops on boot with kernel 2.6.24-rc7-g88fb61e4.
Starting udev: BUG: unable to handle kernel paging request at virtual address
2d6d3a65
printing eip: c04e1af1 *pde =
Oops: [#1] PREEMPT SMP
Modules linked in: evdev evbug rtc_cmos pcspkr floppy rtc_core rtc_lib shpchp pci_hotplug serverworks tg3 generic i2c_piix4 i2c_core
Pid: 1820, comm: modprobe Not tainted (2.6.24-rc7-g88fb61e4 #2)
EIP: 0060:[] EFLAGS: 00210286 CPU: 0
EIP is at strstr+0x11/0x34
EAX: EBX: 2d6d3a65 ECX: EDX: 2d6d3a65
ESI: c0513f75 EDI: 2d6d3a65 EBP: f65bccec ESP: f65bcce0
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process modprobe (pid: 1820, ti=f65bc000 task=f795a2f0 task.ti=f65bc000)
Stack: f8921a44 0001 f65bcd00 c054a0b9 f892e394 f892e080 f892e5f8
f65bcd20 f892133b c04d7c9d f892da80 f891d339 f892e394 f892e080 f892e5f8
f65bcd64 f891d11f f891d339 f891bc38 f892e080 0001
Call Trace:
[] show_trace_log_lvl+0x1a/0x2f
[] show_stack_log_lvl+0x9d/0xa5
[] show_registers+0xa3/0x1df
[] die+0x121/0x204
[] do_page_fault+0x557/0x63e
[] error_code+0x72/0x78
[] dmi_check_system+0x2f/0x58
[] ide_acpi_init+0x28/0x195 [ide_core]
[] hwif_init+0x324/0x37c [ide_core]
[] ide_device_add+0x3b/0xa6 [ide_core]
[] ide_setup_pci_device+0x36/0x40 [ide_core]
[] svwks_init_one+0x5b/0x62 [serverworks]
[] pci_device_probe+0x39/0x5b
[] driver_probe_device+0xe9/0x16a
[] __driver_attach+0x6c/0xa5
[] bus_for_each_dev+0x36/0x5b
[] driver_attach+0x19/0x1b
[] bus_add_driver+0x73/0x1aa
[] driver_register+0x67/0x6c
[] __pci_register_driver+0x56/0x83
[] svwks_ide_init+0x17/0x19 [serverworks]
[] sys_init_module+0x15da/0x1715
[] sysenter_past_esp+0x5f/0xa5
===
Code: e5 89 c1 89 c8 eb 06 80 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 5d c3 90 90 90 55 89 e5 57 56 53 89 c6 89 d3 31 c0 83 c9 ff 89
EIP: [] strstr+0x11/0x34 SS:ESP 0068:f65bcce0
---[ end trace f0316f1e9ff3 ]---
udevd-event[1819]: run_program: '/sbin/modprobe' abnormal exit
Any ideas? As far as I can see, 2.6.24-rc7 itself is good, so I suspect
the recent merge by Bart.
I've set up a bugzilla entry for the regression on
http://bugzilla.kernel.org/show_bug.cgi?id=9728
Does this patch fix it?
Looks like an unterminated DMI table...
Jeff
diff --git a/drivers/ide/ide-acpi.c b/drivers/ide/ide-acpi.c
index fe6768a..8b23ea5 100644
--- a/drivers/ide/ide-acpi.c
+++ b/drivers/ide/ide-acpi.c
@@ -85,6 +85,8 @@ static const struct dmi_system_id ide_acpi_dmi_table[] = {
DMI_MATCH(DMI_BIOS_VERSION, "KAM1.60")
},
},
+
+ { }
};
static int ide_acpi_blacklist(void)
Re: [ipw3945-devel] [PATCH 4/5] iwlwifi: iwl3945 eliminate sleepable task queue from context
2008/1/11, Zhu Yi <[EMAIL PROTECTED]>: > > The version doesn't work on a .24-rc kernel. Can you compile it > with .23? > Thank you for your help, I built it. Thanks, Joonwoo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] AMD Thermal Interrupt Support
All,
Here's the hopefully-final version of the patch, which I have just
tested on Intel and AMD.
In my AMD test, I happened to discover that although MCEs were being
logged, the MCE counter at
/sys/devices/system/cpu/cpu(whatever)/thermal_throttle/count was not
being updated. I fixed this by (1) moving smp_thermal_init from
late_initcall to device_initcall in mce_amd_64.c (2) moving
thermal_throttle_init_device from device_initcall to late_initcall in
therm_throt.c.
Thanks to Andi for his notes on how to hack up an indirect call in
AT X86-64.
To reiterate my earlier general description of the patch:
This patch adds thermal machine check event (MCE) support to AMD
Barcelona (and probably later, if new PCI IDs are added to
k8_northbridges[]), styled after the same in the Intel code. The
initialization consists of 3 parts: (1) northbridge, which enables the
delivery of the interrupt to the local APIC, (2) APIC, which enables
delivery to X86, and (3) hotplug support in threshold_cpu_callback(),
which accomplishes #2 for CPUs which (re)enter the OS later.
Whenever the temperature reaches the throttling threshold programmed
into a northbridge register (by the BIOS -- my code doesn't change
this value), a thermal interrupt is delivered. The interrupt is
delivered to the vector specified in the thermal APIC register at
(APIC_BASE + 0x330), which is identical to Intel. Because the vector
register is the same between both architectures, and because I don't
know which brand of CPU is present until runtime (if either),
thermal_interrupt in entry_64.S will branch to smp_thermal_interrupt
in mce_thermal.c. In turn, smp_thermal_interrupt will branch to the
CPU-specific code for handling the interrupt. (Apart from the common
vector location, AMD and Intel use radically different architectures
for the purpose of reporting throttling events.) At that point, an
MCE is logged if and only if the temperature has made a low-to-high
transition. Rate limiting is employed so as not to spam the log.
--
Russell Leidich
Signed-off-by: Russell Leidich <[EMAIL PROTECTED]>
diff -uprN linux-2.6.24-rc5.orig/arch/x86/kernel/cpu/mcheck/Makefile
linux-2.6.24-rc5/arch/x86/kernel/cpu/mcheck/Makefile
--- linux-2.6.24-rc5.orig/arch/x86/kernel/cpu/mcheck/Makefile 2007-12-11
14:30:53.533297000 -0800
+++ linux-2.6.24-rc5/arch/x86/kernel/cpu/mcheck/Makefile2007-12-11
11:56:20.549185000 -0800
@@ -1,4 +1,4 @@
-obj-y = mce_$(BITS).o therm_throt.o
+obj-y = mce_$(BITS).o therm_throt.o mce_thermal.o
obj-$(CONFIG_X86_32) += k7.o p4.o p5.o p6.o winchip.o
obj-$(CONFIG_X86_MCE_INTEL)+= mce_intel_64.o
diff -uprN linux-2.6.24-rc5.orig/arch/x86/kernel/cpu/mcheck/mce_amd_64.c
linux-2.6.24-rc5/arch/x86/kernel/cpu/mcheck/mce_amd_64.c
--- linux-2.6.24-rc5.orig/arch/x86/kernel/cpu/mcheck/mce_amd_64.c
2007-12-11 14:30:53.559298000 -0800
+++ linux-2.6.24-rc5/arch/x86/kernel/cpu/mcheck/mce_amd_64.c2008-01-10
16:14:28.684763000 -0800
@@ -20,15 +20,18 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
-#include
#include
#include
#include
+#include
+#include
+#include "mce_thermal.h"
#define PFX "mce_threshold: "
#define VERSION "version 1.1.1"
@@ -46,6 +49,16 @@
#define MASK_ERR_COUNT_HI 0x0FFF
#define MASK_BLKPTR_LO0xFF00
#define MCG_XBLK_ADDR 0xC400
+#define THERM_CTL_F3X64 0x64
+#define PSL_APIC_LO_EN0x80
+#define PSL_APIC_HI_EN0x40
+#define HTC_ACTIVE0x10
+#define HTC_EN1
+#define NB_PCI_DEV_BASE 0x18
+
+static int smp_thermal_interrupt_init(void);
+static int thermal_apic_init_allowed;
+static void thermal_apic_init(void *unused);
struct threshold_block {
unsigned int block;
@@ -657,6 +670,9 @@ static int threshold_cpu_callback(struct
case CPU_ONLINE:
case CPU_ONLINE_FROZEN:
threshold_create_device(cpu);
+ if (thermal_apic_init_allowed)
+ smp_call_function_single(cpu,
+ _apic_init, NULL, 1, 0);
break;
case CPU_DEAD:
case CPU_DEAD_FROZEN:
@@ -665,7 +681,7 @@ static int threshold_cpu_callback(struct
default:
break;
}
- out:
+out:
return NOTIFY_OK;
}
@@ -688,3 +704,182 @@ static __init int threshold_init_device(
}
device_initcall(threshold_init_device);
+
+/*
+ * AMD-specific thermal interrupt handler.
+ */
+void amd_smp_thermal_interrupt(void)
+{
+ unsigned int cpu = smp_processor_id();
+
+ ack_APIC_irq();
+ exit_idle();
+ irq_enter();
+ /*
+* We're here because thermal throttling has just been activated -- not
+* deactivated -- hence therm_throt_process(1).
+*/
+ if (therm_throt_process(1))
+ mce_log_therm_throt_event(cpu, 1);
+ /*
+*
Re: [PATCH 0/7] convert semaphore to mutex in struct class
On Jan 10, 2008 8:34 PM, Stefan Richter <[EMAIL PROTECTED]> wrote:
> Dave Young wrote:
> > This is the first one of the series about driver core changes.
>
> Please always provide kerneldoc comments when you add new API elements;
> here: exported functions.
>
> It's unfortunate that the driver core's API isn't fully documented yet,
> and you shouldn't make it worse.
>
> That's only my personal opinion as one API user though. But others
> might agree. Among else, things worth documenting are return values
> after errors, side effects (!), constraints on the calling context if
> there are any special constraints.
>
> I assume you didn't write documentation yet because you need general
> feedback first.
Yes, I did not. Thanks for pointing out, I will do.
>
> ...
> > +struct device *class_find_device(struct class *class, void *data,
> > +int (*match)(struct device *, void *))
> > +{
> > + struct device *dev;
> > +
> > + if (!class)
> > + return NULL;
> > +
> > + mutex_lock(>mutex);
> > + list_for_each_entry(dev, >devices, node)
> > + if (match(dev, data) && get_device(dev))
> > + break;
> > + mutex_unlock(>mutex);
> > +
> > + return dev;
> > +}
>
> What is returned if there was no match?
> What if there was a match but get_ failed?
Will fix it.
>
> ...
> > +struct class_device *class_find_child(struct class *class, void *data,
> > +int (*match)(struct class_device *, void
> > *))
> > +{
> ...
> > + mutex_lock(>mutex);
> > + list_for_each_entry(dev, >children, node)
> > + if (match(dev, data) && class_device_get(dev))
> > + break;
> > + mutex_unlock(>mutex);
> > +
> > + return dev;
> > +}
>
> Here too?
Will fix it.
>
> --
> Stefan Richter
> -=-==--- ---= -=-=-
> http://arcgraph.de/sr/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Fwd: Fwd: laptop / computer hardlocks during execution of 32bit applications(binaries) on 64bit system (Gentoo)
>> - if yes, does booting with "nmi_watchdog=2 idle=poll" give you a >> working NMI watchdog? (working NMI watchdog means the NMI counts >> increase for all cores in /proc/interrupts). > booting with the above gives me an incrementing NMI counter in > /proc/interrupts Ingo, Is there anything else that needs to be set in the kernel config for the nmi watchdog to trigger? I ask because I just had a hang but nothing showed on the _serial_ console - I waited a couple of minutes before rebooting Is there any other way to verify the watchdog is working? I seem to need X active with mix of 32 and 64 bit applications active to get hung here. A massivily threaded 64 bit java app along with 32 bit firefox and a wine active will eventually trigger things here. If I had to guess I would say that it the switch from 32 to 64 (or vise versa) that triggers the isuue. TIA & test/debug patches welcome, Ed Tomlinson -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Serverworks Oops with the very latest git kernel...
Hi, I'm getting the following Oops on boot with kernel 2.6.24-rc7-g88fb61e4. Starting udev: BUG: unable to handle kernel paging request at virtual address 2d6d3a65 printing eip: c04e1af1 *pde = Oops: [#1] PREEMPT SMP Modules linked in: evdev evbug rtc_cmos pcspkr floppy rtc_core rtc_lib shpchp pci_hotplug serverworks tg3 generic i2c_piix4 i2c_core Pid: 1820, comm: modprobe Not tainted (2.6.24-rc7-g88fb61e4 #2) EIP: 0060:[] EFLAGS: 00210286 CPU: 0 EIP is at strstr+0x11/0x34 EAX: EBX: 2d6d3a65 ECX: EDX: 2d6d3a65 ESI: c0513f75 EDI: 2d6d3a65 EBP: f65bccec ESP: f65bcce0 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process modprobe (pid: 1820, ti=f65bc000 task=f795a2f0 task.ti=f65bc000) Stack: f8921a44 0001 f65bcd00 c054a0b9 f892e394 f892e080 f892e5f8 f65bcd20 f892133b c04d7c9d f892da80 f891d339 f892e394 f892e080 f892e5f8 f65bcd64 f891d11f f891d339 f891bc38 f892e080 0001 Call Trace: [] show_trace_log_lvl+0x1a/0x2f [] show_stack_log_lvl+0x9d/0xa5 [] show_registers+0xa3/0x1df [] die+0x121/0x204 [] do_page_fault+0x557/0x63e [] error_code+0x72/0x78 [] dmi_check_system+0x2f/0x58 [] ide_acpi_init+0x28/0x195 [ide_core] [] hwif_init+0x324/0x37c [ide_core] [] ide_device_add+0x3b/0xa6 [ide_core] [] ide_setup_pci_device+0x36/0x40 [ide_core] [] svwks_init_one+0x5b/0x62 [serverworks] [] pci_device_probe+0x39/0x5b [] driver_probe_device+0xe9/0x16a [] __driver_attach+0x6c/0xa5 [] bus_for_each_dev+0x36/0x5b [] driver_attach+0x19/0x1b [] bus_add_driver+0x73/0x1aa [] driver_register+0x67/0x6c [] __pci_register_driver+0x56/0x83 [] svwks_ide_init+0x17/0x19 [serverworks] [] sys_init_module+0x15da/0x1715 [] sysenter_past_esp+0x5f/0xa5 === Code: e5 89 c1 89 c8 eb 06 80 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 5d c3 90 90 90 55 89 e5 57 56 53 89 c6 89 d3 31 c0 83 c9 ff 89 EIP: [] strstr+0x11/0x34 SS:ESP 0068:f65bcce0 ---[ end trace f0316f1e9ff3 ]--- udevd-event[1819]: run_program: '/sbin/modprobe' abnormal exit Any ideas? As far as I can see, 2.6.24-rc7 itself is good, so I suspect the recent merge by Bart. I've set up a bugzilla entry for the regression on http://bugzilla.kernel.org/show_bug.cgi?id=9728 Cheers Trond -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hwclock failure in x86.git
On Thu, 10 Jan 2008 17:13:51 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Kevin Winchester wrote:
> > H. Peter Anvin wrote:
> >> Kevin Winchester wrote:
> >>> My first time building and booting the mm branch of x86.git was pretty
> >>> successful. The only error I noticed was the following in my dmesg:
> >>>
> >>> hwclock[622] general protection ip:804b226 sp:bff43e30 error:0
> >>>
> >>> I'm not sure exactly how to debug this. I could bisect, but there seems
> >>> to be some useful debug information in there, so there might be
> >>> something better to try first.
> >>>
> >> That's a userspace IP; it implies the userspace hwclock binary did
> >> something bad, or the kernel didn't permit it to do something it should
> >> have. The best thing to do would probably to strace hwclock and see
> >> what it did when it died.
> >>
> >
> > Unfortunately, but the time I can get a chance to run hwclock, the
> > problem seems to have fixed itself. I tried booting into single user
> > mode, but `/etc/init.d/hwclock.sh restart` succeeds once I have my prompt.
> >
>
> The other thing you can do is to download the debug information and
> source code for hwclock from your particular distro, and find out
> exactly what operation inside the hwclock binary is triggering the segfault.
>
> The only other option is to bisect.
>
Bisect says...
4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b is first bad commit
commit 4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b
Author: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wed Jan 9 13:31:11 2008 +0100
x86: ioport_{32|64}.c unification
ioport_{32|64}.c unification.
This patch unifies the code from the ioport_32.c and ioport_64.c files.
Tested and working fine with i386 and x86_64 kernels.
Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
I'll take a look at the unification and see if I can see anything obvious.
--
Kevin Winchester <[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: [ipw3945-devel] [PATCH 4/5] iwlwifi: iwl3945 eliminate sleepable task queue from context
On Fri, 2008-01-11 at 10:38 +0900, Joonwoo Park wrote: > I should have checked code base, it's my fault. > it's seems very similar, but I could not made build unfortunately. > Can you introduce to me how to build it please? > > my build error is here: > [EMAIL PROTECTED] ~/SRC/DRIVERS/iwlwifi $ > KSRC=/home/jason/SRC/LINUX/linux-2.6 make The version doesn't work on a .24-rc kernel. Can you compile it with .23? Thanks, -yi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [ipw3945-devel] [PATCH 4/5] iwlwifi: iwl3945 eliminate sleepable task queue from context
2008/1/11, Zhu Yi <[EMAIL PROTECTED]>: > Hi Joonwoo, > > We already did something similiar in our code base. Could you please > take a look at this patch? > > http://intellinuxwireless.org/repos/?p=iwlwifi.git;a=commitdiff;h=57aa02255e9d7be5e2494683fc2793bd1d0707e2 > > Thanks, > -yi Ooops :-) I should have checked code base, it's my fault. it's seems very similar, but I could not made build unfortunately. Can you introduce to me how to build it please? my build error is here: [EMAIL PROTECTED] ~/SRC/DRIVERS/iwlwifi $ KSRC=/home/jason/SRC/LINUX/linux-2.6 make make -C /home/jason/SRC/LINUX/linux-2.6 O= M=/home/jason/SRC/DRIVERS/iwlwifi/compatible/ EXTRA_CFLAGS="-DCONFIG_IWL3945_DEBUG=y -DCONFIG_IWL4965_DEBUG=y -DCONFIG_IWL3945_SPECTRUM_MEASUREMENT=y -DCONFIG_IWL4965_SPECTRUM_MEASUREMENT=y -DCONFIG_IWL4965_SENSITIVITY=y -DCONFIG_IWL3945_QOS=y -DCONFIG_IWL4965_QOS=y" modules make[1]: Entering directory `/home/jason/SRC/LINUX/linux-2.6' CC [M] /home/jason/SRC/DRIVERS/iwlwifi/compatible/iwl3945-base.o In file included from /home/jason/SRC/DRIVERS/iwlwifi/compatible/iwl3945-base.c:51: /home/jason/SRC/DRIVERS/iwlwifi/compatible/iwl-3945.h:443: error: expected specifier-qualifier-list before 'ieee80211_key_alg' /home/jason/SRC/DRIVERS/iwlwifi/compatible/iwl3945-base.c: In function 'iwl3945_add_station': /home/jason/SRC/DRIVERS/iwlwifi/compatible/iwl3945-base.c:539: error: implicit declaration of function 'MAC_ARG' /home/jason/SRC/DRIVERS/iwlwifi/compatible/iwl3945-base.c:539: warning: too few arguments for format /home/jason/SRC/DRIVERS/iwlwifi/compatible/iwl3945-base.c: In function 'iwl3945_commit_rxon': /home/jason/SRC/DRIVERS/iwlwifi/compatible/iwl3945-base.c:1161: warning: too few arguments for format /home/jason/SRC/DRIVERS/iwlwifi/compatible/iwl3945-base.c: In function 'iwl3945_update_sta_key_info': /home/jason/SRC/DRIVERS/iwlwifi/compatible/iwl3945-base.c:1400: error: 'struct iwl3945_hw_key' has no member named 'alg' /home/jason/SRC/DRIVERS/iwlwifi/compatible/iwl3945-base.c:1401: error: 'struct iwl3945_hw_key' has no member named 'keylen' /home/jason/SRC/DRIVERS/iwlwifi/compatible/iwl3945-base.c:1402: error: 'struct iwl3945_hw_key' has no member named 'key' /home/jason/SRC/DRIVERS/iwlwifi/compatible/iwl3945-base.c:1402: error: 'struct iwl3945_hw_key' has no member named 'key' /home/jason/SRC/DRIVERS/iwlwifi/compatible/iwl3945-base.c: In function 'iwl3945_build_tx_cmd_hwcrypto': /home/jason/SRC/DRIVERS/iwlwifi/compatible/iwl3945-base.c:2594: error: 'struct iwl3945_hw_key' has no member named 'alg' /home/jason/SRC/DRIVERS/iwlwifi/compatible/iwl3945-base.c:2597: error: 'struct iwl3945_hw_key' has no member named 'keylen' /home/jason/SRC/DRIVERS/iwlwifi/compatible/iwl3945-base.c:2597: error: 'struct iwl3945_hw_key' has no member named 'key' /home/jason/SRC/DRIVERS/iwlwifi/compatible/iwl3945-base.c:2597: error: 'struct iwl3945_hw_key' has no member named 'keylen' /home/jason/SRC/DRIVERS/iwlwifi/compatible/iwl3945-base.c:2597: error: 'struct iwl3945_hw_key' has no member named 'key' /home/jason/SRC/DRIVERS/iwlwifi/compatible/iwl3945-base.c:2597: error: 'struct iwl3945_hw_key' has no member named 'keylen' Thanks, Joonwoo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 0/5] Intro: convert lockd to kthread and fix use-after-free (try #7)
On Thursday January 10, [EMAIL PROTECTED] wrote: > This is the seventh patchset to fix the use-after-free problem in lockd This patch set looks good now. I'm happy to give it a Reviewed-by: NeilBrown <[EMAIL PROTECTED]> Two remaining issues that I would like to see address, but don't necessarily need to be part of this set, are: 1/ When the last nfsd thread dies, lockd should drop all locks, even if there are active nfs mounts. One approach might be: export nlmsvc_invalidate_all call it from nfsd_last_thread worry about how to change grace_period_expire. 2/ get rid of svc_wake_up and ->b_daemon Maybe change b_daemon to b_rqstp and just call wake_up(>b_rqstp->rq_wait) Thanks, NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On Wed, 2008-01-09 at 17:22 -0500, David P. Reed wrote: > Zachary Amsden wrote: > > > > According to Phoenix Technologies book "System BIOS for IBM PCs, > > Compatibles and EISA Computers, 2nd Edition", the I/O port list gives > > > > port 0080h R/W Extra page register (temporary storage) > > > > Despite looking, I've never seen it documented anywhere else, but I > > believe it works on just about every PC platform. Except, apparently, > > my laptop. > > > > > > > The port 80 problem was discovered by me, after months of "bisecting" > the running code around a problem with hanging when using hwclock in > 64-bit mode when ACPI is on. So it kills my laptop, too, and many > currentlaptop motherboards designed by Quanta for HP and Compaq (dv6000, > dv9000, tx1000, apparently) Thanks very much for that - I was debugging this for a while too, and eventually just shut off hwclock. > Your laptop isn't an aberration. It's part of the new generation of > evolved machines that take advantage of the capabilities of ACPI and > SMBIOS and DMI standards that are becoming core parts of the market. I beg to differ. I managed to turn the thing into a brick by upgrading the BIOS (with the correct image, no less) in an attempt to fix it. I just got it back from repair. I'm not sure that is positive evolutionary development, but it certainly does make my laptop an aberration :) FWIW, I fixed the problem locally by recompiling, changing port 80 to port 84 in io.h; works great, and doesn't conflict with any occupied ports. Zach -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] per-task I/O throttling
Andrea Righi wrote: Allow to limit the bandwidth of I/O-intensive processes, like backup tools running in background, large files copy, checksums on huge files, etc. This kind of processes can noticeably impact the system responsiveness for some time and playing with tasks' priority is not always an acceptable solution. This patch allows to specify a maximum I/O rate in sectors per second for each single process via /proc//io_throttle (default is zero, that specify no limit). It would seem to me that this would be vastly more useful in the real world if there were a settable default, so that administrators could avoid having to find and tune individual user processes. And it would seem far less common that the admin would want to set the limit *up* for a given process, and it's likely to be one known to the admin, at least by name. Of course if you want to do the effort to make it fully tunable, it could have a default by UID or GID. Usful on machines shared by students or managers. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [ipw3945-devel] [PATCH 2/5] iwlwifi: iwl3945 synchronize interruptand tasklet for down iwlwifi
Hello Reinette, 2008/1/11, Chatre, Reinette <[EMAIL PROTECTED]>: > > Could synchronize_irq() be moved into iwl_disable_interrupts() ? I am At this time, iwl_disable_interrupts() can be called with irq disabled, so for do that I think additional modification would be needed. > also wondering if we cannot call tasklet_kill() before > iwl_disable_interrupts() ... thus preventing it from being scheduled > when we are going down. Thanks for your catch, it seems tasklet can re-enable interrupts. I'll handle and make an another patch for them at this weekend :) Thanks, Joonwoo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On 10-01-08 08:58, Jaroslav Kysela wrote:
On Thu, 10 Jan 2008, Rene Herman wrote:
On 09-01-08 23:43, Ondrej Zary wrote:
Jaroslav -- in your role as ISA-PnP maintainer and Bjorn, in yours as
having been foollish enough to touch PnP recently:
as hibernation (swsusp) started to work with my CPU, I found that my Turtle
Beach Malibu stops working after resume from hibernation. It's caused by fact
that the card is not enabled on the pnp layer during resume - and thus card
registers are inaccessible (reads return FFs, writes go nowhere).
During resume, pnp_bus_resume() in drivers/pnp/driver.c is called for each pnp
device. This function calls pnp_start_dev() only when the
PNP_DRIVER_RES_DO_NOT_CHANGE bit is NOT seting pnp_drv->flags. But the cs4236
driver in sound/isa/cs423x/cs4236.c explicitly sets the .flags to
PNP_DRIVER_RES_DISABLE - it's value is 3 and that includes
PNP_DRIVER_RES_DO_NOT_CHANGE bit.
Ehm. Isn't that a bit unexpected:
#define PNP_DRIVER_RES_DO_NOT_CHANGE0x0001 /* do not change the state
of the device */
#define PNP_DRIVER_RES_DISABLE 0x0003 /* ensure the device is
disabled */
I'd say that disabling is changing, so isn't this just a braino where
someone meant to write 2 instead of 3?
It's irrelevant. I think that condition in driver.c in suspend and resume
callbacks is invalid, because PNP_DRIVER_RES_DO_NOT_CHANGE means that
resources should not be changed in the pnp core but only in the driver,
but in suspend/resume process are resources preserved, so the condition
should be removed.
I see a PnP resume _consists_ of setting the resources so I can see the test
implementation wise, but yes, conceptually it seems this test shouldn't be
present. So just like the attached then?
Pierre, what was the idea here? Added the other SOBs to the CC as well...
Author of this code is:
author Pierre Ossman <[EMAIL PROTECTED]> Tue, 29 Nov 2005 09:09:32 +0100
committer Jaroslav Kysela <[EMAIL PROTECTED]> Tue, 03 Jan 2006 12:31:30 +0100
[ALSA] [PATCH] alsa: Improved PnP suspend support
Also use the PnP functions to start/stop the devices during the suspend so
that drivers will not have to duplicate this code.
Cc: Adam Belay <[EMAIL PROTECTED]>
Cc: Jaroslav Kysela <[EMAIL PROTECTED]>
Cc: Takashi Iwai <[EMAIL PROTECTED]>
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Takashi Iwai <[EMAIL PROTECTED]>
Rene.
diff --git a/drivers/pnp/driver.c b/drivers/pnp/driver.c
index a262762..12a1645 100644
--- a/drivers/pnp/driver.c
+++ b/drivers/pnp/driver.c
@@ -161,8 +161,7 @@ static int pnp_bus_suspend(struct device *dev, pm_message_t
state)
return error;
}
- if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE) &&
- pnp_can_disable(pnp_dev)) {
+ if (pnp_can_disable(pnp_dev)) {
error = pnp_stop_dev(pnp_dev);
if (error)
return error;
@@ -185,14 +184,17 @@ static int pnp_bus_resume(struct device *dev)
if (pnp_dev->protocol && pnp_dev->protocol->resume)
pnp_dev->protocol->resume(pnp_dev);
- if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE)) {
+ if (pnp_can_write(pnp_dev)) {
error = pnp_start_dev(pnp_dev);
if (error)
return error;
}
- if (pnp_drv->resume)
- return pnp_drv->resume(pnp_dev);
+ if (pnp_drv->resume) {
+ error = pnp_drv->resume(pnp_dev);
+ if (error)
+ return error;
+ }
return 0;
}
Re: questions on NAPI processing latency and dropped network packets
From: "Chris Friesen" <[EMAIL PROTECTED]> Date: Thu, 10 Jan 2008 11:24:19 -0600 > I've got an issue that's popped up with a deployed system running > 2.6.10. ... > So...anyone have any ideas/suggestions? You have to be kidding, coming here for help with a nearly 4 year old kernel. The networking stack as well as the e1000 driver has been practically rewritten several times over since then. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] PM: Acquire device locks on suspend (rev. 3)
Hi,
The patch below is intended as a replacement for
gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch that deadlocked
suspend and hibernation on some systems. The present patch contains some
safeguards against deadlocks in the relevant cases and a mechanism to print
warnings if a deadlock is probable.
Greetings,
Rafael
---
From: Rafael J. Wysocki <[EMAIL PROTECTED]>, Alan Stern <[EMAIL PROTECTED]>
This patch reorganizes the way suspend and resume notifications are
sent to drivers. The major changes are that now the PM core acquires
every device semaphore before calling the methods, and calls to
device_add() during suspends will fail, while calls to device_del()
during suspends will block.
It also provides a way to safely remove a suspended device with the
help of the PM core, by using the device_pm_schedule_removal() callback
introduced specifically for this purpose, and updates two drivers (msr
and cpuid) that need to use it.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
arch/x86/kernel/cpuid.c|6
arch/x86/kernel/msr.c |6
drivers/base/core.c| 65 +
drivers/base/power/main.c | 504 +
drivers/base/power/power.h | 12 +
include/linux/device.h |8
6 files changed, 414 insertions(+), 187 deletions(-)
Index: linux-2.6/drivers/base/core.c
===
--- linux-2.6.orig/drivers/base/core.c
+++ linux-2.6/drivers/base/core.c
@@ -726,11 +726,20 @@ int device_add(struct device *dev)
{
struct device *parent = NULL;
struct class_interface *class_intf;
- int error = -EINVAL;
+ int error;
+
+ error = pm_sleep_lock();
+ if (error) {
+ dev_warn(dev, "Suspicious %s during suspend\n", __FUNCTION__);
+ dump_stack();
+ return error;
+ }
dev = get_device(dev);
- if (!dev || !strlen(dev->bus_id))
+ if (!dev || !strlen(dev->bus_id)) {
+ error = -EINVAL;
goto Error;
+ }
pr_debug("DEV: registering device: ID = '%s'\n", dev->bus_id);
@@ -795,6 +804,7 @@ int device_add(struct device *dev)
}
Done:
put_device(dev);
+ pm_sleep_unlock();
return error;
BusError:
device_pm_remove(dev);
@@ -905,6 +915,7 @@ void device_del(struct device * dev)
struct device * parent = dev->parent;
struct class_interface *class_intf;
+ device_pm_remove(dev);
if (parent)
klist_del(>knode_parent);
if (MAJOR(dev->devt))
@@ -981,7 +992,6 @@ void device_del(struct device * dev)
if (dev->bus)
blocking_notifier_call_chain(>bus->bus_notifier,
BUS_NOTIFY_DEL_DEVICE, dev);
- device_pm_remove(dev);
kobject_uevent(>kobj, KOBJ_REMOVE);
kobject_del(>kobj);
if (parent)
@@ -1156,14 +1166,11 @@ error:
EXPORT_SYMBOL_GPL(device_create);
/**
- * device_destroy - removes a device that was created with device_create()
+ * find_device - finds a device that was created with device_create()
* @class: pointer to the struct class that this device was registered with
* @devt: the dev_t of the device that was previously registered
- *
- * This call unregisters and cleans up a device that was created with a
- * call to device_create().
*/
-void device_destroy(struct class *class, dev_t devt)
+static struct device *find_device(struct class *class, dev_t devt)
{
struct device *dev = NULL;
struct device *dev_tmp;
@@ -1176,12 +1183,54 @@ void device_destroy(struct class *class,
}
}
up(>sem);
+ return dev;
+}
+
+/**
+ * device_destroy - removes a device that was created with device_create()
+ * @class: pointer to the struct class that this device was registered with
+ * @devt: the dev_t of the device that was previously registered
+ *
+ * This call unregisters and cleans up a device that was created with a
+ * call to device_create().
+ */
+void device_destroy(struct class *class, dev_t devt)
+{
+ struct device *dev;
+ dev = find_device(class, devt);
if (dev)
device_unregister(dev);
}
EXPORT_SYMBOL_GPL(device_destroy);
+#ifdef CONFIG_PM_SLEEP
+/**
+ * destroy_suspended_device - asks the PM core to remove a suspended device
+ * @class: pointer to the struct class that this device was registered with
+ * @devt: the dev_t of the device that was previously registered
+ *
+ * This call notifies the PM core of the necessity to unregister a suspended
+ * device created with a call to device_create() (devices cannot be
+ * unregistered directly while suspended, since the PM core holds their
+ * semaphores at that time).
+ *
+ * It can only be called within the scope of a system sleep transition. �In
+ * practice this means it has to be directly or indirectly invoked
Re: hwclock failure in x86.git
Kevin Winchester wrote: H. Peter Anvin wrote: Kevin Winchester wrote: My first time building and booting the mm branch of x86.git was pretty successful. The only error I noticed was the following in my dmesg: hwclock[622] general protection ip:804b226 sp:bff43e30 error:0 I'm not sure exactly how to debug this. I could bisect, but there seems to be some useful debug information in there, so there might be something better to try first. That's a userspace IP; it implies the userspace hwclock binary did something bad, or the kernel didn't permit it to do something it should have. The best thing to do would probably to strace hwclock and see what it did when it died. Unfortunately, but the time I can get a chance to run hwclock, the problem seems to have fixed itself. I tried booting into single user mode, but `/etc/init.d/hwclock.sh restart` succeeds once I have my prompt. The other thing you can do is to download the debug information and source code for hwclock from your particular distro, and find out exactly what operation inside the hwclock binary is triggering the segfault. The only other option is to bisect. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ipw3945-devel] [PATCH 4/5] iwlwifi: iwl3945 eliminate sleepable task queue from context
Hi Joonwoo,
We already did something similiar in our code base. Could you please
take a look at this patch?
http://intellinuxwireless.org/repos/?p=iwlwifi.git;a=commitdiff;h=57aa02255e9d7be5e2494683fc2793bd1d0707e2
Thanks,
-yi
On Wed, 2008-01-09 at 20:02 +0900, Joonwoo Park wrote:
> Eleminiate task queuing of iwl_pci_probe, register hw to ieee80211 immediately
>
> Signed-off-by: Joonwoo Park <[EMAIL PROTECTED]>
> ---
> drivers/net/wireless/iwlwifi/iwl3945-base.c | 66 +-
> 1 files changed, 43 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c
> b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> index f95f226..7e8d8b3 100644
> --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
> +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> @@ -6171,27 +6171,9 @@ static void iwl_alive_start(struct iwl_priv *priv)
> if (iwl_is_rfkill(priv))
> return;
>
> - if (!priv->mac80211_registered) {
> - /* Unlock so any user space entry points can call back into
> - * the driver without a deadlock... */
> - mutex_unlock(>mutex);
> - iwl_rate_control_register(priv->hw);
> - rc = ieee80211_register_hw(priv->hw);
> - priv->hw->conf.beacon_int = 100;
> - mutex_lock(>mutex);
> -
> - if (rc) {
> - iwl_rate_control_unregister(priv->hw);
> - IWL_ERROR("Failed to register network "
> - "device (error %d)\n", rc);
> - return;
> - }
> -
> - priv->mac80211_registered = 1;
> + iwl_reset_channel_flag(priv);
>
> - iwl_reset_channel_flag(priv);
> - } else
> - ieee80211_start_queues(priv->hw);
> + ieee80211_start_queues(priv->hw);
>
> priv->active_rate = priv->rates_mask;
> priv->active_rate_basic = priv->rates_mask & IWL_BASIC_RATES_MASK;
> @@ -6369,7 +6351,8 @@ static int __iwl_up(struct iwl_priv *priv)
>
> /* clear (again), then enable host interrupts */
> iwl_write32(priv, CSR_INT, 0x);
> - iwl_enable_interrupts(priv);
> + if (priv->mac80211_registered)
> + iwl_enable_interrupts(priv);
>
> /* really make sure rfkill handshake bits are cleared */
> iwl_write32(priv, CSR_UCODE_DRV_GP1_CLR, CSR_UCODE_SW_BIT_RFKILL);
> @@ -6887,10 +6870,21 @@ static void iwl_bg_scan_completed(struct work_struct
> *work)
>
> static int iwl_mac_start(struct ieee80211_hw *hw)
> {
> + int ret;
> struct iwl_priv *priv = hw->priv;
>
> IWL_DEBUG_MAC80211("enter\n");
>
> + ret = wait_event_interruptible_timeout(priv->wait_command_queue,
> + iwl_is_ready(priv), HOST_COMPLETE_TIMEOUT);
> +
> + if (ret == -ERESTARTSYS)
> + return ret;
> + else if (ret == 0 && !iwl_is_ready(priv)) {
> + IWL_ERROR("IWL ready timeout\n");
> + return -ETIMEDOUT;
> + }
> +
> /* we should be verifying the device is ready to be opened */
> mutex_lock(>mutex);
>
> @@ -8299,6 +8293,19 @@ static void iwl_cancel_deferred_work(struct iwl_priv
> *priv)
> cancel_work_sync(>beacon_update);
> }
>
> +static int iwl_register_hw(struct iwl_priv *priv)
> +{
> + int err;
> + IWL_DEBUG_INFO("register_hw\n");
> + iwl_rate_control_register(priv->hw);
> + err = ieee80211_register_hw(priv->hw);
> + if (!err) {
> + priv->hw->conf.beacon_int = 100;
> + priv->mac80211_registered = 1;
> + }
> + return err;
> +}
> +
> static struct attribute *iwl_sysfs_entries[] = {
> _attr_antenna.attr,
> _attr_channels.attr,
> @@ -8546,11 +8553,24 @@ static int iwl_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> goto out_pci_alloc;
> }
>
> + err = __iwl_up(priv);
> + if (err) {
> + IWL_ERROR("Could not make up interface : %d\n", err);
> + mutex_unlock(>mutex);
> + goto out_pci_alloc;
> + }
> +
> mutex_unlock(>mutex);
>
> - IWL_DEBUG_INFO("Queing UP work.\n");
> + err = iwl_register_hw(priv);
> + if (err) {
> + iwl_rate_control_unregister(priv->hw);
> + IWL_ERROR("Failed to register network "
> + "device (error %d)\n", err);
> + goto out_pci_alloc;
> + }
>
> - queue_work(priv->workqueue, >up);
> + iwl_enable_interrupts(priv);
>
> return 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: [PATCH][RFC] fast file mapping for loop
Jens Axboe wrote: Hi, loop.c currently uses the page cache interface to do IO to file backed devices. This works reasonably well for simple things, like mapping an iso9660 file for direct mount and other read-only workloads. Writing is somewhat problematic, as anyone who has really used this feature can attest to - it tends to confuse the vm (hello kswapd) since it break dirty accounting and behaves very erratically on writeout. Did I mention that it's pretty slow as well, for both reads and writes? Since you are looking for comments, I'll mention a loop-related behavior I've been seeing and see if it gets comments or is useful, since it can be used to tickle bad behavior on demand. I have an 6GB sparse file, which I mount with cryptoloop and populate as an ext3 filesystem (more later on why). I then copy ~5.8GB of data to the filesystem, which is unmounted to be burnt to a DVD. Before it's burned the "dvdisaster" application is used to add some ECC information to the end, and make an image which fits on a DVD-DL. Media will be burned and distributed to multiple locations. The problem: When copying with rsync, the copy runs at ~25MB/s for a while, then falls into a pattern of bursts of 25MB/s followed by 10-15 sec of iowait with no disk activity. So I tried doing the copy by cpio find . -depth | cpio -pdm /mnt/loop which shows exactly the same behavior. Then, for no good reason I tried find . -depth | cpio -pBdm /mnt/loop and the copy ran at 25MB/s for the whole data set. I was able to see similar results with a pure loop mount, I only mention the crypto for accuracy. Because many of these have been shipped over the last two years and new loop code would only be useful in this case if it were compatible so old data sets could be read. It also behaves differently than a real drive. For writes, completions are done once they hit page cache. Since loop queues bio's async and hands them off to a thread, you can have a huge backlog of stuff to do. It's hard to attempt to guarentee data safety for file systems on top of loop without making it even slower than it currently is. Back when loop was only used for iso9660 mounting and other simple things, this didn't matter. Now it's often used in xen (and others) setups where we do care about performance AND writing. So the below is a attempt at speeding up loop and making it behave like a real device. It's a somewhat quick hack and is still missing one piece to be complete, but I'll throw it out there for people to play with and comment on. So how does it work? Instead of punting IO to a thread and passing it through the page cache, we instead attempt to send the IO directly to the filesystem block that it maps to. loop maintains a prio tree of known extents in the file (populated lazily on demand, as needed). Advantages of this approach: - It's fast, loop will basically work at device speed. - It's fast, loop it doesn't put a huge amount of system load on the system when busy. When I did comparison tests on my notebook with an external drive, running a simple tiobench on the current in-kernel loop with a sparse file backing rendered the notebook basically unusable while the test was ongoing. The remapper version had no more impact than it did when used directly on the external drive. - It behaves like a real block device. - It's easy to support IO barriers, which is needed to ensure safety especially in virtualized setups. Disadvantages: - The file block mappings must not change while loop is using the file. This means that we have to ensure exclusive access to the file and this is the bit that is currently missing in the implementation. It would be nice if we could just do this via open(), ideas welcome... - It'll tie down a bit of memory for the prio tree. This is GREATLY offset by the reduced page cache foot print though. - It cannot be used with the loop encryption stuff. dm-crypt should be used instead, on top of loop (which, I think, is even the recommended way to do this today, so not a big deal). -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: STT_FUNC for assembler checksum and semaphore ops" in git-x86
Andi Kleen wrote:
> But actually checking the default implementation in linkage.h already
> implements size: [snip]
> Are you sure it doesn't work? Your patch should be not needed. If it's
> still wrong then just ENDPROCs() need to be added.
The ENDPROCs() were not used everywhere. Some code used just END() instead,
while other code used nothing. um/sys-i386/checksum.S didn't #include
. I also got confused because gcc puts the
.type near the ENTRY, while ENDPROC puts it on the opposite end.
Here is a revised patch against linux-2.6-x86.git , including a comment
in linkage.h which explains one motivation. PowerPC is different
("_GLOBAL" instead of "ENTRY") and foreign to me, so I left it alone.
Signed off by: John Reiser <[EMAIL PROTECTED]>
diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index ff203dd..024cfab 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -53,6 +53,10 @@
.size name, .-name
#endif
+/* If symbol 'name' is treated as a subroutine (gets called, and returns)
+ * then please use ENDPROC to mark 'name' as STT_FUNC for the benefit of
+ * static analysis tools such as stack depth analyzer.
+ */
#ifndef ENDPROC
#define ENDPROC(name) \
.type name, @function; \
diff --git a/arch/x86/lib/semaphore_32.S b/arch/x86/lib/semaphore_32.S
index 444fba4..e2c6e0d 100644
--- a/arch/x86/lib/semaphore_32.S
+++ b/arch/x86/lib/semaphore_32.S
@@ -49,7 +49,7 @@ ENTRY(__down_failed)
ENDFRAME
ret
CFI_ENDPROC
- END(__down_failed)
+ ENDPROC(__down_failed)
ENTRY(__down_failed_interruptible)
CFI_STARTPROC
@@ -70,7 +70,7 @@ ENTRY(__down_failed_interruptible)
ENDFRAME
ret
CFI_ENDPROC
- END(__down_failed_interruptible)
+ ENDPROC(__down_failed_interruptible)
ENTRY(__down_failed_trylock)
CFI_STARTPROC
@@ -91,7 +91,7 @@ ENTRY(__down_failed_trylock)
ENDFRAME
ret
CFI_ENDPROC
- END(__down_failed_trylock)
+ ENDPROC(__down_failed_trylock)
ENTRY(__up_wakeup)
CFI_STARTPROC
@@ -112,7 +112,7 @@ ENTRY(__up_wakeup)
ENDFRAME
ret
CFI_ENDPROC
- END(__up_wakeup)
+ ENDPROC(__up_wakeup)
/*
* rw spinlock fallbacks
@@ -132,7 +132,7 @@ ENTRY(__write_lock_failed)
ENDFRAME
ret
CFI_ENDPROC
- END(__write_lock_failed)
+ ENDPROC(__write_lock_failed)
ENTRY(__read_lock_failed)
CFI_STARTPROC
@@ -148,7 +148,7 @@ ENTRY(__read_lock_failed)
ENDFRAME
ret
CFI_ENDPROC
- END(__read_lock_failed)
+ ENDPROC(__read_lock_failed)
#endif
@@ -170,7 +170,7 @@ ENTRY(call_rwsem_down_read_failed)
CFI_ADJUST_CFA_OFFSET -4
ret
CFI_ENDPROC
- END(call_rwsem_down_read_failed)
+ ENDPROC(call_rwsem_down_read_failed)
ENTRY(call_rwsem_down_write_failed)
CFI_STARTPROC
@@ -182,7 +182,7 @@ ENTRY(call_rwsem_down_write_failed)
CFI_ADJUST_CFA_OFFSET -4
ret
CFI_ENDPROC
- END(call_rwsem_down_write_failed)
+ ENDPROC(call_rwsem_down_write_failed)
ENTRY(call_rwsem_wake)
CFI_STARTPROC
@@ -196,7 +196,7 @@ ENTRY(call_rwsem_wake)
CFI_ADJUST_CFA_OFFSET -4
1: ret
CFI_ENDPROC
- END(call_rwsem_wake)
+ ENDPROC(call_rwsem_wake)
/* Fix up special calling conventions */
ENTRY(call_rwsem_downgrade_wake)
@@ -214,6 +214,6 @@ ENTRY(call_rwsem_downgrade_wake)
CFI_ADJUST_CFA_OFFSET -4
ret
CFI_ENDPROC
- END(call_rwsem_downgrade_wake)
+ ENDPROC(call_rwsem_downgrade_wake)
#endif
diff --git a/arch/um/sys-i386/checksum.S b/arch/um/sys-i386/checksum.S
index 62c7e56..4f3f62b 100644
--- a/arch/um/sys-i386/checksum.S
+++ b/arch/um/sys-i386/checksum.S
@@ -26,6 +26,7 @@
*/
#include
+#include
/*
* computes a partial checksum, e.g. for TCP/UDP fragments
@@ -48,7 +49,7 @@ unsigned int csum_partial(const unsigned char * buff, int
len, unsigned int sum)
* Fortunately, it is easy to convert 2-byte alignment to 4-byte
* alignment for the unrolled loop.
*/
-csum_partial:
+ENTRY(csum_partial)
pushl %esi
pushl %ebx
movl 20(%esp),%eax # Function arg: unsigned int sum
@@ -113,12 +114,13 @@ csum_partial:
popl %ebx
popl %esi
ret
+ ENDPROC(csum_partial)
#else
/* Version for PentiumII/PPro */
-csum_partial:
+ENTRY(csum_partial)
pushl %esi
pushl %ebx
movl 20(%esp),%eax # Function arg: unsigned int sum
@@ -211,6 +213,7 @@ csum_partial:
popl %ebx
popl %esi
ret
+ ENDPROC(csum_partial)
#endif
@@ -250,7 +253,7 @@ unsigned int csum_partial_copy_generic (const char *src,
char *dst,
#define ARGBASE 16
#define FP 12
-csum_partial_copy_generic_i386:
+ENTRY(csum_partial_copy_generic_i386)
[PATCH 2/2][RFC][BUG] msync: updating ctime and mtime at syncing
From: Anton Salikhmetov <[EMAIL PROTECTED]>
The patch contains changes for updating the ctime and mtime fields for memory
mapped files:
1) adding a new flag triggering update of the inode data;
2) implementing a helper function for checking that flag and updating ctime and
mtime;
3) updating time stamps for mapped files in sys_msync() and do_fsync().
Signed-off-by: Anton Salikhmetov <[EMAIL PROTECTED]>
---
diff --git a/fs/buffer.c b/fs/buffer.c
index 7249e01..09adf7e 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -719,6 +719,7 @@ static int __set_page_dirty(struct page *page,
}
write_unlock_irq(>tree_lock);
__mark_inode_dirty(mapping->host, I_DIRTY_PAGES);
+ set_bit(AS_MCTIME, >flags);
return 1;
}
diff --git a/fs/inode.c b/fs/inode.c
index ed35383..c5b954e 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
/*
* This is needed for the following functions:
@@ -1282,6 +1283,18 @@ void file_update_time(struct file *file)
EXPORT_SYMBOL(file_update_time);
+/*
+ * Update the ctime and mtime stamps after checking if they are to be updated.
+ */
+void mapped_file_update_time(struct file *file)
+{
+ if (test_and_clear_bit(AS_MCTIME, >f_mapping->flags)) {
+ get_file(file);
+ file_update_time(file);
+ fput(file);
+ }
+}
+
int inode_needs_sync(struct inode *inode)
{
if (IS_SYNC(inode))
diff --git a/fs/sync.c b/fs/sync.c
index 7cd005e..df57507 100644
--- a/fs/sync.c
+++ b/fs/sync.c
@@ -87,6 +87,8 @@ long do_fsync(struct file *file, int datasync)
goto out;
}
+ mapped_file_update_time(file);
+
ret = filemap_fdatawrite(mapping);
/*
diff --git a/include/linux/fs.h b/include/linux/fs.h
index b3ec4a4..0b05118 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1978,6 +1978,7 @@ extern int inode_change_ok(struct inode *, struct iattr
*);
extern int __must_check inode_setattr(struct inode *, struct iattr *);
extern void file_update_time(struct file *file);
+extern void mapped_file_update_time(struct file *file);
static inline ino_t parent_ino(struct dentry *dentry)
{
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index db8a410..bf0f9e7 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -17,8 +17,9 @@
* Bits in mapping->flags. The lower __GFP_BITS_SHIFT bits are the page
* allocation mode flags.
*/
-#defineAS_EIO (__GFP_BITS_SHIFT + 0) /* IO error on async
write */
+#define AS_EIO (__GFP_BITS_SHIFT + 0) /* IO error on async write */
#define AS_ENOSPC (__GFP_BITS_SHIFT + 1) /* ENOSPC on async write */
+#define AS_MCTIME (__GFP_BITS_SHIFT + 2) /* mtime and ctime to update */
static inline void mapping_set_error(struct address_space *mapping, int error)
{
diff --git a/mm/msync.c b/mm/msync.c
index e788f7b..9d0a8f9 100644
--- a/mm/msync.c
+++ b/mm/msync.c
@@ -5,6 +5,7 @@
* Copyright (C) 1994-1999 Linus Torvalds
*
* Substantial code cleanup.
+ * Updating the ctime and mtime stamps for memory mapped files.
* Copyright (C) 2008 Anton Salikhmetov <[EMAIL PROTECTED]>
*/
@@ -22,6 +23,10 @@
* Nor does it mark the relevant pages dirty (it used to up to 2.6.17).
* Now it doesn't do anything, since dirty pages are properly tracked.
*
+ * The msync() system call updates the ctime and mtime fields for
+ * the mapped file when called with the MS_SYNC or MS_ASYNC flags
+ * according to the POSIX standard.
+ *
* The application may now run fsync() to
* write out the dirty pages and wait on the writeout and check the result.
* Or the application may run fadvise(FADV_DONTNEED) against the fd to start
@@ -74,14 +79,17 @@ asmlinkage long sys_msync(unsigned long start, size_t len,
int flags)
break;
}
file = vma->vm_file;
- if ((flags & MS_SYNC) && file && (vma->vm_flags & VM_SHARED)) {
- get_file(file);
- up_read(>mmap_sem);
- error = do_fsync(file, 0);
- fput(file);
- if (error)
- return error;
- down_read(>mmap_sem);
+ if (file && (vma->vm_flags & VM_SHARED)) {
+ mapped_file_update_time(file);
+ if (flags & MS_SYNC) {
+ get_file(file);
+ up_read(>mmap_sem);
+ error = do_fsync(file, 0);
+ fput(file);
+ if (error)
+ return error;
+ down_read(>mmap_sem);
+ }
}
start = vma->vm_end;
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index
Re: [PATCH]quirks: set 'En' bit of MSI Mapping for devices on HT-based nvidia platform
On Thu, 10 Jan 2008 22:41:58 +0800 "peerchen" <[EMAIL PROTECTED]> wrote: > Subject: [PATCH]quirks: set 'En' bit of MSI Mapping for devices on HT-based > nvidia platform > > Signed-off-by: Andy Currid <[EMAIL PROTECTED]> > Signed-off-by: Peer Chen <[EMAIL PROTECTED]> You didn't provide a reason for making this change to the kernel. Please do so, and include it in the patch's changelog, 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/
[PATCH 2/2][RFC][BUG] msync: updating ctime and mtime at syncing
From: Anton Salikhmetov <[EMAIL PROTECTED]>
The patch contains changes for updating the ctime and mtime fields for memory
mapped files:
1) adding a new flag triggering update of the inode data;
2) implementing a helper function for checking that flag and updating ctime and
mtime;
3) updating time stamps for mapped files in sys_msync() and do_fsync().
Signed-off-by: Anton Salikhmetov <[EMAIL PROTECTED]>
---
diff --git a/fs/buffer.c b/fs/buffer.c
index 7249e01..09adf7e 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -719,6 +719,7 @@ static int __set_page_dirty(struct page *page,
}
write_unlock_irq(>tree_lock);
__mark_inode_dirty(mapping->host, I_DIRTY_PAGES);
+ set_bit(AS_MCTIME, >flags);
return 1;
}
diff --git a/fs/inode.c b/fs/inode.c
index ed35383..c5b954e 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
/*
* This is needed for the following functions:
@@ -1282,6 +1283,18 @@ void file_update_time(struct file *file)
EXPORT_SYMBOL(file_update_time);
+/*
+ * Update the ctime and mtime stamps after checking if they are to be updated.
+ */
+void mapped_file_update_time(struct file *file)
+{
+ if (test_and_clear_bit(AS_MCTIME, >f_mapping->flags)) {
+ get_file(file);
+ file_update_time(file);
+ fput(file);
+ }
+}
+
int inode_needs_sync(struct inode *inode)
{
if (IS_SYNC(inode))
diff --git a/fs/sync.c b/fs/sync.c
index 7cd005e..df57507 100644
--- a/fs/sync.c
+++ b/fs/sync.c
@@ -87,6 +87,8 @@ long do_fsync(struct file *file, int datasync)
goto out;
}
+ mapped_file_update_time(file);
+
ret = filemap_fdatawrite(mapping);
/*
diff --git a/include/linux/fs.h b/include/linux/fs.h
index b3ec4a4..0b05118 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1978,6 +1978,7 @@ extern int inode_change_ok(struct inode *, struct iattr
*);
extern int __must_check inode_setattr(struct inode *, struct iattr *);
extern void file_update_time(struct file *file);
+extern void mapped_file_update_time(struct file *file);
static inline ino_t parent_ino(struct dentry *dentry)
{
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index db8a410..bf0f9e7 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -17,8 +17,9 @@
* Bits in mapping->flags. The lower __GFP_BITS_SHIFT bits are the page
* allocation mode flags.
*/
-#defineAS_EIO (__GFP_BITS_SHIFT + 0) /* IO error on async
write */
+#define AS_EIO (__GFP_BITS_SHIFT + 0) /* IO error on async write */
#define AS_ENOSPC (__GFP_BITS_SHIFT + 1) /* ENOSPC on async write */
+#define AS_MCTIME (__GFP_BITS_SHIFT + 2) /* mtime and ctime to update */
static inline void mapping_set_error(struct address_space *mapping, int error)
{
diff --git a/mm/msync.c b/mm/msync.c
index e788f7b..9d0a8f9 100644
--- a/mm/msync.c
+++ b/mm/msync.c
@@ -5,6 +5,7 @@
* Copyright (C) 1994-1999 Linus Torvalds
*
* Substantial code cleanup.
+ * Updating the ctime and mtime stamps for memory mapped files.
* Copyright (C) 2008 Anton Salikhmetov <[EMAIL PROTECTED]>
*/
@@ -22,6 +23,10 @@
* Nor does it mark the relevant pages dirty (it used to up to 2.6.17).
* Now it doesn't do anything, since dirty pages are properly tracked.
*
+ * The msync() system call updates the ctime and mtime fields for
+ * the mapped file when called with the MS_SYNC or MS_ASYNC flags
+ * according to the POSIX standard.
+ *
* The application may now run fsync() to
* write out the dirty pages and wait on the writeout and check the result.
* Or the application may run fadvise(FADV_DONTNEED) against the fd to start
@@ -74,14 +79,17 @@ asmlinkage long sys_msync(unsigned long start, size_t len,
int flags)
break;
}
file = vma->vm_file;
- if ((flags & MS_SYNC) && file && (vma->vm_flags & VM_SHARED)) {
- get_file(file);
- up_read(>mmap_sem);
- error = do_fsync(file, 0);
- fput(file);
- if (error)
- return error;
- down_read(>mmap_sem);
+ if (file && (vma->vm_flags & VM_SHARED)) {
+ mapped_file_update_time(file);
+ if (flags & MS_SYNC) {
+ get_file(file);
+ up_read(>mmap_sem);
+ error = do_fsync(file, 0);
+ fput(file);
+ if (error)
+ return error;
+ down_read(>mmap_sem);
+ }
}
start = vma->vm_end;
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index
[PATCH 0/2][RFC][BUG] msync: another attempt to fix the ctime/mtime issue
From: Anton Salikhmetov <[EMAIL PROTECTED]> I would like to propose my second solution for the bug #2645 from the kernel bug tracker: http://bugzilla.kernel.org/show_bug.cgi?id=2645 You may find the relevant background information as well as an extensive discussion of my previous solution using the following link: http://lkml.org/lkml/2008/1/9/387 The short change list: 1) taking into account the intervening sync() call which Peter Staubach has mentioned (http://lkml.org/lkml/2008/1/9/267); 2) splitting the solution into two patches: code cleanup and functional changes; 3) updating ctime and mtime in do_fsync(), due to that the file time stamps get updated even without any explicit call to msync(). Please note that the second patch (functional changes) should be applied on top of the first one (code cleanup). Also I changed my unit test due to Peter's remark: http://lkml.org/lkml/2008/1/9/267 The new version of the unit test can be found here: http://bugzilla.kernel.org/attachment.cgi?id=14398=view No regression was found when I ran the test cases for the msync() system call from the LTP test suite (msync01 - msync05, mmapstress01, mmapstress09, and mmapstress10). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2][RFC][BUG] msync: massive code cleanup of sys_msync()
From: Anton Salikhmetov <[EMAIL PROTECTED]>
The patch contains substantial code cleanup of the sys_msync() function:
1) consolidated error check for function parameters;
2) using the PAGE_ALIGN() macro instead of "manual" alignment;
3) improved readability of the loop traversing the process memory regions.
Signed-off-by: Anton Salikhmetov <[EMAIL PROTECTED]>
---
diff --git a/mm/msync.c b/mm/msync.c
index 144a757..e788f7b 100644
--- a/mm/msync.c
+++ b/mm/msync.c
@@ -1,24 +1,25 @@
/*
* linux/mm/msync.c
*
+ * The msync() system call.
* Copyright (C) 1994-1999 Linus Torvalds
+ *
+ * Substantial code cleanup.
+ * Copyright (C) 2008 Anton Salikhmetov <[EMAIL PROTECTED]>
*/
-/*
- * The msync() system call.
- */
+#include
#include
#include
#include
-#include
-#include
#include
+#include
/*
* MS_SYNC syncs the entire file - including mappings.
*
* MS_ASYNC does not start I/O (it used to, up to 2.5.67).
- * Nor does it marks the relevant pages dirty (it used to up to 2.6.17).
+ * Nor does it mark the relevant pages dirty (it used to up to 2.6.17).
* Now it doesn't do anything, since dirty pages are properly tracked.
*
* The application may now run fsync() to
@@ -33,71 +34,60 @@ asmlinkage long sys_msync(unsigned long start, size_t len,
int flags)
unsigned long end;
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
- int unmapped_error = 0;
- int error = -EINVAL;
+ int error = 0, unmapped_error = 0;
+
+ if ((flags & ~(MS_ASYNC | MS_INVALIDATE | MS_SYNC)) ||
+ (start & ~PAGE_MASK) ||
+ ((flags & MS_ASYNC) && (flags & MS_SYNC)))
+ return -EINVAL;
- if (flags & ~(MS_ASYNC | MS_INVALIDATE | MS_SYNC))
- goto out;
- if (start & ~PAGE_MASK)
- goto out;
- if ((flags & MS_ASYNC) && (flags & MS_SYNC))
- goto out;
- error = -ENOMEM;
- len = (len + ~PAGE_MASK) & PAGE_MASK;
+ len = PAGE_ALIGN(len);
end = start + len;
if (end < start)
- goto out;
- error = 0;
+ return -ENOMEM;
if (end == start)
- goto out;
+ return 0;
+
/*
* If the interval [start,end) covers some unmapped address ranges,
* just ignore them, but return -ENOMEM at the end.
*/
down_read(>mmap_sem);
vma = find_vma(mm, start);
- for (;;) {
+ do {
struct file *file;
- /* Still start < end. */
- error = -ENOMEM;
- if (!vma)
- goto out_unlock;
- /* Here start < vma->vm_end. */
+ if (!vma) {
+ error = -ENOMEM;
+ break;
+ }
if (start < vma->vm_start) {
start = vma->vm_start;
- if (start >= end)
- goto out_unlock;
+ if (start >= end) {
+ error = -ENOMEM;
+ break;
+ }
unmapped_error = -ENOMEM;
}
- /* Here vma->vm_start <= start < vma->vm_end. */
- if ((flags & MS_INVALIDATE) &&
- (vma->vm_flags & VM_LOCKED)) {
+ if ((flags & MS_INVALIDATE) && (vma->vm_flags & VM_LOCKED)) {
error = -EBUSY;
- goto out_unlock;
+ break;
}
file = vma->vm_file;
- start = vma->vm_end;
- if ((flags & MS_SYNC) && file &&
- (vma->vm_flags & VM_SHARED)) {
+ if ((flags & MS_SYNC) && file && (vma->vm_flags & VM_SHARED)) {
get_file(file);
up_read(>mmap_sem);
error = do_fsync(file, 0);
fput(file);
- if (error || start >= end)
- goto out;
+ if (error)
+ return error;
down_read(>mmap_sem);
- vma = find_vma(mm, start);
- } else {
- if (start >= end) {
- error = 0;
- goto out_unlock;
- }
- vma = vma->vm_next;
}
- }
-out_unlock:
+
+ start = vma->vm_end;
+ vma = vma->vm_next;
+ } while (start < end);
up_read(>mmap_sem);
-out:
+
return error ? : unmapped_error;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: [PATCH] Fix private_list handling
On Thu, 10 Jan 2008 16:55:13 +0100 Jan Kara <[EMAIL PROTECTED]> wrote: > Hi, > > sorry for the previous empty email... > > Supriya noted in his testing that sometimes buffers removed by > __remove_assoc_queue() don't have b_assoc_mapping set (and thus IO error > won't be properly propagated). Actually, looking more into the code I found > there are some more races. The patch below should fix them. It survived > beating with LTP and fsstress on ext2 filesystem on my testing machine so > it should be reasonably bugfree... Andrew, would you put the patch into > -mm? Thanks. > > Honza > -- > Jan Kara <[EMAIL PROTECTED]> > SUSE Labs, CR > --- > > There are two possible races in handling of private_list in buffer cache. > 1) When fsync_buffers_list() processes a private_list, it clears > b_assoc_mapping and moves buffer to its private list. Now drop_buffers() > comes, > sees a buffer is on list so it calls __remove_assoc_queue() which complains > about b_assoc_mapping being cleared (as it cannot propagate possible IO > error). > This race has been actually observed in the wild. private_lock should prevent this race. Which call to drop_buffers() is the culprit? The first one in try_to_free_buffers(), I assume? The "can this still happen?" one? If so, it can happen. How? Perhaps this is a bug. > 2) When fsync_buffers_list() processes a private_list, > mark_buffer_dirty_inode() can be called on bh which is already on the private > list of fsync_buffers_list(). As buffer is on some list (note that the check > is > performed without private_lock), it is not readded to the mapping's > private_list and after fsync_buffers_list() finishes, we have a dirty buffer > which should be on private_list but it isn't. This race has not been reported, > probably because most (but not all) callers of mark_buffer_dirty_inode() hold > i_mutex and thus are serialized with fsync(). Maybe fsync_buffers_list should put the buffer back onto private_list if it got dirtied again. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH] per-task I/O throttling
Allow to limit the bandwidth of I/O-intensive processes, like backup
tools running in background, large files copy, checksums on huge files,
etc.
This kind of processes can noticeably impact the system responsiveness
for some time and playing with tasks' priority is not always an
acceptable solution.
This patch allows to specify a maximum I/O rate in sectors per second
for each single process via /proc//io_throttle (default is zero,
that specify no limit).
Signed-off-by: Andrea Righi <[EMAIL PROTECTED]>
---
diff -urpN linux-2.6.24-rc7/block/ll_rw_blk.c
linux-2.6.24-rc7-task-io-throttle/block/ll_rw_blk.c
--- linux-2.6.24-rc7/block/ll_rw_blk.c 2008-01-06 22:45:38.0 +0100
+++ linux-2.6.24-rc7-task-io-throttle/block/ll_rw_blk.c 2008-01-10
23:23:41.0 +0100
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
/*
* for max sense size
@@ -3184,6 +3185,41 @@ static inline int bio_check_eod(struct b
return 0;
}
+#ifdef CONFIG_TASK_IO_THROTTLE
+static inline void task_io_throttle(int nr_sectors)
+{
+ unsigned long delta;
+ long sleep;
+
+ if (!current->io_throttle) {
+ return;
+ }
+
+ if (!current->io_throttle_timestamp) {
+ current->io_throttle_timestamp = jiffies;
+ }
+ delta = jiffies_to_msecs((long)jiffies -
+ (long)(current->io_throttle_timestamp)) * 1000;
+
+ current->io_throttle_req += nr_sectors;
+
+ sleep = current->io_throttle_req -
+ current->io_throttle * max(delta, (unsigned long)1);
+ if (sleep > 0) {
+ schedule_timeout_uninterruptible(sleep);
+ }
+
+ if (delta) {
+ current->io_throttle_timestamp = jiffies;
+ current->io_throttle_req = 0;
+ }
+}
+#else
+static inline void task_io_throttle(int nr_sectors)
+{
+}
+#endif /* CONFIG_TASK_IO_THROTTLE */
+
/**
* generic_make_request: hand a buffer to its device driver for I/O
* @bio: The bio describing the location in memory and on the device.
@@ -3221,6 +3257,8 @@ static inline void __generic_make_reques
if (bio_check_eod(bio, nr_sectors))
goto end_io;
+ task_io_throttle(nr_sectors);
+
/*
* Resolve the mapping until finished. (drivers are
* still free to implement/resolve their own stacking
diff -urpN linux-2.6.24-rc7/fs/proc/base.c
linux-2.6.24-rc7-task-io-throttle/fs/proc/base.c
--- linux-2.6.24-rc7/fs/proc/base.c 2008-01-06 22:45:38.0 +0100
+++ linux-2.6.24-rc7-task-io-throttle/fs/proc/base.c2008-01-10
23:24:43.0 +0100
@@ -864,6 +864,56 @@ static const struct file_operations proc
.write = oom_adjust_write,
};
+#ifdef CONFIG_TASK_IO_THROTTLE
+static ssize_t io_throttle_read(struct file *file, char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ struct task_struct *task = get_proc_task(file->f_path.dentry->d_inode);
+ char buffer[PROC_NUMBUF];
+ size_t len;
+ unsigned long io_throttle;
+
+ if (!task)
+ return -ESRCH;
+ io_throttle = task->io_throttle;
+ put_task_struct(task);
+
+ len = snprintf(buffer, sizeof(buffer), "%lu\n", io_throttle);
+
+ return simple_read_from_buffer(buf, count, ppos, buffer, len);
+}
+
+static ssize_t io_throttle_write(struct file *file, const char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ struct task_struct *task;
+ char buffer[PROC_NUMBUF], *end;
+ unsigned long io_throttle;
+
+ memset(buffer, 0, sizeof(buffer));
+ if (count > sizeof(buffer) - 1)
+ count = sizeof(buffer) - 1;
+ if (copy_from_user(buffer, buf, count))
+ return -EFAULT;
+ io_throttle = simple_strtoul(buffer, , 0);
+ if (*end == '\n')
+ end++;
+ task = get_proc_task(file->f_path.dentry->d_inode);
+ if (!task)
+ return -ESRCH;
+ task->io_throttle = io_throttle;
+ put_task_struct(task);
+ if (end - buffer == 0)
+ return -EIO;
+ return end - buffer;
+}
+
+static const struct file_operations proc_io_throttle_operations = {
+ .read = io_throttle_read,
+ .write = io_throttle_write,
+};
+#endif /* CONFIG_TASK_IO_THROTTLE */
+
#ifdef CONFIG_MMU
static ssize_t clear_refs_write(struct file *file, const char __user *buf,
size_t count, loff_t *ppos)
@@ -2250,6 +2300,9 @@ static const struct pid_entry tgid_base_
#ifdef CONFIG_TASK_IO_ACCOUNTING
INF("io", S_IRUGO, pid_io_accounting),
#endif
+#ifdef CONFIG_TASK_IO_THROTTLE
+ REG("io_throttle",S_IRUGO|S_IWUSR, io_throttle),
+#endif
};
static int proc_tgid_base_readdir(struct file * filp,
diff -urpN linux-2.6.24-rc7/include/linux/sched.h
linux-2.6.24-rc7-task-io-throttle/include/linux/sched.h
---
Re: soft lockup - CPU#1 stuck for 15s! [swapper:0]
On Jan 9, 2008 6:56 AM, Thomas Gleixner <[EMAIL PROTECTED]> wrote: > Can you apply the patch below + the debug patch which prints the timer > stats on softlockup and provide the output of this. Applied to today's git and running for 21 hours - no recurrence yet even with 1.2 wakeups per second. I will re-open this thread if it bites again. Thanks Parag -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 01/22 -v2] Add basic support for gcc profiler instrumentation
Steven Rostedt wrote:
> Index: linux-compile-i386.git/Makefile
> ===
> --- linux-compile-i386.git.orig/Makefile 2008-01-09 14:09:36.0
> -0500
> +++ linux-compile-i386.git/Makefile 2008-01-09 14:10:07.0 -0500
> @@ -509,6 +509,10 @@ endif
>
> include $(srctree)/arch/$(SRCARCH)/Makefile
>
> +# MCOUNT expects frame pointer
This comment looks stray.
> +ifdef CONFIG_MCOUNT
> +KBUILD_CFLAGS+= -pg
> +endif
> ifdef CONFIG_FRAME_POINTER
> KBUILD_CFLAGS+= -fno-omit-frame-pointer -fno-optimize-sibling-calls
> else
> Index: linux-compile-i386.git/arch/x86/Kconfig
> ===
> --- linux-compile-i386.git.orig/arch/x86/Kconfig 2008-01-09
> 14:09:36.0 -0500
> +++ linux-compile-i386.git/arch/x86/Kconfig 2008-01-09 14:10:07.0
> -0500
> @@ -28,6 +28,10 @@ config GENERIC_CMOS_UPDATE
> bool
> default y
>
> +config ARCH_HAS_MCOUNT
> + bool
> + default y
> +
> config CLOCKSOURCE_WATCHDOG
> bool
> default y
> Index: linux-compile-i386.git/arch/x86/kernel/Makefile_32
> ===
> --- linux-compile-i386.git.orig/arch/x86/kernel/Makefile_32 2008-01-09
> 14:09:36.0 -0500
> +++ linux-compile-i386.git/arch/x86/kernel/Makefile_322008-01-09
> 14:10:07.0 -0500
> @@ -23,6 +23,7 @@ obj-$(CONFIG_APM) += apm_32.o
> obj-$(CONFIG_X86_SMP)+= smp_32.o smpboot_32.o tsc_sync.o
> obj-$(CONFIG_SMP)+= smpcommon_32.o
> obj-$(CONFIG_X86_TRAMPOLINE) += trampoline_32.o
> +obj-$(CONFIG_MCOUNT) += mcount-wrapper.o
So far the code organization is different for 32 and 64 bit. I would
suggest to either
o move both trampolines into entry_*.S or
o put them in something like mcount-wrapper_32/64.S.
> obj-$(CONFIG_X86_MPPARSE)+= mpparse_32.o
> obj-$(CONFIG_X86_LOCAL_APIC) += apic_32.o nmi_32.o
> obj-$(CONFIG_X86_IO_APIC)+= io_apic_32.o
> Index: linux-compile-i386.git/arch/x86/kernel/mcount-wrapper.S
> ===
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ linux-compile-i386.git/arch/x86/kernel/mcount-wrapper.S 2008-01-09
> 14:10:07.0 -0500
> @@ -0,0 +1,25 @@
> +/*
> + * linux/arch/x86/mcount-wrapper.S
> + *
> + * Copyright (C) 2004 Ingo Molnar
> + */
> +
> +.globl mcount
> +mcount:
> + cmpl $0, mcount_enabled
> + jz out
> +
> + push %ebp
> + mov %esp, %ebp
What is the benefit of having a call frame in this trampoline? We used
to carry this in the i386 mcount tracer for Adeos/I-pipe too (it was
derived from the -rt code), but I just successfully tested a removal
patch. Also glibc [1] doesn't include it.
> + pushl %eax
> + pushl %ecx
> + pushl %edx
> +
> + call __mcount
I think this indirection should be avoided, just like the 64-bit version
and glibc do.
> +
> + popl %edx
> + popl %ecx
> + popl %eax
> + popl %ebp
> +out:
> + ret
...
> Index: linux-compile-i386.git/lib/tracing/mcount.c
> ===
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ linux-compile-i386.git/lib/tracing/mcount.c 2008-01-09
> 14:10:07.0 -0500
> @@ -0,0 +1,77 @@
> +/*
> + * Infrastructure for profiling code inserted by 'gcc -pg'.
> + *
> + * Copyright (C) 2007 Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
> + *
> + * Converted to be more generic:
> + * Copyright (C) 2007-2008 Steven Rostedt <[EMAIL PROTECTED]>
> + *
> + * From code in the latency_tracer, that is:
> + *
> + * Copyright (C) 2004-2006 Ingo Molnar
> + * Copyright (C) 2004 William Lee Irwin III
> + */
> +
> +#include
> +#include
> +
> +/*
> + * Since we have nothing protecting between the test of
> + * mcount_trace_function and the call to it, we can't
> + * set it to NULL without risking a race that will have
> + * the kernel call the NULL pointer. Instead, we just
> + * set the function pointer to a dummy function.
> + */
> +notrace void dummy_mcount_tracer(unsigned long ip,
> + unsigned long parent_ip)
> +{
> + /* do nothing */
> +}
> +
> +mcount_func_t mcount_trace_function __read_mostly = dummy_mcount_tracer;
> +int mcount_enabled __read_mostly;
> +
> +/** __mcount - hook for profiling
> + *
> + * This routine is called from the arch specific mcount routine, that in
> turn is
> + * called from code inserted by gcc -pg.
> + */
> +notrace void __mcount(void)
> +{
> + mcount_trace_function(CALLER_ADDR1, CALLER_ADDR2);
> +}
mcount_trace_function should always be called from the assembly
trampoline, IMO.
> +EXPORT_SYMBOL_GPL(mcount);
> +/*
> + * The above EXPORT_SYMBOL is for the gcc call of mcount and not the
> + * function __mcount that it is underneath. I put the export there
> + *
Re: [x86] list of style offenders
On Fri, 2008-01-11 at 00:40 +0100, Paolo Ciarrocchi wrote: > On Jan 11, 2008 12:08 AM, Daniel Walker <[EMAIL PROTECTED]> wrote: > > > The git logs also show that arch/x86/math-emu/fpu_trig.c hasn't been > > modified since it was pull in on Oct. 11 .. > > Daniel, > are we looking at the same tree? > fpu_trig.c has been modified (and cleaned up) by Ingo 35 hours ago: > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=history;f=arch/x86/math-emu/fpu_trig.c;h=ecd06680581c51cbb7631cd0240708e92d9ef919;hb=mm Here's another set of, which shows significant improvement over the last one.. ./arch/x86/kernel/cpu/centaur.c total: 152 errors, 11 warnings, 471 lines checked ./arch/x86/crypto/aes_32.c total: 113 errors, 0 warnings, 515 lines checked ./arch/x86/kernel/traps_64.c total: 103 errors, 24 warnings, 1211 lines checked ./arch/x86/kernel/io_apic_32.c total: 97 errors, 69 warnings, 2889 lines checked ./arch/x86/kernel/traps_32.c total: 86 errors, 21 warnings, 1200 lines checked ./arch/x86/oprofile/op_model_p4.c total: 86 errors, 10 warnings, 722 lines checked ./arch/x86/kernel/process_64.c total: 70 errors, 19 warnings, 902 lines checked ./arch/x86/kernel/mpparse_32.c total: 69 errors, 36 warnings, 1137 lines checked ./arch/x86/kernel/mpparse_64.c total: 69 errors, 27 warnings, 865 lines checked ./arch/x86/lib/mmx_32.c total: 68 errors, 3 warnings, 403 lines checked ./arch/x86/mm/init_64.c total: 67 errors, 18 warnings, 763 lines checked ./arch/x86/kernel/vm86_32.c total: 64 errors, 16 warnings, 840 lines checked ./arch/x86/lib/usercopy_32.c total: 63 errors, 2 warnings, 882 lines checked ./arch/x86/pci/irq.c total: 61 errors, 83 warnings, 1224 lines checked ./arch/x86/boot/compressed/misc_32.c total: 61 errors, 8 warnings, 383 lines checked ./arch/x86/boot/compressed/misc_64.c total: 60 errors, 8 warnings, 378 lines checked ./arch/x86/kernel/cpu/common.c total: 57 errors, 15 warnings, 729 lines checked ./arch/x86/kernel/signal_64.c total: 55 errors, 14 warnings, 489 lines checked ./arch/x86/kernel/cpu/mtrr/main.c total: 53 errors, 23 warnings, 762 lines checked ./arch/x86/lib/csum-wrappers_64.c total: 51 errors, 6 warnings, 135 lines checked ./arch/x86/kernel/io_apic_64.c total: 49 errors, 50 warnings, 2384 lines checked ./arch/x86/kernel/cpu/cyrix.c total: 49 errors, 11 warnings, 461 lines checked ./arch/x86/mach-voyager/voyager_cat.c total: 46 errors, 49 warnings, 1199 lines checked ./arch/x86/lib/string_32.c total: 45 errors, 0 warnings, 237 lines checked ./arch/x86/kernel/setup64.c total: 43 errors, 16 warnings, 300 lines checked ./arch/x86/kernel/cpu/amd.c total: 42 errors, 26 warnings, 350 lines checked ./arch/x86/kernel/mca_32.c total: 42 errors, 3 warnings, 469 lines checked ./arch/x86/kernel/i8259_64.c total: 38 errors, 2 warnings, 510 lines checked ./arch/x86/kernel/cpu/intel.c total: 37 errors, 16 warnings, 368 lines checked ./arch/x86/kernel/cpu/intel_cacheinfo.c total: 36 errors, 49 warnings, 832 lines checked ./arch/x86/oprofile/op_model_ppro.c total: 34 errors, 3 warnings, 192 lines checked ./arch/x86/oprofile/op_model_athlon.c total: 33 errors, 4 warnings, 190 lines checked ./arch/x86/kernel/cpu/mcheck/mce_64.c total: 32 errors, 3 warnings, 899 lines checked ./arch/x86/boot/cpucheck.c total: 30 errors, 0 warnings, 262 lines checked ./arch/x86/kernel/smpboot_32.c total: 29 errors, 46 warnings, 1338 lines checked ./arch/x86/boot/compressed/relocs.c total: 28 errors, 48 warnings, 626 lines checked ./arch/x86/kernel/cpu/cpufreq/longhaul.h total: 28 errors, 0 warnings, 353 lines checked ./arch/x86/kernel/vmi_32.c total: 27 errors, 30 warnings, 1014 lines checked ./arch/x86/kernel/signal_32.c total: 27 errors, 10 warnings, 669 lines checked ./arch/x86/math-emu/errors.c total: 26 errors, 36 warnings, 689 lines checked ./arch/x86/math-emu/fpu_emu.h total: 25 errors, 3 warnings, 217 lines checked ./arch/x86/kernel/e820_32.c total: 24 errors, 34 warnings, 751 lines checked ./arch/x86/kernel/smpboot_64.c total: 24 errors, 30 warnings, 1119 lines checked ./arch/x86/kernel/cpu/cpufreq/powernow-k7.c total: 23 errors, 88 warnings, 701 lines checked ./arch/x86/kernel/cpu/cpufreq/speedstep-centrino.c total: 23 errors, 20 warnings, 633 lines checked
Re: LRW/XTS + Via Padlock Bug in 2.6.24-rc7?
On Fri, Jan 11, 2008 at 12:21:50AM +0100, Torben Viets wrote:
>
> Why I can't see both in /proc/crypto and of course not use in int
> cryptsetup, till I make a /etc/init.d/udev restart ist ths a kernel bug,
> or a ubuntu bug?
The algorithm xts(aes) is an instantiation of the xts template. As such
you won't see it until someone tries to use it or you instantiate it
explicitly (which isn't possible yet :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: hwclock failure in x86.git
H. Peter Anvin wrote: > Kevin Winchester wrote: >> My first time building and booting the mm branch of x86.git was pretty >> successful. The only error I noticed was the following in my dmesg: >> >> hwclock[622] general protection ip:804b226 sp:bff43e30 error:0 >> >> I'm not sure exactly how to debug this. I could bisect, but there seems >> to be some useful debug information in there, so there might be >> something better to try first. >> > > That's a userspace IP; it implies the userspace hwclock binary did > something bad, or the kernel didn't permit it to do something it should > have. The best thing to do would probably to strace hwclock and see > what it did when it died. > Unfortunately, but the time I can get a chance to run hwclock, the problem seems to have fixed itself. I tried booting into single user mode, but `/etc/init.d/hwclock.sh restart` succeeds once I have my prompt. A few other facts: - This is an Athlon64 box running X83_32 - I use hpet=force for the Via chipset - A little more of the demsg is: [ 17.511262] rtc_cmos 00:05: setting system clock to 2008-01-10 23:44:16 UTC (128656) [ 17.545948] EXT3-fs: mounted filesystem with ordered data mode. [ 17.545986] VFS: Mounted root (ext3 filesystem) readonly. [ 17.546142] Freeing unused kernel memory: 144k freed [ 17.546260] kjournald starting. Commit interval 5 seconds [ 21.861249] hwclock[622] general protection ip:804b226 sp:bfd98480 error:0 [ 22.416442] Velocity is AUTO mode [ 23.093416] Adding 1502036k swap on /dev/sda5. Priority:-1 extents:1 across:1502036k [ 23.416756] EXT3 FS on sda1, internal journal [ 24.009669] kjournald starting. Commit interval 5 seconds [ 24.009889] EXT3 FS on sda6, internal journal [ 24.009899] EXT3-fs: mounted filesystem with ordered data mode. [ 24.053164] eth0: Link auto-negotiation speed 100M bps full duplex [ 28.733360] agpgart: Found an AGP 3.0 compliant device at :00:00.0. [ 28.733872] agpgart: Putting AGP V3 device at :00:00.0 into 8x mode [ 28.734354] agpgart: Putting AGP V3 device at :01:00.0 into 8x mode [ 29.089412] [drm] Setting GART location based on new memory map [ 29.089842] [drm] Loading R200 Microcode [ 29.090172] [drm] writeback test succeeded in 1 usecs [ 143.076821] Marking TSC unstable due to: cpufreq changes. [ 143.084910] Time: hpet clocksource has been installed. [ 143.670905] Clocksource tsc unstable (delta = -231086796 ns) So the TSC is being marked unstable because of cpufreq changes. I have no idea when it comes to TSCs and HPETs and how the RTC works (other than what the abbreviations stand for), so this all may be meaningless. I'll try disabling cpufreq to see if that has an effect. -- Kevin Winchester -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [x86] list of style offenders
On Fri, 2008-01-11 at 00:40 +0100, Paolo Ciarrocchi wrote: > On Jan 11, 2008 12:08 AM, Daniel Walker <[EMAIL PROTECTED]> wrote: > > > The git logs also show that arch/x86/math-emu/fpu_trig.c hasn't been > > modified since it was pull in on Oct. 11 .. > > Daniel, > are we looking at the same tree? > fpu_trig.c has been modified (and cleaned up) by Ingo 35 hours ago: > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=history;f=arch/x86/math-emu/fpu_trig.c;h=ecd06680581c51cbb7631cd0240708e92d9ef919;hb=mm Not it's appears we aren't .. The tree I was using was a straight pull of the repository above .. I guess there's a separate repository, and branch for x86 .. 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: Is it possible to change IRQ for certain device?
On Thursday 10 January 2008 09:01, linux-os (Dick Johnson) wrote: > > On Thu, 10 Jan 2008, Jan Marek wrote: > > > Hello lkml, > > > > I have problem with my computer: I have motherboard with AMD690G chipset > > and nVidia VGA card. But I cannot set BIOS, to assign for VGA unique > > IRQ. VGA card is sharing IRQ with two ohci_hcd (USB 1.1 controllers). > > But when I want use for X proprietary nvidia driver, X didn't work with > > this errors: > > > > In dmesg: > > > > NVRM: RmInitAdapter failed! (0x23:0x:678) > > NVRM: rm_init_adapter(0) failed > > > > and in /var/log/Xorg.0.log: > > > > (II) Setting vga for screen 0. > > (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32 > > (==) NVIDIA(0): RGB weight 888 > > (==) NVIDIA(0): Default visual is TrueColor > > (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0) > > (**) NVIDIA(0): Enabling RENDER acceleration > > (II) NVIDIA(0): Support for GLX with the Damage and Composite X > > extensions is > > (II) NVIDIA(0): enabled. > > (EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device > > PCI:1:0:0. > > (EE) NVIDIA(0): Please see the COMMON PROBLEMS section in the > > README for > > (EE) NVIDIA(0): additional information. > > (EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device! > > (EE) NVIDIA(0): *** Aborting *** > > (II) UnloadModule: "nvidia" > > (II) UnloadModule: "fb" > > (EE) Screen(s) found, but none have a usable configuration. > > > > Fatal server error: > > no screens found > > > > I've found in README for NVIDIA, that VGA has to have unique IRQ. I've > > tried to set INTERRUPT_LINE and INTERRUPT_PIN with setpci tool, set > > pci=routeirq, pci=noacpi as the kernel boot parameters, but IRQ > > is still the same. > > > > Is there a way to change IRQ for VGA (or for ohci_hcd instead of VGA) > > directly in Linux? > > > > Thanks a lot. > > > > Sincerely > > Jan Marek > > The interrupt lines are set by the traces on the PC board and > the contents of various "glue" chips and FPGAs. Many lap-tops, > for instance, only have one IRQ serving any PCI devices. If > your screen card can't share the only IRQ you have, it is > broken. Contact the vendor of both your motherboard (they > may have a BIOS upgrade) and the screen card (they may > have a fix). What Dick writes is true. If you can move devices between slots, you can often get onto a different physical interrupt wire. However, if your system has an IOAPIC but you're not using IOAPIC mode, often that programs the "glue" above so spread interrutps out. See if your BIOS setup has any IRQ options, and see if your kernel has the IOAPIC enabled. dmesg would tell. cheers, -Len -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [x86] list of style offenders
On Jan 11, 2008 12:08 AM, Daniel Walker <[EMAIL PROTECTED]> wrote: > The git logs also show that arch/x86/math-emu/fpu_trig.c hasn't been > modified since it was pull in on Oct. 11 .. Daniel, are we looking at the same tree? fpu_trig.c has been modified (and cleaned up) by Ingo 35 hours ago: http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=history;f=arch/x86/math-emu/fpu_trig.c;h=ecd06680581c51cbb7631cd0240708e92d9ef919;hb=mm Ciao, -- Paolo http://paolo.ciarrocchi.googlepages.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
