Oops on 2.6.24.2 "rmmod fan" && "rmmod 8250_pnp"
114.924779] [] inode_has_perm+0x6b/0x7a Feb 14 18:53:01 nike kernel: [ 1114.925034] [] check_bytes_and_report+0x38/0xcb Feb 14 18:53:01 nike kernel: [ 1114.925288] [] file_has_perm+0xa7/0xb6 Feb 14 18:53:01 nike kernel: [ 1114.925543] [] do_ioctl+0x5e/0x77 Feb 14 18:53:01 nike kernel: [ 1114.931362] [] vfs_ioctl+0x251/0x26e Feb 14 18:53:01 nike kernel: [ 1114.931616] [] sys_ioctl+0x57/0x7b Feb 14 18:53:01 nike kernel: [ 1114.931869] [] tracesys+0xdc/0xe1 Feb 14 18:53:01 nike kernel: [ 1114.932123] Feb 14 18:53:01 nike kernel: [ 1114.932368] Feb 14 18:53:01 nike kernel: [ 1114.932369] Code: 8b 42 10 2b 42 14 c9 25 ff 0f 00 00 c3 48 8b 87 b0 00 00 00 Feb 14 18:53:01 nike kernel: [ 1114.934036] RSP Feb 14 18:53:01 nike kernel: [ 1114.934554] ---[ end trace d01c9c9b8dd780f4 ]--- Agetty is spawned via: S0:2345:respawn:/sbin/agetty -h -L ttyS0 115200 vt100 This kernel is 2.6.24.2 from kernel.org and configured only with "make allmodconfig". Colin. -- "Developers are like artists; they produce their best work if they have the freedom to do so" - Werner Vogels, CTO Amazon.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/
newbie, 2.4.0-test11-pre4 no compile when CONFIG_AGP=y
I'll preface this saying I'm a kernel compile newbie and I could be making the most basic of mistakes. My problem is that I have an Asus CUSL2 board and am attempting to use the Intel i815-based on-board video. I'm on Redhat 7.0, which works great with the stock 2.2.16-22 kernel. I am able to compile and boot a 2.4.0-test10 kernel for text only. The problem is that to use the on-board video of the i810/i815 board, you have to have agpgart -- but when I try to turn CONFIG_AGP=y in the .config the 2.4.0-test11-pre4 compile fails on agpsupport.c:35 I've found many references to similar problems in prior test builds, but I thought this was already patched? There linux-kernel mailing list archives had a lengthy discussion about other .config setting dependencies, but I couldn't find the "final word" on this issue. I have documented the EXACT procedure I use to build my kernel. For every attempt, I start with a DELETED /usr/src/linux/ tree and all fresh files from the downloaded tarball. My steps are documented at: http://www.roundsparrow.com/Linux/240oni815/ Any help appreciated. Feel free to keep replies off the main list, as this may be a training issue more than a kernel one :) Thanks. Stephen Gutknecht Renton, Washington mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Given an image, how can show its config?
Dear all, I would like to upgrade my kernel which is bundled with Red Hat. However, I don't want to lose modules/functions it has complied. How can I do it? Is there any command to check the current config and how can I check the modules it has as well? Many thanks!!! Best regards, Boris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
about linux-2.4.0-test13pre3
Hi, Where can I get the linux-2.4.0-test13pre3 -- Best regards, linux-kernel mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
build error
[please CC: me, my subscribe mail was greylisted] Morning! My make run for 2.6.23-rc9 ends like this: GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 kernel/built-in.o: In function `getnstimeofday': (.text+0x1e141): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1e263): undefined reference to `__udivdi3' kernel/built-in.o: In function `timekeeping_resume': timekeeping.c:(.text+0x1e427): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x1e829): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x1ec4c): undefined reference to `__udivdi3' make: *** [.tmp_vmlinux1] Error 1 .config attached. I have already read the diff from -rc8 and found nothing that helped me. Any ideas? Further questions? Wilfried # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc9 # Tue Oct 2 19:34:58 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_BLOCK=y CONFIG_LBD=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_LSF=y # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set CONFIG_MPENTIUMM=y # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_PREEMPT_NONE is not set #
[patch 02/19] free swap space on swap-in/activation
+ lts' convert anon_vma list lock to reader/write lock patch
+ Nick Piggin's move and rework isolate_lru_page() patch
Free swap cache entries when swapping in pages if vm_swap_full()
[swap space > 1/2 used?]. Uses new pagevec to reduce pressure
on locks.
Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>
Signed-off-by: Lee Schermerhorn <[EMAIL PROTECTED]>
Index: linux-2.6.24-rc6-mm1/mm/vmscan.c
===
--- linux-2.6.24-rc6-mm1.orig/mm/vmscan.c 2008-01-02 12:37:14.0
-0500
+++ linux-2.6.24-rc6-mm1/mm/vmscan.c2008-01-02 12:37:18.0 -0500
@@ -632,6 +632,9 @@ free_it:
continue;
activate_locked:
+ /* Not a candidate for swapping, so reclaim swap space. */
+ if (PageSwapCache(page) && vm_swap_full())
+ remove_exclusive_swap_page(page);
SetPageActive(page);
pgactivate++;
keep_locked:
@@ -1214,6 +1217,8 @@ static void shrink_active_list(unsigned
__mod_zone_page_state(zone, NR_ACTIVE, pgmoved);
pgmoved = 0;
spin_unlock_irq(&zone->lru_lock);
+ if (vm_swap_full())
+ pagevec_swap_free(&pvec);
__pagevec_release(&pvec);
spin_lock_irq(&zone->lru_lock);
}
@@ -1223,6 +1228,8 @@ static void shrink_active_list(unsigned
__count_zone_vm_events(PGREFILL, zone, pgscanned);
__count_vm_events(PGDEACTIVATE, pgdeactivate);
spin_unlock_irq(&zone->lru_lock);
+ if (vm_swap_full())
+ pagevec_swap_free(&pvec);
pagevec_release(&pvec);
}
Index: linux-2.6.24-rc6-mm1/mm/swap.c
===
--- linux-2.6.24-rc6-mm1.orig/mm/swap.c 2008-01-02 12:37:12.0 -0500
+++ linux-2.6.24-rc6-mm1/mm/swap.c 2008-01-02 12:37:18.0 -0500
@@ -465,6 +465,24 @@ void pagevec_strip(struct pagevec *pvec)
}
}
+/*
+ * Try to free swap space from the pages in a pagevec
+ */
+void pagevec_swap_free(struct pagevec *pvec)
+{
+ int i;
+
+ for (i = 0; i < pagevec_count(pvec); i++) {
+ struct page *page = pvec->pages[i];
+
+ if (PageSwapCache(page) && !TestSetPageLocked(page)) {
+ if (PageSwapCache(page))
+ remove_exclusive_swap_page(page);
+ unlock_page(page);
+ }
+ }
+}
+
/**
* pagevec_lookup - gang pagecache lookup
* @pvec: Where the resulting pages are placed
Index: linux-2.6.24-rc6-mm1/include/linux/pagevec.h
===
--- linux-2.6.24-rc6-mm1.orig/include/linux/pagevec.h 2008-01-02
12:37:12.0 -0500
+++ linux-2.6.24-rc6-mm1/include/linux/pagevec.h2008-01-02
12:37:18.0 -0500
@@ -26,6 +26,7 @@ void __pagevec_free(struct pagevec *pvec
void __pagevec_lru_add(struct pagevec *pvec);
void __pagevec_lru_add_active(struct pagevec *pvec);
void pagevec_strip(struct pagevec *pvec);
+void pagevec_swap_free(struct pagevec *pvec);
unsigned pagevec_lookup(struct pagevec *pvec, struct address_space *mapping,
pgoff_t start, unsigned nr_pages);
unsigned pagevec_lookup_tag(struct pagevec *pvec,
--
All Rights Reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 01/19] move isolate_lru_page() to vmscan.c
duplicate refcount from
+* isolate_lru_page() or drop the page ref if it was
+* not isolated.
+*/
+ put_page(page);
+ } else
+ list_add_tail(&page->lru, &pagelist);
set_status:
pp->status = err;
}
Index: linux-2.6.24-rc6-mm1/mm/vmscan.c
===
--- linux-2.6.24-rc6-mm1.orig/mm/vmscan.c 2008-01-02 12:37:12.0
-0500
+++ linux-2.6.24-rc6-mm1/mm/vmscan.c2008-01-02 12:37:14.0 -0500
@@ -829,6 +829,47 @@ static unsigned long clear_active_flags(
return nr_active;
}
+/**
+ * isolate_lru_page(@page)
+ *
+ * Isolate one @page from the LRU lists. Must be called with an elevated
+ * refcount on the page, which is a fundamentnal difference from
+ * isolate_lru_pages (which is called without a stable reference).
+ *
+ * The returned page will have PageLru() cleared, and PageActive set,
+ * if it was found on the active list. This flag generally will need to be
+ * cleared by the caller before letting the page go.
+ *
+ * The vmstat page counts corresponding to the list on which the page was
+ * found will be decremented.
+ *
+ * lru_lock must not be held, interrupts must be enabled.
+ *
+ * Returns:
+ * -EBUSY: page not on LRU list
+ * 0: page removed from LRU list.
+ */
+int isolate_lru_page(struct page *page)
+{
+ int ret = -EBUSY;
+
+ if (PageLRU(page)) {
+ struct zone *zone = page_zone(page);
+
+ spin_lock_irq(&zone->lru_lock);
+ if (PageLRU(page) && get_page_unless_zero(page)) {
+ ret = 0;
+ ClearPageLRU(page);
+ if (PageActive(page))
+ del_page_from_active_list(zone, page);
+ else
+ del_page_from_inactive_list(zone, page);
+ }
+ spin_unlock_irq(&zone->lru_lock);
+ }
+ return ret;
+}
+
/*
* shrink_inactive_list() is a helper for shrink_zone(). It returns the number
* of reclaimed pages
Index: linux-2.6.24-rc6-mm1/mm/mempolicy.c
===
--- linux-2.6.24-rc6-mm1.orig/mm/mempolicy.c2008-01-02 12:37:12.0
-0500
+++ linux-2.6.24-rc6-mm1/mm/mempolicy.c 2008-01-02 12:37:14.0 -0500
@@ -93,6 +93,8 @@
#include
#include
+#include "internal.h"
+
/* Internal flags */
#define MPOL_MF_DISCONTIG_OK (MPOL_MF_INTERNAL << 0) /* Skip checks for
continuous vmas */
#define MPOL_MF_INVERT (MPOL_MF_INTERNAL << 1) /* Invert check for
nodemask */
@@ -603,8 +605,12 @@ static void migrate_page_add(struct page
/*
* Avoid migrating a page that is shared with others.
*/
- if ((flags & MPOL_MF_MOVE_ALL) || page_mapcount(page) == 1)
- isolate_lru_page(page, pagelist);
+ if ((flags & MPOL_MF_MOVE_ALL) || page_mapcount(page) == 1) {
+ if (!isolate_lru_page(page)) {
+ get_page(page);
+ list_add_tail(&page->lru, pagelist);
+ }
+ }
}
static struct page *new_node_page(struct page *page, unsigned long node, int
**x)
--
All Rights Reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 03/19] define page_file_cache() function
@ -2284,6 +2286,7 @@ static int __do_fault(struct mm_struct *
set_pte_at(mm, address, page_table, entry);
if (anon) {
inc_mm_counter(mm, anon_rss);
+ SetPageSwapBacked(page);
lru_cache_add_active(page);
page_add_new_anon_rmap(page, vma, address);
} else {
Index: linux-2.6.24-rc6-mm1/mm/swap_state.c
===
--- linux-2.6.24-rc6-mm1.orig/mm/swap_state.c 2008-01-02 12:37:11.0
-0500
+++ linux-2.6.24-rc6-mm1/mm/swap_state.c2008-01-02 12:37:22.0
-0500
@@ -82,6 +82,7 @@ int add_to_swap_cache(struct page *page,
if (!error) {
page_cache_get(page);
SetPageSwapCache(page);
+ SetPageSwapBacked(page);
set_page_private(page, entry.val);
total_swapcache_pages++;
__inc_zone_page_state(page, NR_FILE_PAGES);
Index: linux-2.6.24-rc6-mm1/mm/migrate.c
===
--- linux-2.6.24-rc6-mm1.orig/mm/migrate.c 2008-01-02 12:37:14.0
-0500
+++ linux-2.6.24-rc6-mm1/mm/migrate.c 2008-01-02 12:37:22.0 -0500
@@ -546,6 +546,8 @@ static int move_to_new_page(struct page
/* Prepare mapping for the new page.*/
newpage->index = page->index;
newpage->mapping = page->mapping;
+ if (PageSwapBacked(page))
+ SetPageSwapBacked(newpage);
mapping = page_mapping(page);
if (!mapping)
Index: linux-2.6.24-rc6-mm1/mm/page_alloc.c
===
--- linux-2.6.24-rc6-mm1.orig/mm/page_alloc.c 2008-01-02 12:37:11.0
-0500
+++ linux-2.6.24-rc6-mm1/mm/page_alloc.c2008-01-02 12:37:22.0
-0500
@@ -253,6 +253,7 @@ static void bad_page(struct page *page)
1 << PG_slab|
1 << PG_swapcache |
1 << PG_writeback |
+ 1 << PG_swapbacked |
1 << PG_buddy );
set_page_count(page, 0);
reset_page_mapcount(page);
@@ -485,6 +486,8 @@ static inline int free_pages_check(struc
bad_page(page);
if (PageDirty(page))
__ClearPageDirty(page);
+ if (PageSwapBacked(page))
+ __ClearPageSwapBacked(page);
/*
* For now, we report if PG_reserved was found set, but do not
* clear it, and do not free the page. But we shall soon need
@@ -631,6 +634,7 @@ static int prep_new_page(struct page *pa
1 << PG_swapcache |
1 << PG_writeback |
1 << PG_reserved |
+ 1 << PG_swapbacked |
1 << PG_buddy
bad_page(page);
--
All Rights Reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 04/19] debugging checks for page_file_cache()
Debug whether we end up classifying the wrong pages as
filesystem backed. This has not triggered in stress
tests on my system, but who knows...
DEBUGGING ONLY: NOT FOR UPSTREAM MERGE
Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>
Index: linux-2.6.24-rc6-mm1/include/linux/mm_inline.h
===
--- linux-2.6.24-rc6-mm1.orig/include/linux/mm_inline.h 2008-01-02
12:37:22.0 -0500
+++ linux-2.6.24-rc6-mm1/include/linux/mm_inline.h 2008-01-02
12:37:27.0 -0500
@@ -1,6 +1,8 @@
#ifndef LINUX_MM_INLINE_H
#define LINUX_MM_INLINE_H
+#include /* for struct address_space */
+
/**
* page_file_cache(@page)
* Returns !0 if @page is page cache page backed by a regular filesystem,
@@ -10,11 +12,19 @@
* needs to survive until the page is last deleted from the LRU, which
* could be as far down as __page_cache_release.
*/
+extern const struct address_space_operations shmem_aops;
static inline int page_file_cache(struct page *page)
{
+ struct address_space * mapping = page_mapping(page);
+
if (PageSwapBacked(page))
return 0;
+ /* These pages should all be marked PG_swapbacked */
+ WARN_ON(PageAnon(page));
+ WARN_ON(PageSwapCache(page));
+ WARN_ON(mapping && mapping->a_ops && mapping->a_ops == &shmem_aops);
+
/* The page is page cache backed by a normal filesystem. */
return 2;
}
Index: linux-2.6.24-rc6-mm1/mm/shmem.c
===
--- linux-2.6.24-rc6-mm1.orig/mm/shmem.c2008-01-02 12:37:22.0
-0500
+++ linux-2.6.24-rc6-mm1/mm/shmem.c 2008-01-02 12:37:27.0 -0500
@@ -179,7 +179,7 @@ static inline void shmem_unacct_blocks(u
}
static const struct super_operations shmem_ops;
-static const struct address_space_operations shmem_aops;
+const struct address_space_operations shmem_aops;
static const struct file_operations shmem_file_operations;
static const struct inode_operations shmem_inode_operations;
static const struct inode_operations shmem_dir_inode_operations;
@@ -2344,7 +2344,7 @@ static void destroy_inodecache(void)
kmem_cache_destroy(shmem_inode_cachep);
}
-static const struct address_space_operations shmem_aops = {
+const struct address_space_operations shmem_aops = {
.writepage = shmem_writepage,
.set_page_dirty = __set_page_dirty_no_writeback,
#ifdef CONFIG_TMPFS
--
All Rights Reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 05/19] Use an indexed array for LRU variables
claim_active(sc->mem_cgroup,
zone, priority);
- nr_inactive = mem_cgroup_calc_reclaim_inactive(sc->mem_cgroup,
+ nr[LRU_INACTIVE] =
mem_cgroup_calc_reclaim_inactive(sc->mem_cgroup,
zone, priority);
}
-
- while (nr_active || nr_inactive) {
- if (nr_active) {
- nr_to_scan = min(nr_active,
+ while (nr[LRU_ACTIVE] || nr[LRU_INACTIVE]) {
+ for_each_lru(l) {
+ if (nr[l]) {
+ nr_to_scan = min(nr[l],
(unsigned long)sc->swap_cluster_max);
- nr_active -= nr_to_scan;
- shrink_active_list(nr_to_scan, zone, sc, priority);
- }
+ nr[l] -= nr_to_scan;
- if (nr_inactive) {
- nr_to_scan = min(nr_inactive,
- (unsigned long)sc->swap_cluster_max);
- nr_inactive -= nr_to_scan;
- nr_reclaimed += shrink_inactive_list(nr_to_scan, zone,
- sc);
+ nr_reclaimed += shrink_list(l, nr_to_scan,
+ zone, sc, priority);
+ }
}
}
@@ -1809,6 +1808,7 @@ static unsigned long shrink_all_zones(un
{
struct zone *zone;
unsigned long nr_to_scan, ret = 0;
+ enum lru_list l;
for_each_zone(zone) {
@@ -1818,28 +1818,25 @@ static unsigned long shrink_all_zones(un
if (zone_is_all_unreclaimable(zone) && prio != DEF_PRIORITY)
continue;
- /* For pass = 0 we don't shrink the active list */
- if (pass > 0) {
- zone->nr_scan_active +=
- (zone_page_state(zone, NR_ACTIVE) >> prio) + 1;
- if (zone->nr_scan_active >= nr_pages || pass > 3) {
- zone->nr_scan_active = 0;
+ for_each_lru(l) {
+ /* For pass = 0 we don't shrink the active list */
+ if (pass == 0 && l == LRU_ACTIVE)
+ continue;
+
+ zone->nr_scan[l] +=
+ (zone_page_state(zone, NR_INACTIVE + l)
+ >> prio) + 1;
+ if (zone->nr_scan[l] >= nr_pages || pass > 3) {
+ zone->nr_scan[l] = 0;
nr_to_scan = min(nr_pages,
- zone_page_state(zone, NR_ACTIVE));
- shrink_active_list(nr_to_scan, zone, sc, prio);
+ zone_page_state(zone,
+ NR_INACTIVE + l));
+ ret += shrink_list(l, nr_to_scan, zone,
+ sc, prio);
+ if (ret >= nr_pages)
+ return ret;
}
}
-
- zone->nr_scan_inactive +=
- (zone_page_state(zone, NR_INACTIVE) >> prio) + 1;
- if (zone->nr_scan_inactive >= nr_pages || pass > 3) {
- zone->nr_scan_inactive = 0;
- nr_to_scan = min(nr_pages,
- zone_page_state(zone, NR_INACTIVE));
- ret += shrink_inactive_list(nr_to_scan, zone, sc);
- if (ret >= nr_pages)
- return ret;
- }
}
return ret;
Index: linux-2.6.24-rc6-mm1/mm/vmstat.c
=======
--- linux-2.6.24-rc6-mm1.orig/mm/vmstat.c 2008-01-02 12:37:11.0
-0500
+++ linux-2.6.24-rc6-mm1/mm/vmstat.c2008-01-02 12:37:32.0 -0500
@@ -758,7 +758,8 @@ static void zoneinfo_show_print(struct s
zone->pages_low,
zone->pages_high,
zone->pages_scanned,
- zone->nr_scan_active, zone->nr_scan_inactive,
+ zone->nr_scan[LRU_ACTIVE],
+ zone->nr_scan[LRU_INACTIVE],
zone->spanned_pages,
zone->present_pages);
--
All Rights Reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 09/19] add newly swapped in pages to the inactive list
Swapin_readahead can read in a lot of data that the processes in memory never need. Adding swap cache pages to the inactive list prevents them from putting too much pressure on the working set. This has the potential to help the programs that are already in memory, but it could also be a disadvantage to processes that are trying to get swapped in. In short, this patch needs testing. Signed-off-by: Rik van Riel <[EMAIL PROTECTED]> Index: linux-2.6.24-rc6-mm1/mm/swap_state.c === --- linux-2.6.24-rc6-mm1.orig/mm/swap_state.c 2008-01-02 12:37:38.0 -0500 +++ linux-2.6.24-rc6-mm1/mm/swap_state.c2008-01-02 12:37:52.0 -0500 @@ -300,7 +300,7 @@ struct page *read_swap_cache_async(swp_e /* * Initiate read into locked page and return. */ - lru_cache_add_active_anon(new_page); + lru_cache_add_anon(new_page); swap_readpage(NULL, new_page); return new_page; } -- All Rights Reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 08/19] SEQ replacement for anonymous pages
e pages which were snipped off */
@@ -1058,12 +1058,25 @@ static void shrink_active_list(unsigned
cond_resched();
page = lru_to_page(&l_hold);
list_del(&page->lru);
- if (page_referenced(page, 0, sc->mem_cgroup))
- lru = LRU_ACTIVE_ANON;
+ if (page_referenced(page, 0, sc->mem_cgroup)) {
+ if (file)
+ /* Referenced file pages stay active. */
+ lru = LRU_ACTIVE_ANON;
+ else
+ /* Anonymous pages always get deactivated. */
+ pgmoved++;
+ }
list_add(&page->lru, &list[lru]);
}
/*
+* Count the referenced anon pages as rotated, to balance pageout
+* scan pressure between file and anonymous pages in get_scan_ratio.
+*/
+ if (!file)
+ zone->recent_rotated_anon += pgmoved;
+
+ /*
* Now put the pages back to the appropriate [file or anon] inactive
* and active lists.
*/
@@ -1145,7 +1158,11 @@ static unsigned long shrink_list(enum lr
{
int file = is_file_lru(lru);
- if (lru == LRU_ACTIVE_ANON || lru == LRU_ACTIVE_FILE) {
+ if (lru == LRU_ACTIVE_FILE) {
+ shrink_active_list(nr_to_scan, zone, sc, priority, file);
+ return 0;
+ }
+ if (lru == LRU_ACTIVE_ANON && inactive_anon_low(zone)) {
shrink_active_list(nr_to_scan, zone, sc, priority, file);
return 0;
}
@@ -1255,8 +1272,8 @@ static unsigned long shrink_zone(int pri
}
}
- while (nr[LRU_ACTIVE_ANON] || nr[LRU_INACTIVE_ANON] ||
- nr[LRU_ACTIVE_FILE] || nr[LRU_INACTIVE_FILE]) {
+ while (nr[LRU_INACTIVE_ANON] || nr[LRU_ACTIVE_FILE] ||
+nr[LRU_INACTIVE_FILE]) {
for_each_lru(l) {
if (nr[l]) {
nr_to_scan = min(nr[l],
@@ -1560,6 +1577,14 @@ loop_again:
priority != DEF_PRIORITY)
continue;
+ /*
+* Do some background aging of the anon list, to give
+* pages a chance to be referenced before reclaiming.
+*/
+ if (inactive_anon_low(zone))
+ shrink_active_list(SWAP_CLUSTER_MAX, zone,
+ &sc, priority, 0);
+
if (!zone_watermark_ok(zone, order, zone->pages_high,
0, 0)) {
end_zone = i;
Index: linux-2.6.24-rc6-mm1/mm/vmstat.c
===
--- linux-2.6.24-rc6-mm1.orig/mm/vmstat.c 2008-01-02 15:55:33.0
-0500
+++ linux-2.6.24-rc6-mm1/mm/vmstat.c2008-01-02 15:56:07.0 -0500
@@ -800,10 +800,12 @@ static void zoneinfo_show_print(struct s
seq_printf(m,
"\n all_unreclaimable: %u"
"\n prev_priority: %i"
- "\n start_pfn: %lu",
+ "\n start_pfn: %lu"
+ "\n inactive_ratio:%u",
zone_is_all_unreclaimable(zone),
zone->prev_priority,
- zone->zone_start_pfn);
+ zone->zone_start_pfn,
+ zone->inactive_ratio);
seq_putc(m, '\n');
}
--
All Rights Reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 07/19] split anon & file LRUs for memcontrol code
zone->nr_scan[l] += (zone_page_state(zone,
NR_INACTIVE_ANON + l) >> priority) + 1;
nr[l] = zone->nr_scan[l] * percent[file] / 100;
@@ -1244,18 +1244,15 @@ static unsigned long shrink_zone(int pri
zone->nr_scan[l] = 0;
else
nr[l] = 0;
+ } else {
+ /*
+* This reclaim occurs not because zone memory shortage
+* but because memory controller hits its limit.
+* Then, don't modify zone reclaim related data.
+*/
+ nr[l] = mem_cgroup_calc_reclaim(sc->mem_cgroup, zone,
+ priority, l);
}
- } else {
- /*
-* This reclaim occurs not because zone memory shortage but
-* because memory controller hits its limit.
-* Then, don't modify zone reclaim related data.
-*/
- nr[LRU_ACTIVE] = mem_cgroup_calc_reclaim_active(sc->mem_cgroup,
- zone, priority);
-
- nr[LRU_INACTIVE] =
mem_cgroup_calc_reclaim_inactive(sc->mem_cgroup,
- zone, priority);
}
while (nr[LRU_ACTIVE_ANON] || nr[LRU_INACTIVE_ANON] ||
--
All Rights Reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 12/19] scan noreclaim list for reclaimable pages
}
+ } else {
+ SetPageNoreclaim(page);
+ list_move(&page->lru, l_noreclaim);
+ }
+
+ }
+ spin_unlock_irq(&zone->lru_lock);
+
+ nr_to_scan -= batch_size;
+ }
+}
+
+
+/**
+ * scan_all_zones_noreclaim_pages()
+ *
+ * A really big hammer: scan all zones' noreclaim LRU lists to check for
+ * pages that have become reclaimable. Move those back to the zones'
+ * inactive list where they become candidates for reclaim.
+ * This occurs when, e.g., we have unswappable pages on the noreclaim lists,
+ * and we add swap to the system. As such, it runs in the context of a task
+ * that has possibly/probably made some previously non-reclaimable pages
+ * reclaimable.
+//TODO: or as a last resort under extreme memory pressure--before OOM?
+ */
+void scan_all_zones_noreclaim_pages(void)
+{
+ struct zone *zone;
+
+ for_each_zone(zone) {
+ scan_zone_noreclaim_pages(zone);
+ }
+}
+
+/*
+ * scan_noreclaim_pages [vm] sysctl handler. On demand re-scan of
+ * all nodes' noreclaim lists for reclaimable pages
+ */
+unsigned long scan_noreclaim_pages;
+
+int scan_noreclaim_handler( struct ctl_table *table, int write,
+ struct file *file, void __user *buffer,
+ size_t *length, loff_t *ppos)
+{
+ proc_doulongvec_minmax(table, write, file, buffer, length, ppos);
+
+ if (write && *(unsigned long *)table->data)
+ scan_all_zones_noreclaim_pages();
+
+ scan_noreclaim_pages = 0;
+ return 0;
+}
+
+/*
+ * per node 'scan_noreclaim_pages' attribute. On demand re-scan of
+ * a specified node's per zone noreclaim lists for reclaimable pages.
+ */
+
+static ssize_t read_scan_noreclaim_node(struct sys_device *dev, char *buf)
+{
+ return sprintf(buf, "0\n"); /* always zero; should fit... */
+}
+
+static ssize_t write_scan_noreclaim_node(struct sys_device *dev,
+ const char *buf, size_t count)
+{
+ struct zone *node_zones = NODE_DATA(dev->id)->node_zones;
+ struct zone *zone;
+ unsigned long req = simple_strtoul(buf, NULL, 10);
+
+ if (!req)
+ return 1; /* zero is no-op */
+
+ for (zone = node_zones; zone - node_zones < MAX_NR_ZONES; ++zone) {
+ if (!populated_zone(zone))
+ continue;
+ scan_zone_noreclaim_pages(zone);
+ }
+ return 1;
+}
+
+
+static SYSDEV_ATTR(scan_noreclaim_pages, S_IRUGO | S_IWUSR,
+ read_scan_noreclaim_node,
+ write_scan_noreclaim_node);
+
+int scan_noreclaim_register_node(struct node *node)
+{
+ return sysdev_create_file(&node->sysdev, &attr_scan_noreclaim_pages);
+}
+
+void scan_noreclaim_unregister_node(struct node *node)
+{
+ sysdev_remove_file(&node->sysdev, &attr_scan_noreclaim_pages);
+}
+
+
#endif
Index: linux-2.6.24-rc6-mm1/kernel/sysctl.c
===
--- linux-2.6.24-rc6-mm1.orig/kernel/sysctl.c 2007-12-23 23:45:44.0
-0500
+++ linux-2.6.24-rc6-mm1/kernel/sysctl.c2008-01-02 13:07:09.0
-0500
@@ -1151,6 +1151,16 @@ static struct ctl_table vm_table[] = {
.extra2 = &one,
},
#endif
+#ifdef CONFIG_NORECLAIM
+ {
+ .ctl_name = CTL_UNNUMBERED,
+ .procname = "scan_noreclaim_pages",
+ .data = &scan_noreclaim_pages,
+ .maxlen = sizeof(scan_noreclaim_pages),
+ .mode = 0644,
+ .proc_handler = &scan_noreclaim_handler,
+ },
+#endif
/*
* NOTE: do not add new entries to this table unless you have read
* Documentation/sysctl/ctl_unnumbered.txt
Index: linux-2.6.24-rc6-mm1/drivers/base/node.c
===
--- linux-2.6.24-rc6-mm1.orig/drivers/base/node.c 2008-01-02
13:00:37.0 -0500
+++ linux-2.6.24-rc6-mm1/drivers/base/node.c2008-01-02 13:07:09.0
-0500
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
static struct sysdev_class node_class = {
.name = "node",
@@ -162,6 +163,8 @@ int register_node(struct node *node, int
sysdev_create_file(&node->sysdev, &attr_meminfo);
sysdev_create_file(&node->sysdev, &attr_numastat);
sysdev_create_file(&node->sysdev, &attr_distance);
+
+ scan_noreclaim_register_node(node);
}
return error;
}
@@ -180,6 +183,8 @@ void unregister_node(struct node *node)
sysdev_remove_file(&node->sysdev, &attr_numastat);
sysdev_r
[patch 10/19] No Reclaim LRU Infrastructure
ru(l) {
+ nr[LRU_INACTIVE_FILE]) {
+ for_each_reclaimable_lru(l) {
if (nr[l]) {
nr_to_scan = min(nr[l],
(unsigned long)sc->swap_cluster_max);
@@ -1814,8 +1874,8 @@ static unsigned long shrink_all_zones(un
if (zone_is_all_unreclaimable(zone) && prio != DEF_PRIORITY)
continue;
- for_each_lru(l) {
- /* For pass = 0 we don't shrink the active list */
+ for_each_reclaimable_lru(l) {
+ /* For pass = 0, we don't shrink the active list */
if (pass == 0 &&
(l == LRU_ACTIVE_ANON || l == LRU_ACTIVE_FILE))
continue;
@@ -2161,3 +2221,29 @@ int zone_reclaim(struct zone *zone, gfp_
return ret;
}
#endif
+
+#ifdef CONFIG_NORECLAIM
+/*
+ * page_reclaimable(struct page *page, struct vm_area_struct *vma)
+ * Test whether page is reclaimable--i.e., should be placed on active/inactive
+ * lists vs noreclaim list.
+ *
+ * @page - page to test
+ * @vma- vm area in which page is/will be mapped. May be NULL.
+ * If !NULL, called from fault path.
+ *
+ * Reasons page might not be reclaimable:
+ * TODO - later patches
+ *
+ * TODO: specify locking assumptions
+ */
+int page_reclaimable(struct page *page, struct vm_area_struct *vma)
+{
+
+ VM_BUG_ON(PageNoreclaim(page));
+
+ /* TODO: test page [!]reclaimable conditions */
+
+ return 1;
+}
+#endif
Index: linux-2.6.24-rc6-mm1/mm/mempolicy.c
===
--- linux-2.6.24-rc6-mm1.orig/mm/mempolicy.c2008-01-02 16:00:39.0
-0500
+++ linux-2.6.24-rc6-mm1/mm/mempolicy.c 2008-01-02 16:00:54.0 -0500
@@ -1912,7 +1912,7 @@ static void gather_stats(struct page *pa
if (PageSwapCache(page))
md->swapcache++;
- if (PageActive(page))
+ if (PageActive(page) || PageNoreclaim(page))
md->active++;
if (PageWriteback(page))
Index: linux-2.6.24-rc6-mm1/mm/memcontrol.c
=======
--- linux-2.6.24-rc6-mm1.orig/mm/memcontrol.c 2008-01-02 16:00:39.0
-0500
+++ linux-2.6.24-rc6-mm1/mm/memcontrol.c2008-01-02 16:00:54.0
-0500
@@ -520,6 +520,10 @@ unsigned long mem_cgroup_isolate_pages(u
scan++;
list_move(&pc->lru, &pc_list);
+//TODO: for now, don't isolate non-reclaimable pages. When/if
+// mem controller supports a noreclaim list, we'll need to make
+// at least ISOLATE_ACTIVE visible outside of vm_scan and pass
+// the 'take_nonreclaimable' flag accordingly.
if (__isolate_lru_page(page, mode, file) == 0) {
list_move(&page->lru, dst);
nr_taken++;
--
All Rights Reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/19] Non-reclaimable page statistics
nid, K(i.totalhigh), nid, K(i.freehigh), Index: linux-2.6.24-rc6-mm1/fs/proc/proc_misc.c === --- linux-2.6.24-rc6-mm1.orig/fs/proc/proc_misc.c 2008-01-02 12:37:38.0 -0500 +++ linux-2.6.24-rc6-mm1/fs/proc/proc_misc.c2008-01-02 12:38:03.0 -0500 @@ -162,6 +162,9 @@ static int meminfo_read_proc(char *page, "Inactive(anon): %8lu kB\n" "Active(file): %8lu kB\n" "Inactive(file): %8lu kB\n" +#ifdef CONFIG_NORECLAIM + "Noreclaim:%8lu kB\n" +#endif #ifdef CONFIG_HIGHMEM "HighTotal: %8lu kB\n" "HighFree: %8lu kB\n" @@ -194,6 +197,9 @@ static int meminfo_read_proc(char *page, K(global_page_state(NR_INACTIVE_ANON)), K(global_page_state(NR_ACTIVE_FILE)), K(global_page_state(NR_INACTIVE_FILE)), +#ifdef CONFIG_NORECLAIM + K(global_page_state(NR_NORECLAIM)), +#endif #ifdef CONFIG_HIGHMEM K(i.totalhigh), K(i.freehigh), -- All Rights Reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 00/19] VM pageout scalability improvements
On large memory systems, the VM can spend way too much time scanning through pages that it cannot (or should not) evict from memory. Not only does it use up CPU time, but it also provokes lock contention and can leave large systems under memory presure in a catatonic state. Against 2.6.24-rc6-mm1 This patch series improves VM scalability by: 1) making the locking a little more scalable 2) putting filesystem backed, swap backed and non-reclaimable pages onto their own LRUs, so the system only scans the pages that it can/should evict from memory 3) switching to SEQ replacement for the anonymous LRUs, so the number of pages that need to be scanned when the system starts swapping is bound to a reasonable number The noreclaim patches come verbatim from Lee Schermerhorn and Nick Piggin. I have made a few small fixes to them and left out the bits that are no longer needed with split file/anon lists. The exception is "Scan noreclaim list for reclaimable pages", which should not be needed but could be a useful debugging tool. -- All Rights Reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 14/19] SHM_LOCKED pages are nonreclaimable
unsigned long scan;
unsigned long nr_to_scan = zone_page_state(zone, NR_NORECLAIM);
@@ -2282,26 +2304,15 @@ void scan_zone_noreclaim_pages(struct zo
for (scan = 0; scan < batch_size; scan++) {
struct page* page = lru_to_page(l_noreclaim);
- if (unlikely(!PageLRU(page) || !PageNoreclaim(page)))
+ if (TestSetPageLocked(page))
continue;
prefetchw_prev_lru_page(page, l_noreclaim, flags);
- ClearPageNoreclaim(page); /* for page_reclaimable() */
- if(page_reclaimable(page, NULL)) {
- __dec_zone_state(zone, NR_NORECLAIM);
- if (page_file_cache(page)) {
- list_move(&page->lru, l_inactive_file);
- __inc_zone_state(zone,
NR_INACTIVE_FILE);
- } else {
- list_move(&page->lru, l_inactive_anon);
- __inc_zone_state(zone,
NR_INACTIVE_ANON);
- }
- } else {
- SetPageNoreclaim(page);
- list_move(&page->lru, l_noreclaim);
- }
+ if (likely(PageLRU(page) && PageNoreclaim(page)))
+ check_move_noreclaim_page(page, zone);
+ unlock_page(page);
}
spin_unlock_irq(&zone->lru_lock);
@@ -2331,6 +2342,62 @@ void scan_all_zones_noreclaim_pages(void
}
}
+/**
+ * scan_mapping_noreclaim_pages(mapping)
+ * @mapping - struct address_space to scan for reclaimable pages
+ *
+ * scan all pages in mapping. check non-reclaimable pages for
+ * reclaimabililty and move them to the appropriate zone lru list.
+ */
+void scan_mapping_noreclaim_pages(struct address_space *mapping)
+{
+ pgoff_t next = 0;
+ pgoff_t end = i_size_read(mapping->host);
+ struct zone *zone;
+ struct pagevec pvec;
+
+ if (mapping->nrpages == 0)
+ return;
+
+ pagevec_init(&pvec, 0);
+ while (next < end &&
+ pagevec_lookup(&pvec, mapping, next, PAGEVEC_SIZE)) {
+ int i;
+
+ zone = NULL;
+
+ for (i = 0; i < pagevec_count(&pvec); i++) {
+ struct page *page = pvec.pages[i];
+ pgoff_t page_index = page->index;
+ struct zone *pagezone = page_zone(page);
+
+ if (page_index > next)
+ next = page_index;
+ next++;
+
+ if (TestSetPageLocked(page))
+ continue;
+
+ if (pagezone != zone) {
+ if (zone)
+ spin_unlock(&zone->lru_lock);
+ zone = pagezone;
+ spin_lock(&zone->lru_lock);
+ }
+
+ if (PageLRU(page) && PageNoreclaim(page))
+ check_move_noreclaim_page(page, zone);
+
+ unlock_page(page);
+
+ }
+ if (zone)
+ spin_unlock(&zone->lru_lock);
+ pagevec_release(&pvec);
+ }
+
+}
+
/*
* scan_noreclaim_pages [vm] sysctl handler. On demand re-scan of
* all nodes' noreclaim lists for reclaimable pages
Index: linux-2.6.24-rc6-mm1/include/linux/swap.h
===
--- linux-2.6.24-rc6-mm1.orig/include/linux/swap.h 2008-01-02
13:07:09.0 -0500
+++ linux-2.6.24-rc6-mm1/include/linux/swap.h 2008-01-02 13:24:55.0
-0500
@@ -218,6 +218,7 @@ static inline int zone_reclaim(struct zo
extern int page_reclaimable(struct page *page, struct vm_area_struct *vma);
extern void scan_zone_noreclaim_pages(struct zone *);
extern void scan_all_zones_noreclaim_pages(void);
+extern void scan_mapping_noreclaim_pages(struct address_space *);
extern unsigned long scan_noreclaim_pages;
extern int scan_noreclaim_handler(struct ctl_table *, int, struct file *,
void __user *, size_t *, loff_t *);
@@ -231,6 +232,9 @@ static inline int page_reclaimable(struc
}
static inline void scan_zone_noreclaim_pages(struct zone *z) { }
static inline void scan_all_zones_noreclaim_pages(void) { }
+static inline void scan_mapping_noreclaim_pages(struct address_space *mapping)
+{
+}
static inline int scan_noreclaim_register_node(struct node *node)
{
return 0;
--
All Rights Reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 13/19] ramfs pages are non-reclaimable
.ioctl =brd_ioctl, #ifdef CONFIG_BLK_DEV_XIP .direct_access = brd_direct_access, -- All Rights Reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 18/19] account mlocked pages
*
@@ -75,8 +75,11 @@ void mlock_vma_page(struct page *page)
{
BUG_ON(!PageLocked(page));
- if (!TestSetPageMlocked(page) && !isolate_lru_page(page))
+ if (!TestSetPageMlocked(page)) {
+ inc_zone_page_state(page, NR_MLOCK);
+ if (!isolate_lru_page(page))
putback_lru_page(page);
+ }
}
/*
@@ -98,10 +101,22 @@ static void munlock_vma_page(struct page
{
BUG_ON(!PageLocked(page));
- if (TestClearPageMlocked(page) && !isolate_lru_page(page)) {
- if (try_to_unlock(page) == SWAP_MLOCK)
- SetPageMlocked(page); /* still VM_LOCKED */
- putback_lru_page(page);
+ if (TestClearPageMlocked(page)) {
+ dec_zone_page_state(page, NR_MLOCK);
+ if (!isolate_lru_page(page)) {
+ if (try_to_unlock(page) == SWAP_MLOCK) {
+ SetPageMlocked(page); /* still VM_LOCKED */
+ inc_zone_page_state(page, NR_MLOCK);
+ }
+ putback_lru_page(page);
+ }
+ /*
+* Else we lost the race. let try_to_unmap() deal with it.
+* At least we get the page state and mlock stats right.
+* However, page is still on the noreclaim list. We'll fix
+* that up when the page is eventually freed or we scan the
+* noreclaim list.
+*/
}
}
@@ -118,7 +133,8 @@ int is_mlocked_vma(struct vm_area_struct
if (likely(!(vma->vm_flags & VM_LOCKED)))
return 0;
- SetPageMlocked(page);
+ if (!TestSetPageMlocked(page))
+ inc_zone_page_state(page, NR_MLOCK);
return 1;
}
Index: linux-2.6.24-rc6-mm1/mm/migrate.c
===
--- linux-2.6.24-rc6-mm1.orig/mm/migrate.c 2008-01-02 17:08:17.0
-0500
+++ linux-2.6.24-rc6-mm1/mm/migrate.c 2008-01-02 17:08:17.0 -0500
@@ -366,8 +366,15 @@ static void migrate_page_copy(struct pag
set_page_dirty(newpage);
}
- if (TestClearPageMlocked(page))
+ if (TestClearPageMlocked(page)) {
+ unsigned long flags;
+
+ local_irq_save(flags);
+ __dec_zone_page_state(page, NR_MLOCK);
SetPageMlocked(newpage);
+ __inc_zone_page_state(newpage, NR_MLOCK);
+ local_irq_restore(flags);
+ }
#ifdef CONFIG_SWAP
ClearPageSwapCache(page);
Index: linux-2.6.24-rc6-mm1/mm/vmstat.c
===
--- linux-2.6.24-rc6-mm1.orig/mm/vmstat.c 2008-01-02 16:01:21.0
-0500
+++ linux-2.6.24-rc6-mm1/mm/vmstat.c2008-01-02 17:09:20.0 -0500
@@ -693,6 +693,9 @@ static const char * const vmstat_text[]
#ifdef CONFIG_NORECLAIM
"nr_noreclaim",
#endif
+#ifdef CONFIG_NORECLAIM_MLOCK
+ "nr_mlock",
+#endif
"nr_anon_pages",
"nr_mapped",
"nr_file_pages",
--
All Rights Reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 17/19] handle mlocked pages during map/unmap and truncate
_addr + new_len);
}
return new_addr;
@@ -373,7 +375,7 @@ unsigned long do_mremap(unsigned long ad
vm_stat_account(mm, vma->vm_flags, vma->vm_file, pages);
if (vma->vm_flags & VM_LOCKED) {
mm->locked_vm += pages;
- make_pages_present(addr + old_len,
+ mlock_vma_pages_range(vma, addr + old_len,
addr + new_len);
}
ret = addr;
Index: linux-2.6.24-rc6-mm1/mm/vmscan.c
===
--- linux-2.6.24-rc6-mm1.orig/mm/vmscan.c 2008-01-02 15:04:11.0
-0500
+++ linux-2.6.24-rc6-mm1/mm/vmscan.c2008-01-02 15:08:07.0 -0500
@@ -540,6 +540,10 @@ static unsigned long shrink_page_list(st
goto activate_locked;
case SWAP_AGAIN:
goto keep_locked;
+ case SWAP_MLOCK:
+ ClearPageActive(page);
+ SetPageNoreclaim(page);
+ goto keep_locked; /* to noreclaim list */
case SWAP_SUCCESS:
; /* try to free the page below */
}
Index: linux-2.6.24-rc6-mm1/mm/filemap.c
===
--- linux-2.6.24-rc6-mm1.orig/mm/filemap.c 2008-01-02 12:37:38.0
-0500
+++ linux-2.6.24-rc6-mm1/mm/filemap.c 2008-01-02 15:08:07.0 -0500
@@ -2525,8 +2525,16 @@ generic_file_direct_IO(int rw, struct ki
if (rw == WRITE) {
write_len = iov_length(iov, nr_segs);
end = (offset + write_len - 1) >> PAGE_CACHE_SHIFT;
- if (mapping_mapped(mapping))
+ if (mapping_mapped(mapping)) {
+ /*
+* Calling unmap_mapping_range like this is wrong,
+* because it can lead to mlocked pages being
+* discarded (this is true even before the Noreclaim
+* mlock work). direct-IO vs pagecache is a load of
+* junk anyway, so who cares.
+*/
unmap_mapping_range(mapping, offset, write_len, 0);
+ }
}
retval = filemap_write_and_wait(mapping);
Index: linux-2.6.24-rc6-mm1/mm/truncate.c
===
--- linux-2.6.24-rc6-mm1.orig/mm/truncate.c 2007-12-23 23:45:44.0
-0500
+++ linux-2.6.24-rc6-mm1/mm/truncate.c 2008-01-02 15:08:07.0 -0500
@@ -18,6 +18,7 @@
#include
#include /* grr. try_to_release_page,
do_invalidatepage */
+#include "internal.h"
/**
@@ -104,6 +105,7 @@ truncate_complete_page(struct address_sp
cancel_dirty_page(page, PAGE_CACHE_SIZE);
remove_from_page_cache(page);
+ clear_page_mlock(page);
ClearPageUptodate(page);
ClearPageMappedToDisk(page);
page_cache_release(page); /* pagecache ref */
@@ -128,6 +130,7 @@ invalidate_complete_page(struct address_
if (PagePrivate(page) && !try_to_release_page(page, 0))
return 0;
+ clear_page_mlock(page);
ret = remove_mapping(mapping, page);
return ret;
@@ -354,6 +357,7 @@ invalidate_complete_page2(struct address
if (PageDirty(page))
goto failed;
+ clear_page_mlock(page);
BUG_ON(PagePrivate(page));
__remove_from_page_cache(page);
write_unlock_irq(&mapping->tree_lock);
--
All Rights Reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 16/19] mlock vma pages under mmap_sem held for read
nd > (*prev)->vm_end)
+ ret = -EAGAIN;
+ }
+
out:
if (ret == -ENOMEM)
ret = -EAGAIN;
Index: linux-2.6.24-rc6-mm1/mm/internal.h
===
--- linux-2.6.24-rc6-mm1.orig/mm/internal.h 2008-01-02 14:58:22.0
-0500
+++ linux-2.6.24-rc6-mm1/mm/internal.h 2008-01-02 15:07:37.0 -0500
@@ -61,24 +61,21 @@ extern int __mlock_vma_pages_range(struc
/*
* mlock all pages in this vma range. For mmap()/mremap()/...
*/
-static inline void mlock_vma_pages_range(struct vm_area_struct *vma,
- unsigned long start, unsigned long end)
-{
- __mlock_vma_pages_range(vma, start, end, 1);
-}
+extern int mlock_vma_pages_range(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end);
/*
* munlock range of pages. For munmap() and exit().
* Always called to operate on a full vma that is being unmapped.
*/
-static inline void munlock_vma_pages_range(struct vm_area_struct *vma,
+static inline int munlock_vma_pages_range(struct vm_area_struct *vma,
unsigned long start, unsigned long end)
{
// TODO: verify my assumption. Should we just drop the start/end args?
VM_BUG_ON(start != vma->vm_start || end != vma->vm_end);
vma->vm_flags &= ~VM_LOCKED;/* try_to_unlock() needs this */
- __mlock_vma_pages_range(vma, start, end, 0);
+ return __mlock_vma_pages_range(vma, start, end, 0);
}
extern void clear_page_mlock(struct page *page);
@@ -90,10 +87,10 @@ static inline int is_mlocked_vma(struct
}
static inline void clear_page_mlock(struct page *page) { }
static inline void mlock_vma_page(struct page *page) { }
-static inline void mlock_vma_pages_range(struct vm_area_struct *vma,
- unsigned long start, unsigned long end) { }
-static inline void munlock_vma_pages_range(struct vm_area_struct *vma,
- unsigned long start, unsigned long end) { }
+static inline int mlock_vma_pages_range(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end) { return 0; }
+static inline int munlock_vma_pages_range(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end) { return 0; }
#endif /* CONFIG_NORECLAIM_MLOCK */
--
All Rights Reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 15/19] non-reclaimable mlocked pages
1 << PG_swapcache |
1 << PG_writeback |
1 << PG_swapbacked |
+ 1 << PG_mlocked |
1 << PG_buddy );
set_page_count(page, 0);
reset_page_mapcount(page);
@@ -488,6 +489,9 @@ static inline int free_pages_check(struc
#ifdef CONFIG_NORECLAIM
1 << PG_noreclaim |
#endif
+// TODO: always trip this under heavy workloads.
+// Why isn't this being cleared on last unmap/unlock?
+// 1 << PG_mlocked |
1 << PG_buddy
bad_page(page);
if (PageDirty(page))
@@ -644,6 +648,8 @@ static int prep_new_page(struct page *pa
1 << PG_writeback |
1 << PG_reserved |
1 << PG_swapbacked |
+//TODO: why hitting this?
+// 1 << PG_mlocked |
1 << PG_buddy
bad_page(page);
@@ -656,7 +662,9 @@ static int prep_new_page(struct page *pa
page->flags &= ~(1 << PG_uptodate | 1 << PG_error | 1 << PG_readahead |
1 << PG_referenced | 1 << PG_arch_1 |
- 1 << PG_owner_priv_1 | 1 << PG_mappedtodisk);
+ 1 << PG_owner_priv_1 | 1 << PG_mappedtodisk |
+//TODO take care of it here, for now.
+ 1 << PG_mlocked );
set_page_private(page, 0);
set_page_refcounted(page);
Index: linux-2.6.24-rc6-mm1/mm/swap.c
===
--- linux-2.6.24-rc6-mm1.orig/mm/swap.c 2008-01-02 14:53:08.0 -0500
+++ linux-2.6.24-rc6-mm1/mm/swap.c 2008-01-02 14:53:15.0 -0500
@@ -346,7 +346,7 @@ void lru_add_drain(void)
put_cpu();
}
-#ifdef CONFIG_NUMA
+#if defined(CONFIG_NUMA) || defined(CONFIG_NORECLAIM_MLOCK)
static void lru_add_drain_per_cpu(struct work_struct *dummy)
{
lru_add_drain();
--
All Rights Reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 19/19] cull non-reclaimable anon pages from the LRU at fault time
V2 -> V3:
+ rebase to 23-mm1 atop RvR's split lru series.
V1 -> V2:
+ no changes
Optional part of "noreclaim infrastructure"
In the fault paths that install new anonymous pages, check whether
the page is reclaimable or not using lru_cache_add_active_or_noreclaim().
If the page is reclaimable, just add it to the active lru list [via
the pagevec cache], else add it to the noreclaim list.
This "proactive" culling in the fault path mimics the handling of
mlocked pages in Nick Piggin's series to keep mlocked pages off
the lru lists.
Notes:
1) This patch is optional--e.g., if one is concerned about the
additional test in the fault path. We can defer the moving of
nonreclaimable pages until when vmscan [shrink_*_list()]
encounters them. Vmscan will only need to handle such pages
once.
2) I moved the call to page_add_new_anon_rmap() to before the test
for page_reclaimable() and thus before the calls to
lru_cache_add_{active|noreclaim}(), so that page_reclaimable()
could recognize the page as anon, thus obviating, I think, the
vma arg to page_reclaimable() for this purpose. Still needed for
culling mlocked pages in fault path [later patch].
TBD: I think this reordering is OK, but the previous order may
have existed to close some obscure race?
3) With this and other patches above installed, any anon pages
created before swap is added--e.g., init's anonymous memory--
will be declared non-reclaimable and placed on the noreclaim
LRU list. Need to add mechanism to bring such pages back when
swap becomes available.
Signed-off-by: Lee Schermerhorn <[EMAIL PROTECTED]>
Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>
Index: linux-2.6.24-rc6-mm1/mm/memory.c
===
--- linux-2.6.24-rc6-mm1.orig/mm/memory.c 2008-01-02 12:37:38.0
-0500
+++ linux-2.6.24-rc6-mm1/mm/memory.c2008-01-02 15:14:31.0 -0500
@@ -1665,7 +1665,7 @@ gotten:
set_pte_at(mm, address, page_table, entry);
update_mmu_cache(vma, address, entry);
SetPageSwapBacked(new_page);
- lru_cache_add_active_anon(new_page);
+ lru_cache_add_active_or_noreclaim(new_page, vma);
page_add_new_anon_rmap(new_page, vma, address);
/* Free the old page.. */
@@ -2133,7 +2133,7 @@ static int do_anonymous_page(struct mm_s
goto release;
inc_mm_counter(mm, anon_rss);
SetPageSwapBacked(page);
- lru_cache_add_active_anon(page);
+ lru_cache_add_active_or_noreclaim(page, vma);
page_add_new_anon_rmap(page, vma, address);
set_pte_at(mm, address, page_table, entry);
@@ -2285,10 +2285,10 @@ static int __do_fault(struct mm_struct *
entry = maybe_mkwrite(pte_mkdirty(entry), vma);
set_pte_at(mm, address, page_table, entry);
if (anon) {
-inc_mm_counter(mm, anon_rss);
+ inc_mm_counter(mm, anon_rss);
SetPageSwapBacked(page);
-lru_cache_add_active_anon(page);
-page_add_new_anon_rmap(page, vma, address);
+ lru_cache_add_active_or_noreclaim(page, vma);
+ page_add_new_anon_rmap(page, vma, address);
} else {
inc_mm_counter(mm, file_rss);
page_add_file_rmap(page);
Index: linux-2.6.24-rc6-mm1/mm/swap_state.c
===
--- linux-2.6.24-rc6-mm1.orig/mm/swap_state.c 2008-01-02 12:37:52.0
-0500
+++ linux-2.6.24-rc6-mm1/mm/swap_state.c2008-01-02 15:14:31.0
-0500
@@ -300,7 +300,10 @@ struct page *read_swap_cache_async(swp_e
/*
* Initiate read into locked page and return.
*/
- lru_cache_add_anon(new_page);
+ if (!page_reclaimable(new_page, vma))
+ lru_cache_add_noreclaim(new_page);
+ else
+ lru_cache_add_anon(new_page);
swap_readpage(NULL, new_page);
return new_page;
}
--
All Rights Reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
"Unable to handle kernel NULL pointer dereference" in 2.6.18.2 (2.6.18-1.2239.fc5)
cmd 0xD480 ctl 0xD402 bmdma 0xD088 irq 130 scsi9 : sata_nv ata9: SATA link down (SStatus 0 SControl 300) ATA: abnormal status 0x7F on port 0xD887 scsi10 : sata_nv ata10: SATA link down (SStatus 0 SControl 300) ATA: abnormal status 0x7F on port 0xD487 ACPI: PCI Interrupt Link [ISI2] enabled at IRQ 45 GSI 22 sharing vector 0x8A and IRQ 22 ACPI: PCI Interrupt :80:05.2[C] -> Link [ISI2] -> GSI 45 (level, low) -> IRQ 138 ata11: SATA max UDMA/133 cmd 0xD000 ctl 0xCC02 bmdma 0xC480 irq 138 ata12: SATA max UDMA/133 cmd 0xC880 ctl 0xC802 bmdma 0xC488 irq 138 scsi11 : sata_nv ata11: SATA link down (SStatus 0 SControl 300) ATA: abnormal status 0x7F on port 0xD007 scsi12 : sata_nv ata12: SATA link down (SStatus 0 SControl 300) ATA: abnormal status 0x7F on port 0xC887 EXT3-fs: INFO: recovery required on readonly filesystem. EXT3-fs: write access will be enabled during recovery. kjournald starting. Commit interval 5 seconds EXT3-fs: sda1: orphan cleanup on readonly fs EXT3-fs: sda1: 25 orphan inodes deleted EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. audit(1163769770.617:2): enforcing=1 old_enforcing=0 auid=4294967295 security: 3 users, 6 roles, 1481 types, 152 bools, 1 sens, 256 cats security: 58 classes, 43474 rules SELinux: Completing initialization. SELinux: Setting up existing superblocks. SELinux: initialized (dev sda1, type ext3), uses xattr SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses genfs_contexts SELinux: initialized (dev devpts, type devpts), uses transition SIDs SELinux: initialized (dev eventpollfs, type eventpollfs), uses task SIDs SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts SELinux: initialized (dev pipefs, type pipefs), uses task SIDs SELinux: initialized (dev sockfs, type sockfs), uses task SIDs SELinux: initialized (dev cpuset, type cpuset), not configured for labeling SELinux: initialized (dev proc, type proc), uses genfs_contexts SELinux: initialized (dev bdev, type bdev), uses genfs_contexts SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts audit(1163769770.723:3): policy loaded auid=4294967295 SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts -- "Developers are like artists; they produce their best work if they have the freedom to do so" - Werner Vogels, CTO Amazon.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: VIA C7 / VIA PC-1 (PC2500) anyone?
Michael Tokarev wrote: > I bought a VIA PC2500 board a few days ago - this > new series of their mobos, > > This beast looks nice - after replacing their cooling > system (that had a small fan on it) with larger but > fanless, -- it becomes a almost real PC (1500MHz CPU), > equipped with quite nice crypto and multimedia abilities, > but with very low power consumption and very quiet. > > But the thing is - it doesn't quite work. > > It works generally - it boots, I can run my usual apps > etc. But on a random (yet frequent) basis it segfaults > here and there. For example: > > $ man man > Reformatting man(1), please wait... > $ man man > Segmentation fault > $ man man > Segmentation fault > $ man man > Segmentation fault > $ man man > Segmentation fault > $ man man > Reformatting man(1), please wait... > $ _ > > (this is 100% idle machine, just booted). > > (There are other - simple and comples - applications which > inhibits this problem. For example, it 99% reliable segfaults > on compiling aic79xx_core.c file in kernel, while all the rest > (in my configuration anyway) compiles, at least after second > attempt). > > It's definitely NOT memory issue - I tried several different > memory modules (and different combinations) - the same results; > I ran memtest86 for several days - no single error. > > I've seen a thread here on LKML about C7 and C3 CPUs back in > March this year - tried with patch from Andi titled > "i386: Enable CX8/PGE CPUID bits early on VIA C3" - it didn't > change anything (this board does not lock up - not when booting > nor when doing something, -- just random applications are > crashing randomly, and the crash is always SIGSEGV; there's > _nothing_ in dmesg about that, too). > > From all the above it seems like something's broke on the > motherboard (I've no idea what it can be however - because > memory testing - which also tests for CPU cache for exampe - > shows no errors; testing disk controller/disk using md5 does > not show errors either, except of occasional SIGSEGVs).. > > However, being very curious about this, I tried installing > 'doze on this machine - winXP. And that one went just fine > without any error so far -- i tried stress-testing it as far > as I can imagine, running various applications and workloads, -- > no errors. > > So I'm kinda.. stuck about what to do next. > > Any.. idea, anyone? :) > > Thanks! > > /mjt To me it looks like a wrong choice of gcc switches to user-mode programs. What distribution are you using? try compiling failing programs from source with conservative command line switches to gcc. See if things change. Boaz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hacking Alert! You account was hacked (your password:qwerty)
Dear user of vger.kernel.org! I am a spyware software developer. Your account has been hacked by me in the summer of 2018. I understand that it is hard to believe, but here is my evidence: - I sent you this email from your account. - Password from account linux-kernel@vger.kernel.org: qwerty (on moment of hack). The hacking was carried out using a hardware vulnerability through which you went online (Cisco router, vulnerability CVE-2018-0296). I went around the security system in the router, installed an exploit there. When you went online, my exploit downloaded my malicious code (rootkit) to your device. This is driver software, I constantly updated it, so your antivirus is silent all time. Since then I have been following you (I can connect to your device via the VNC protocol). That is, I can see absolutely everything that you do, view and download your files and any data to yourself. I also have access to the camera on your device, and I periodically take photos and videos with you. At the moment, I have harvested a solid dirt... on you... I saved all your email and chats from your messangers. I also saved the entire history of the sites you visit. I note that it is useless to change the passwords. My malware update passwords from your accounts every times. I know what you like hard funs (adult sites). Oh, yes .. I'm know your secret life, which you are hiding from everyone. Oh my God, what are your like... I saw THIS ... Oh, you dirty naughty person ... :) I took photos and videos of your most passionate funs with adult content, and synchronized them in real time with the image of your camera. Believe it turned out very high quality! So, to the business! I'm sure you don't want to show these files and visiting history to all your contacts. Transfer $868 to my Bitcoin cryptocurrency wallet: 1Bt4psBJmjfVTcW6eYiJZ6HEbpFgKkBSX4 Just copy and paste the wallet number when transferring. If you do not know how to do this - ask Google. My system automatically recognizes the translation. As soon as the specified amount is received, all your data will be destroyed from my server, and the rootkit will be automatically removed from your system. Do not worry, I really will delete everything, since I am “working” with many people who have fallen into your position. You will only have to inform your provider about the vulnerabilities in the router so that other hackers will not use it. Since opening this letter you have 48 hours. If funds not will be received, after the specified time has elapsed, the disk of your device will be formatted, and from my server will automatically send email and sms to all your contacts with compromising material. I advise you to remain prudent and not engage in nonsense (all files on my server). Good luck!
Change your password qwerty immediately. Your account has been hacked.
I greet you! I have bad news for you. 06/28/2018 - on this day I hacked your operating system and got full access to your account linux-kernel@vger.kernel.org On that day your account (linux-kernel@vger.kernel.org) password was: qwerty It is useless to change the password, my malware intercepts it every time. How it was: In the software of the router to which you were connected that day, there was a vulnerability. I first hacked this router and placed my malicious code on it. When you entered in the Internet, my trojan was installed on the operating system of your device. After that, I made a full dump of your disk (I have all your address book, history of viewing sites, all files, phone numbers and addresses of all your contacts). A month ago, I wanted to lock your device and ask for a small amount of money to unlock. But I looked at the sites that you regularly visit, and came to the big delight of your favorite resources. I'm talking about sites for adults. I want to say - you are a big pervert. You have unbridled fantasy! After that, an idea came to my mind. I made a screenshot of the intimate website where you have fun (you know what it is about, right?). After that, I took off your joys (using the camera of your device). It turned out beautifully, do not hesitate. I am strongly belive that you would not like to show these pictures to your relatives, friends or colleagues. I think $913 is a very small amount for my silence. Besides, I spent a lot of time on you! I accept money only in Bitcoins. My BTC wallet: 15ZHnf1MPn6ybb8yUeAoCQ1AJtiKhg3NrP You do not know how to replenish a Bitcoin wallet? In any search engine write "how to send money to btc wallet". It's easier than send money to a credit card! For payment you have a little more than two days (exactly 50 hours). Do not worry, the timer will start at the moment when you open this letter. Yes, yes .. it has already started! After payment, my virus and dirty photos with you self-destruct automatically. Narrative, if I do not receive the specified amount from you, then your device will be blocked, and all your contacts will receive a photos with your "joys". I want you to be prudent. - Do not try to find and destroy my virus! (All your data is already uploaded to a remote server) - Do not try to contact me (this is not feasible, I sent you an email from your account) - Various security services will not help you; formatting a disk or destroying a device will not help either, since your data is already on a remote server. P.S. I guarantee you that I will not disturb you again after payment, as you are not my single victim. This is a hacker code of honor. >From now on, I advise you to use good antiviruses and update them regularly >(several times a day)! Don't be mad at me, everyone has their own work. Farewell.
Delete Message After Reading!
Hello! I'm a member of an international hacker group. As you could probably have guessed, your account linux-kernel@vger.kernel.org was hacked, because I sent message you from it. Now I have access to you accounts! For example, your password for linux-kernel@vger.kernel.org is qwerty Within a period from July 17, 2018 to October 3, 2018, you were infected by the virus we've created, through an adult website you've visited. So far, we have access to your messages, social media accounts, and messengers. Moreover, we've gotten full damps of these data. We are aware of your little and big secrets...yeah, you do have them. We saw and recorded your doings on porn websites. Your tastes are so weird, you know.. But the key thing is that sometimes we recorded you with your webcam, syncing the recordings with what you watched! I think you are not interested show this video to your friends, relatives, and your intimate one... Transfer $800 to our Bitcoin wallet: 14bXUoPwruptLamUfKTuMW39Qy1q4ohX9w If you don't know about Bitcoin please input in Google "buy BTC". It's really easy. I guarantee that after that, we'll erase all your "data" :) A timer will start once you read this message. You have 48 hours to pay the above-mentioned amount. Your data will be erased once the money are transferred. If they are not, all your messages and videos recorded will be automatically sent to all your contacts found on your devices at the moment of infection. You should always think about your security. We hope this case will teach you to keep secrets. Take care of yourself.
Your Account Was Hacked!
Hi, dear user of vger.kernel.org We have installed one RAT software into you device. For this moment your email account is hacked (see on "from address", I messaged you from your account). Your password for linux-kernel@vger.kernel.org: qwerty I have downloaded all confidential information from your system and I got some more evidence. The most interesting moment that I have discovered are videos records where you masturbating. I posted my virus on porn site, and then you installed it on your operation system. When you clicked the button Play on porn video, at that moment my trojan was downloaded to your device. After installation, your front camera shoots video every time you masturbate, in addition, the software is synchronized with the video you choose. For the moment, the software has collected all your contact information from social networks and email addresses. If you need to erase all of your collected data, send me $800 in BTC (crypto currency). This is my Bitcoin wallet: 13cyEdT7kyH2f4j9xchvDGhv1o64MYNLUS You have 48 hours after reading this letter. After your transaction I will erase all your data. Otherwise, I will send video with your pranks to all your colleagues and friends!!! And henceforth be more careful! Please visit only secure sites! Bye!
linux-kernel@vger.kernel.org has password qwerty. Password must be changed
Hello! I'm a programmer who cracked your email account and device about half year ago. You entered a password on one of the insecure site you visited, and I catched it. Your password from linux-kernel@vger.kernel.org on moment of crack: qwerty Of course you can will change your password, or already made it. But it doesn't matter, my rat software update it every time. Please don't try to contact me or find me, it is impossible, since I sent you an email from your email account. Through your e-mail, I uploaded malicious code to your Operation System. I saved all of your contacts with friends, colleagues, relatives and a complete history of visits to the Internet resources. Also I installed a rat software on your device and long tome spying for you. You are not my only victim, I usually lock devices and ask for a ransom. But I was struck by the sites of intimate content that you very often visit. I am in shock of your reach fantasies! Wow! I've never seen anything like this! I did not even know that SUCH content could be so exciting! So, when you had fun on intime sites (you know what I mean!) I made screenshot with using my program from your camera of yours device. After that, I jointed them to the content of the currently viewed site. Will be funny when I send these photos to your contacts! And if your relatives see it? BUT I'm sure you don't want it. I definitely would not want to ... I will not do this if you pay me a little amount. I think $814 is a nice price for it! I accept only Bitcoins. My BTC wallet: 1HQ7wGdA5G9qUtM8jyDt5obDv1x3vEvjCy If you have difficulty with this - Ask Google "how to make a payment on a bitcoin wallet". It's easy. After receiving the above amount, all your data will be immediately removed automatically. My virus will also will be destroy itself from your operating system. My Trojan have auto alert, after this email is looked, I will be know it! You have 2 days (48 hours) for make a payment. If this does not happen - all your contacts will get crazy shots with your dirty life! And so that you do not obstruct me, your device will be locked (also after 48 hours) Do not take this frivolously! This is the last warning! Various security services or antiviruses won't help you for sure (I have already collected all your data). Here are the recommendations of a professional: Antiviruses do not help against modern malicious code. Just do not enter your passwords on unsafe sites! I hope you will be prudent. Bye.
Zdravstvujte Vas interesuet parsing kontaktov?
Zdravstvujte Vas interesuet parsing kontaktov?
Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
Zdravstvujte Vas interesuyut klientskie bazy dannyh?
Zdravstvujte Vas interesuyut klientskie bazy dannyh?
Zdravstvujte Vas interesuyut klientskie bazy dannyh?
Zdravstvujte Vas interesuyut klientskie bazy dannyh?
Zdravstvujte Vas interesuyut bazy dannyh dlya prodazhi Vashih tovarov i uslug?
Zdravstvujte Vas interesuyut bazy dannyh dlya prodazhi Vashih tovarov i uslug?
Клиентскиe базы Email:tsemnolutskytsemnol...@gmail.com skype: rwer.wqerq ICQ: 446444644 Собeрeм для Вac koнтakты тoльko Baших потенциальныx клиентов нecкoльko дecятkoв тысяч мeнee чeм за сутkи
Клиентскиe базы Email:tsemnolutskytsemnol...@gmail.com skype: rwer.wqerq ICQ: 446444644 Собeрeм для Вac koнтakты тoльko Baших потенциальныx клиентов нecкoльko дecятkoв тысяч мeнee чeм за сутkи -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Клиентские базы Тел +79133913837 Email: nonen2...@gmail.com Узнайте подробнее!!!
Соберем для Вас по интернет базу данных потенциальных клиентов для Вашего Бизнеса! По базе можно звонить писать слать факсы и email, вести любые прямые активные продажи Ваших товаров и услуг! Узнайте подробнее по Тел +79133913837 Email: nonen2...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Klientskie Bazy http://prodawez.tilda.ws/page7270311.html
Klientskie Bazy http://prodawez.tilda.ws/page7270311.html
Klientskie Bazy http://prodawez.tilda.ws/page7270311.html
Klientskie Bazy http://prodawez.tilda.ws/page7270311.html
[no subject]
Здравствуйте! Вас интересуют клиентские базы данных?
[no subject]
Здравствуйте! Вас интересуют клиентские базы данных?
[no subject]
Здравствуйте! Вас интересуют клиентские базы данных?
Zdravstvujte vas interesuyut klientskie bazy dannyh?
Zdravstvujte vas interesuyut klientskie bazy dannyh?
Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
Здравствуйте! Вас интересуют клиентские базы данных?
Здравствуйте! Вас интересуют клиентские базы данных?
Zdravstvujte! Vas interesuyut klientskie bazy dannyh?
Zdravstvujte! Vas interesuyut klientskie bazy dannyh?
Zdravstvujte! Vas interesuyut klientskie bazy dannyh?
Zdravstvujte! Vas interesuyut klientskie bazy dannyh?
Zdravstvujte! Vas interesuyut klientskie bazy dannyh?
Zdravstvujte! Vas interesuyut klientskie bazy dannyh?
Клиентские базы! Email: proda...@armyspy.com Узнайте подробнее!
Клиентские базы! Email: proda...@armyspy.com Узнайте подробнее!
Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
Клиентские базы! Email: proda...@armyspy.com Узнайте подробнее!
Клиентские базы! Email: proda...@armyspy.com Узнайте подробнее!
Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
Клиентские базы! Email: proda...@armyspy.com Узнайте подробнее!
Клиентские базы! Email: proda...@armyspy.com Узнайте подробнее!
Клиентские базы! Email: proda...@armyspy.com Узнайте подробнее!
Клиентские базы! Email: proda...@armyspy.com Узнайте подробнее!
Клиентские базы! Email: proda...@armyspy.com Узнайте подробнее!
Клиентские базы! Email: proda...@armyspy.com Узнайте подробнее!
Klientskie bazy. Email: proda...@armyspy.com Uznajte podrobnee!
Klientskie bazy. Email: proda...@armyspy.com Uznajte podrobnee!
Klientskie bazy. Email: proda...@armyspy.com Uznajte podrobnee!
Klientskie bazy. Email: proda...@armyspy.com Uznajte podrobnee!
Здравствуйте! Вас интересуют клиентские базы данных?
Здравствуйте! Вас интересуют клиентские базы данных?
VAS INTERESUYUT BAZY DANNYKH? - YOU ARE INTERESTED IN DATABASES?
VAS INTERESUYUT BAZY DANNYKH? - YOU ARE INTERESTED IN DATABASES?
Your Secret Life
Hello! I'm a member of an international hacker group. As you could probably have guessed, your account linux-kernel@vger.kernel.org was hacked, I sent message you from it. Now I have access to you accounts! You still do not believe it? So, this is your password: qwerty , right? Within a period from July 5, 2018 to September 21, 2018, you were infected by the virus we've created, through an adult website you've visited. So far, we have access to your messages, social media accounts, and messengers. Moreover, we've gotten full damps of these data. We are aware of your little and big secrets...yeah, you do have them. We saw and recorded your doings on porn websites. Your tastes are so weird, you know.. But the key thing is that sometimes we recorded you with your webcam, syncing the recordings with what you watched! I think you are not interested show this video to your friends, relatives, and your intimate one... Transfer $700 to our Bitcoin wallet: 1DzM9y4fRgWqpZZCsvf5Rx4HupbE5Q5r4y I guarantee that after that, we'll erase all your "data" :D A timer will start once you read this message. You have 48 hours to pay the above-mentioned amount. Your data will be erased once the money are transferred. If they are not, all your messages and videos recorded will be automatically sent to all your contacts found on your devices at the moment of infection. You should always think about your security. We hope this case will teach you to keep secrets. Take care of yourself.
Клиентские базы +79139230330 Skype: prodawez390 Email: prodawez...@gmail.com Узнайте подробнее!
Клиентские базы +79139230330 Skype: prodawez390 Email: prodawez...@gmail.com Узнайте подробнее!
Клиентские базы +79139230330 Skype: prodawez390 Email: prodawez...@gmail.com Узнайте подробнее!
Клиентские базы +79139230330 Skype: prodawez390 Email: prodawez...@gmail.com Узнайте подробнее!
DO NOT TAKE THIS FOR GRANTED!!!
Goodday I think you will not be happy, because I have a very bad news for you. Just a few months ago I hacked your operating system and I have full control of your device. I implanted a small application into your device which sends me your current IP address and allows me to connect to your device just like remote desktop. Even if you change your password, it won’t help. How I infected you? The router that you used to connect to Internet had a security hole. You can read about this problem by searching for CVE-2018-10562. I hacked your router and I put my code into it, and when you tried to connect to Internet, my program infected your device. Later I made a full copy of your hard drive (I have all your email contact lists, list of websites you visited, phone numbers, your passwords etc.) A little while later, when I was searching your web browsing history I was shocked by what I saw!! The sites for adults you are visiting... you know what I mean... I just want to say - your fantasies are shifted far away from the normal course!... For months I have been spying on you through your device camera.. especially when you visited those sites to have fun...Those videos show clearly you having fun and the content for adults you were watching.. this is pretty nasty and I would be very worried if I were you. I have secured 2 videos: linux-kernel@vger.kernel.org_1557074047.mp4 (119.1 MB) linux-kernel@vger.kernel.org_1555285697.mp4 (64.5 MB) You can verify that the timestamps correspond to the moments you were enjoying yourself...Now, because I do not like at all what I saw (that’s pretty crazy and ugly) I ask you to send me a donation through Bitcoin network. 2000 US dollars is a fair price (considering your perversions). If you want me to forget about the whole case, remove the files and disable the nasty app that is spying you, send me the Bitcoin payment within 72 hours. Yes, I give you 72 hours only. Here is my wallet: === Send exactly 0.291578 BTC to my address: 1JiE6YXy2rvZJfVb1E3JnSCdEjmgKqUkm5 (copy it and paste - it’s case sensitive) === 0.291578 BTC = 2000 dollars If you do not send me the Bitcoin, I promise you - I will send those 4 files with you enjoying yourself to all your contact lists, associates and social network friends. I still have access to your device and I know when you read this message. When you opened it, time started ticking. You have 72 hours only! I am from Russia and nobody will help you if you report this email.. Before they find me your life will be ruined! If you do not cooperate with me - I will release this ugly material immediately. This is why I advise you - send me the Bitcoin and let’s forget about the whole situation. I know you can afford it. If you do not know how to send bitcoin Step 1: Create an account on www.localbitcoins.com Step 2: Buy 0.291578 BITCOIN Step 3: Send the amount on this BTC address: 1JiE6YXy2rvZJfVb1E3JnSCdEjmgKqUkm5 Step 4: Contact me on this email address chanblog...@aol.com with this subject: 980VIPERMARVO-RESTOREKEYPC00765 After this steps you will receive through email the key and a decrypt tutorial. Here is another list where you can buy bitcoin: https://bitcoin.org/en/exchanges Here is my address again: === Send exactly: 0.291578 BTC to my address: 1JiE6YXy2rvZJfVb1E3JnSCdEjmgKqUkm5 === Remember to send the exact amount as above! This way I will know it’s from you. Do not be angry at me. This is just my job, and you are not the only person I caught. Be angry at your fantasies - if you didn’t visit those sites for adults you would have no problem.. but now... I am waiting for your bitcoin. Remember, time is ticking..
Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
[no subject]
73233.doc Description: MS-Word document
Linux "Kernel" Explorer
http://openvldhamme.vldhamme.be/heah/suyiar.yiptaphgbpigczriyjy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc-2.95.2-51 is buggy
> > Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs > > gcc version 2.95.2 19991024 (release) > > % /usr/bin/gcc -Wall -O2 -o bug bug.c; ./bug > > 0x8480 > > % /usr/gcc/aeb/bin/gcc -v > > Reading specs from /usr/gcc/aeb/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs > > gcc version 2.95.2 19991024 (release) > > % /usr/gcc/aeb/bin/gcc -Wall -O2 -o nobug bug.c; ./nobug > > 0x0 > > > > So, not all versions of gcc 2.95.2 are equal. > > Interesting. Plain vanilla 2.95.2 from ftp.gnu.org exhibits the same > bug on an BSDI2.1 i386 system. > > defiant ~/tmp$ gcc -v > Reading specs from /usr/local/gnu/lib/gcc-lib/i386-pc-bsdi2.1/2.95.2/specs > gcc version 2.95.2 19991024 (release) > defiant ~/tmp$ gcc -O2 -o bug bug.c; ./bug > 0x480 > > Ion > Don't know if anyone else has noticed this but from what I've seen posted it appears, unless I missed something, the gcc 2.95.2s that have exibited the bug were compiled for a 386 or a 486 while the one on which it worked was a 686. Perhaps the bug only appears on certain gcc configurations. Either the build configuration or the default optimization method(s), if I remember correctly gcc optimizes for the platform (i.e. i386, i486, i586, etc) it was configured for by default. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Phantom PS/2 mouse persists..
- Original Message - From: "Steven N. Hirsch" <[EMAIL PROTECTED]> To: "Jeff V. Merkey" <[EMAIL PROTECTED]> Cc: "Alan Cox" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, December 03, 2000 5:42 PM Subject: Re: Phantom PS/2 mouse persists.. > On Sun, 3 Dec 2000, Jeff V. Merkey wrote: > > > > On Sun, Dec 03, 2000 at 06:27:52PM +, Alan Cox wrote: > > > > > > > > I've fixed the major case. I can see no definitive answer to the other ghost > > > > PS/2 stuff (except maybe USB interactions). I take it like the others 2.4test > > > > also misreports a PS/2 mouse being present. > > > > > > > > Anyway I think its no longer a showstopper for 2.2.18. Someone with an affected > > > > board can piece together the picture > > > I just tested 2.2.18-24 as a boot kernel with anaconda -- works great -- > > mouse problem on PS/2 system is nailed. > > I always seem to own the wierd hardware. I agree the mouse > mis-detection isn't a showstopper - just damn annoying. > > FWIW, USB isn't compiled into the kernel in question. > Definately could be your hardware. I once saw a 486 board (PcChips M571 I think) which would report a PS/2 mouse even though the port didn't even exist on the motherboard. This problem showed up on all versions of Win9x. >From what I could tell it appeared as if the BIOS had support for the PS/2 mouse port but the port pins themself had not been saudered onto the board and for some reason the board alway thaught it had a PS/2 mouse and reported as so to Windows. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Criticism] On the discussion about C++ modules
Wasn't the original complaint that the kernel headers use C++ keyword and thus prevent the writing of, at least some, modules in C++. I have written C++ code before that was as least as fast as comparable C code and more efficient in some ways. Whether this could be or not be reproduced in kernel code I do not know. So far I have done my kernel programming in C. However even if I or other programmers would like to give this a try it is my understanding we cannot because of the header situation. I think it is unfair to attack C++ kernel code that is unable to come into existence, at least without jumping through a bunch of hoops, due to external influences (i.e. the incompatible headers). On a separate note. Isn't one of the philosophies behind Linux the idea of freedom. If people wish to try and program their modules in C++ for whatever reason, be it porting from existing code or to object orient their code, should they be free to do so. If the header situation is true, which I am not sure of since I have not tried to do C++ programming in kernel code, then people aren't free to write modules however they wished. Seeing as fixing the headers should be rather trivial and probably is the right thing to do anyway (using existing language keywords is a bad idea) I do not see why this same flame war must erupt every time the header situation is brought up. Its not as if C++ code would all of the sudden popup in the kernel core forcing everybody to use C++. At best a driver here and there might start using it and its continual usage would depend on if its implementation is successful or not. And those drivers themselves are extremely likely to be self-contained thus not affecting anybody else's kernel code. > If C++ really is that good for kernel modules, I'd like to > see some code that proves it can be done without too much > of a performance hit (or without a performance hit at all?). > > Sending 500 rants to the kernel list isn't even close to > being productive. Sending 1 patch is... > > regards, > > Rik > -- > "What you're running that piece of shit Gnome?!?!" >-- Miguel de Icaza, UKUUG 2000 > > http://www.conectiva.com/ http://www.surriel.com/ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Possible C++ safe header project - Re: [Criticism] On the discussion about C++ modules
OK I've decided to give this a shot, IF there is sufficient interest out
there for C++ safe headers. So all you coders out there who have tried and
failed or who wish to program kernel modules in C++ join in and help out by
listing the errors you have encountered with the current header setup.
This is currently what I plan to do to make safe headers.
1. Insert
#ifdef __cplusplus
extern "C" {
#endif
at the begining of each header file and
#ifdef __cplusplus
}
#endif
at the end of each header file.
2. In the files which contain the usable of C++ keywords I intend to use
define statements such as the one below for the offending keywords:
#ifdef __cplusplus
#define class lk_class
#defined new lk_new
..
#endif
A side effect of this is that certain kernel variables make have to be
accessed in a C++ module with a new lk_ prefix. However C code will not be
affected. I don't like the idea of using the define statements especially
after seeing the horror Palm did in their SDK however I cannot think of
another way to transparently fix this unless the offending header code is
self contained. If anyone has a better idea let me know.
3. Add a new header for C++ modules that currently only include definitions
for the new and delete operator functions. This should be simple enougth.
Basically map new to kmalloc and delete to kfree. new will be a
non-exception version that returns NULL on error just like it used to do
before the horrible new C++ standard. I'm not even going to go near
exceptions as that IMHO creates non-clear and hard to debug execution paths
in code.
Please comment on the pluses and minuses of each planned task and on
other things that you may see that should be done. Please no flames unless
they contain useful information. Also I plan to implement the first patches
for 2.2.x. I prefer to work on a stable codebase at least while the project
gets off the ground. The other thing I'd like to know if the eventual
patch, if there is any as this is dependant on interest, would be considered
for inclusion into the standard source base.
Let the games begin.
> The "incompatible headers" can be cured mostly with just:
>
> extern "C" {
> #define new header_new
> #define ...
> #include
> #undef new
> #undef ...
> }
>
> If they can't go this far, or create a local patch for the offending
> headers (perhaps even suggesting it for inclusion) I don't see why they
> should even be considered, not to mention taken seriously...
>
> Fix it, send in a patch and get over it. Given your email address, this
> should be a no-brainer for you. At the very least, such a patch will
> (hopefully) stop this nonsense.
>
> > Its not as if C++ code would all of the sudden popup in the
> > kernel core forcing everybody to use C++. At best a driver here and
there
> > might start using it and its continual usage would depend on if its
> > implementation is successful or not. And those drivers themselves are
> > extremely likely to be self-contained thus not affecting anybody else's
> > kernel code.
>
> I'd prefer the kernel staying plain C, with no admixtures. Just MHO, of
> course. What somebody else does in the privacy of their own trees is their
> bussiness, as always.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Linux C++ safe header project
Hi all,
I'm looking through the suggestions and stuff that I have gotten so far.
As for the extern "C" stuff I'm torn between fixing the headers internally
or making side-by-side header files for C++ users. Such as:
a.h exists. So I create a a.hpp which contains somthing like the following:
a.hpp:
#ifndef __A_HPP__
#define __A_HPP__
#ifdef __cplusplus
extern "C" {
#endif
#include "a.h"
#ifdef __cplusplus
}
#endif
#endif
I'm not crazy about the second approach but open to it if the other one is
considered too intrusionary, a statement which I question considering the
$ifdef's leave the headers unchanged for C code.
As a first step in the project I've create a program that can be used to
update all the header files to include
#ifdef __cplusplus
extern "C" {
#endif
at the begining of each header file and
#ifdef __cplusplus
}
#endif
at the end of each header file. Said program is attached. Testers have
fun.
Note: this is only the first step to C++ safe header files. So please no
complaits about the C++ keywords. They still remain, for now.
- A. B.
begin 666 mkcppsaf.pl
M(R$O=7-R+V)I;B]P97)L"B,@4')O9W)A;2!N86UE.B!M:V-P<'-A9BYP; HC
M(%!R;V=R86UM960@:6XZ(%!E3H@
M02X@0BX*(R!0=7)P;W-E.B!4:&ES('!R;V=R86T@9FEX97,@0R!H96%D97(@
M9FEL97,@9F]R($,K*R!B>2!P;&%C:6YG(&%N(&5X=&5R;B B0R(*(R @(" @
M(" @("!W#H@;6MC<'!S868@6V1I
M"]I;F-L=61E+PH*
M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,*"B,)"0E);F-L
M=61E(')E<75I&ET*&UA:6XH0$%21U8I*3L*"B,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C"@HC"0D)36%I;B!P2 D9&ER(#T@*&EN="A 05)'5BD@
M/B P*2 _("1!4D=66S!=(#H@(B]U7!E(&8@+7!R:6YT('PB*2DI"@E["@D)
M4U1$15)2+3YP&EN9SH@)7,N+BXB+" D9FYA;64I.PH*"0EI9BAU<&1A=&5?
M9FEL92@D9FYA;64I(#T](# I"@D)>PH)"0EP2 H)&9N86UE*2 ]($!?.PH);7D@)&1A=&$@/2 B(CL*"6UY("1F:6QE
M(#T@;F5W($9I;&5(86YD;&4["@H):68H(61E9FEN960H)&9I;&4M/F]P96XH
M)&9N86UE+"!/7U)$3TY,62DI*0H)>PH)"5-41$524BT^<')I;G1F*")5;F%B
M;&4@=&\@;W!E;B!F:6QE("5S.B E7-T96TH
Need info on the use of certain datastructures and the first C++ keyword patch for 2.2.17
Hi all,
After a delay on some other project I've again started up the process of
fixing up the Linux headers, i.e. removing the use of C++ keywords as
variable and stuff. I have questions on the use of three datastructures
which happen to use the C++ keyword new but first a couple of things.
First thing. Some had commented on my previous post that this did not
belong on the Linux kernel mailing list. I disagree with that assertion.
The goal of this project is to clean up the kernel headers so as they are
useable/compatible with those who wish to program their kernel modules in
C++. It is not my goal to rewrite the kernel in C++ or anything like that,
merely to give those interested the option to program their modules in C++.
In order to accomplish this goal I may occasionally need to ask the various
kernel gods on this list whether changing a particular variable or structure
member name would cause a problem as I am also doing in this post. The
other reason I am posting, occasionally, on this list is to hopefully get
eyeballs and testers, from among those whom are most intimately familiar
with the kernel, to tryout my latest patch. And as a final note to some of
those whom responded negatively to my previous post I did not start the
previous flame war nor did I post a ton of messages. My previous posts on
the subject totaled 1 before I accepted someone's challenge to fix the
headers myself and since then I've only posted twice once to announce the
project and once with a script that would allow those interested to update
their header files with the 'extern "C" {}' compile conditional wrappers as
the starting point of the project. Any future posts will be limited to more
header fixes and/or questions on certain pieces of code I am looking to
modify. If and when I decide to start experimental kernel C++ projects such
as perhaps a generic virtual device driver classes that can be inheritable,
which by the way is not even near to my current goal, I will take those off
this list unless a question is required on the use of a particular data
structure or interface. And before the flames begin again I restate my
current goal is to fix the headers so they are useable in C++ and nothing
more.
Ok now the second thing I wish to announce in this post is that the
included C++ compatible header fixing patch fixes most references of the C++
keyword of "new" in the header files. The following files have been
updated. A couple of C files had to be updated as well due to parameters,
defined in the header files, being called "new". All of these were
straightforward fixes and should be correct, testing is welcome.
include/linux/arch/mips/kernel/irq.c
include/linux/include/asm-mips/irq.h
include/linux/include/asm-mips/mipsregs.h
include/linux/include/Linux/hdlcdrv.h
include/linux/include/Linux/list.h
include/linux/include/Linux/lists.h
include/linux/include/net/neighbour.h
include/linux/net/core/neighbour.c
Ok now on to the questions I have. In include/linux/joystick.h,
include/linux/raid5.h, and include/linux/adfs_fs.h I've found members of
structures and a union which were called "new". The datastructures in
question are union adfs_dirtail::new, struct stripe_head::new, struct
js_dev::new. My questions are basically this. If I update these data
structure members' names along with the references to them in various C
files in the kernel will all be happy in Linuxland. Can any external
utilities be broken or anything like that. Or more precisely are there any
known external utilities that would be broken by this change? Thanks to all
those whom can give me a hand in this.
- A. B.
begin 666 c++-0.0.1.patch
M9&EF9B M"TR+C(N,3PH@"6EN="!S:&%R960@/2 P.PH@"7-T"]I;F-L=61E+V%S
M;2UM:7!S+VER<2YH"BTM+2!L:6YU>"TR+C(N,3"]I;F-L=61E+V%S;2UM:7!S+VER<2YH"4UO;B!/8W0@,S @,#$Z,C@Z,C<@
M,C P, I 0" M,3"]I;F-L=61E+V%S;2UM:7!S+VUI<'-R
M96=S+F@)36]N($]C=" S," P,3HR.#HR-R R,# P"D! ("TQ-C$L,3,@*S$V
M,2PQ,R! 0 H@("HO"B C9&5F:6YE(%]?0E5)3$1?4T547T-0,"AN86UE+')E
M9VES=&5R*2 @(" @(" @(" @(" @(" @(" @(" @(" @7 H@97AT97)N(%]?
M:6YL:6YE7U\@=6YS:6=N960@:6YT(" @(" @(" @(" @(" @(" @(" @(" @
M(" @(" @(" @(%P*+7-E=%]C<#!?(R-N86UE*'5NR @(" @(" @(" @(" @(" @(" @(" @(" @(" @
M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(%P*( EU;G-I9VYE
M9"!I;G0@"]I;F-L=61E+VQI;G5X+VAD;&-DPHK"6EF("AI"TR+C(N,3"TR+C(N,3"]L:7-T+F@)36]N($]C=" S," P,3HR
M.#HR-B R,# P"D! ("TS,"PR,B K,S L,C(@0$ *(" J(%1H:7,@:7,@;VYL
M>2!F;W(@:6YT97)N86P@;&ES="!M86YI<'5L871I;VX
Recommended compiler? - Re: [patch] kernel/module.c (plus gratuitous rant)
So which is the recommended compiler for each kernel version 2.2.x, 2.4.x(pre?) nowadays? I've pretty much kept gcc 2.7.2.3 around just for compiling the kernel however now I hear you need egcs to compile 2.4? I don't mind keeping 2.7.2.3 around in its own installation directory just for the purpose of doing kernel work however from a previous post I've now got the impression that egcs has become the recommended compiler? If I'm going to keep a secondary compiler around (outside of gcc 2.95.2 which I still hear is no good for kernel compiles) just for kernel work I'd prefer to use my disk space on the recommended one. > > [Rusty] > > > CC=gcc-2723 make 2.0 kernel > > > CC=gcc-2723 make 2.2 kernel > > > CC=egcs make 2.4 kernel > > > > No, environment doesn't override make variables by default. This > > works on any shell: > > > > make CC=egcs > > If you're going to get pedantic, that won't work either -- since the > makefiles in kernels 2.0 and 2.2 expect $(CC) to include some compiler > flags. This was fixed somewhere in 2.3.3x. > > Peter > - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Need info on the use of certain datastructures and the first C++ keyword patch for 2.2.17
> > files in the kernel will all be happy in Linuxland. Can any external
>
> Why do you need to touch any existing kernel .c source file ? If you make
> that patch, this breaks "situation 1" above.
It doesn't break situation 1 as the minor changes I've made to those 2 C
files should not have changed any outputted code. The change was only in
the offending parameter names.
> AFAIK, ANSI C does not require that prototype (declaration) parameter
names and
> definition parameter names match, only types. So, this snippet is correct:
>
> int f(int onename);
>
> int f(int othername)
> {
> }
I think good style requires that the parameter names match in the
function prototype and its declaration. Besides which if I remember
correctly the latest C++ standard does require that the parameter names
match and the next C standard might follow suit. But I think that is a
minor issue, I only updated the C files (minimally at that) to keep
consistency.
> The "klass" example is directly taken from XFree header files, look at
> vi +239 /usr/X11R6/include/X11/Xlib.h
> vi +898 /usr/X11R6/include/X11/Xlib.h
>
> So the core X internals, written in C, use the "class" field, but anyone
using
> X in C++ programs has to use the field as "klass" or "c_class".
I bought up a solution like this before and it was mostly argued
against.
>
> I think X is a good example to provide C++ friendlyness with the minimal
> internal
> change. Perhaps this is a way to make kernel programmers-mantainers to
accept
> the
> headers patch, they can continue working the same...
The kernel gods will have to give their opinion on this. Should a
"proper" fix be implemented for the offending variable names or should a
workaround be implemented. Or perhaps a combination depending on whether
the change breaks any external utilities and how bad a break that is (I say
external utilities as I can update all the files in the kernel itself). I
am inclined to think that the proper fix should be done unless something
important break in which case the ugly workaround can be used in those
limited cases. However my mind is open to be changed. After all the ugly
workaround would actually be easier for me, one Perl script.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Need info on the use of certain datastructures and the first C++ keyword patch for 2.2.17
- Original Message -
From: "Alan Cox" <[EMAIL PROTECTED]>
To: "Linux Kernel Developer" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, October 30, 2000 8:04 AM
Subject: Re: Need info on the use of certain datastructures and the first
C++ keyword patch for 2.2.17
> > js_dev::new. My questions are basically this. If I update these data
> > structure members' names along with the references to them in various C
> > files in the kernel will all be happy in Linuxland. Can any external
>
> That may well be a problem. Also the use of private.
>
> You may find that creating your own wrappers for these files that do
>
> extern "C" {
> #define new new_
> #define private private_
> #include
> #undef new
> #undef private
> }
>
> safer, since you won't break anything
That was one of the two possible solutions I was looking at initially.
Having for example a module.hpp header file alongside module.h which did the
extern "C" {} wrapper along with the #define new lk_new, etc. Actually that
would be an easier task for me as I could easily write a Perl script which
automatically built that for any kernel. However from the responses I
gathered at the time it was mostly recommended against. I am also leary at
that option as some variable (and function?) names would differ when used in
either a C or C++ program and also after having seeing the horror Palm did
with defines in their SDK.
Perhaps this is what I should do. Continue making the straitforward
fixes that will not break anything and incorporate that into my main patch.
Fixes for situations such as the one I encountered in those 3 data
structures I will put into a separate patch for testing to see if the change
affects anybody. If those modifications happen prove unwise then for those
rare cases do the .hpp option on those header files.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Question on HighPoint HPT370 support
Hi, I was wondering if support for the HPT370 RAID capabilities is planned? I found that with the IDE patch from Hedrick I was able to get regular EIDE device support for this controller however I was hoping to use its RAID capabilities. Is work on this being done? Thanks for any help. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Why no HPT370 RAID Support?
Hi, I was just wondering if there was some reason why the HPT370's RAID capabilities weren't supported in the enhanced IDE patch for 2.2.*? Or if support for its RAID capabilities were being worked on. I noticed FreeBSD also appears to fail to support its RAID features so I am partially inclined into thinking that its RAID capabilities are done in software and thats why its RAID support hasn't been added. However from reading its specs on its web page it appears to be a hardware solution. Is it just a lack of documentation? Or will its RAID capabilities be added to Linux? Thanks for your help. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.6.11-mm3, mm4, usb, suspend 2 ram
--
Norbert Preining Università di Siena
sip:[EMAIL PROTECTED] +43 (0) 59966-690018
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
---
CHENIES (pl.n.)
The last few sprigs or tassels of last Christmas's decoration you
notice on the ceiling while lying on the sofa on an August afternoon.
--- Douglas Adams, The Meaning of Liff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Followup to previous post: Atlon/VIA Instabilities
> No, actually the instability starts right after/when the root > filesystem is mounted (it seems). I have no foreign modules installed > when this error occurs. Even if I did, why would the Abit KA7 with the > same [other] hardware and software NOT show this problem, even with all > opts enabled? In my experience I've noticed motherboards can have a huge impact on stability despite the chipsets, hardware used, etc. Abit is well known and liked in the overclocking circles, consequently I would strongly suspect that their motherboards are generally highly stable when compared to most others. In fact, my experience with them seams to support this thesis. Its possible that the other motherboard you were using is just flaky. Does the other one happen to be a PC-Chips one? These generally can be quite cheap, feature rich, and even have the best chipsets but still have proved themselves to be quite flaky to me in the past. FIC seams to have a similar problem, although they actually improve on their boards stability over time (have some rock solid high volume servers on "stabilized" FIC boards); sometimes with just a conveniently available BIOS update. Shuttle also seams to have gone downhill but that might have just been a one time occurrence. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Клиентские базы тел +79139230330 Skype: prodawez390 Whatsapp: +79139230330 Viber: +79139230330 Telegram: +79139230330 Email: nbiruko...@gmail.com Узнайте об этом подробнее!
Соберем для Вас по интернет базу данных контактов потенциальных клиентов для массовой продажи Ваших товаров и услуг в городе, стране или в мире. В базе - название, телефон, факс, местоположение, mail, имена руководителей или сотрудников итд Узнайте об этом подробнее! тел +79139230330 Skype: prodawez390 Whatsapp: +79139230330 Viber: +79139230330 Telegram: +79139230330 Email: nbiruko...@gmail.com Спасибо за быстрый ответ!
Клиентские базы bawupecoda-3...@courriel.fr.nf Skype: prodawez389 Подробности узнайте сейчас!
Соберем для Вас по интернет базу данных потенциальных клиентов для Вашего Бизнеса! В базе будут все контактные данные необходимые для массовой продажи Ваших товаров и услуг. По Вашему запросу пришлем пример и подробную информацию. Если интересно запросите подробности сейчас Email: bawupecoda-3...@courriel.fr.nf Skype: prodawez389 Благодарим за быстрый ответ!
КЛИЕНТCКИЕ БА3Ьl МАЙЛ:oqissavip-2...@speed.1s.fr CКАЙП: prodawez389 Для 6ысmpoй мАссoвoй npoдАжи ВАшиx moвАpoв и услуг! Пoдpo6нoсmи узнАйmе сейчАс!
Собeрeм gля Bac пo uнmернem бaзу данныx noтeнцuальныx kлиентов gля Baшегo Бизнeса! B 6азe буqyт вce koнтakmные qaнные нeо6xоgимые gля масcoвой проqажи Вaшuх mоваpов и yслyг. По Baшeму зaпроcy npишлем npuмep и noдpо6ную информацию. Если инmеpесно запpoсите подpо6нocmи ceйчас МAЙЛ: oqissavip-2...@speed.1s.fr CКAЙП: prodawez389 Блaгоqарим за 6ысmpый отвem
Klientskie bazi tel +79133913837 Email: lidiaakse...@gmail.com Клиентские базы тел +79133913837 Email: lidiaakse...@gmail.com
Клиентские базы тел +79133913837 Email: lidiaakse...@gmail.com Klientskie bazi tel +79133913837 Email: lidiaakse...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Klientskie bazi tel +79133913837 Email: lidiaakse...@gmail.com Клиентские базы тел +79133913837 Email: lidiaakse...@gmail.com
Клиентские базы тел +79133913837 Email: lidiaakse...@gmail.com Klientskie bazi tel +79133913837 Email: lidiaakse...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] platform/x86: pmc_atom: Match all Beckhoff Automation baytrail boards with critclk_systems DMI table
On Mo, 2021-04-12 at 12:43 +0300, Andy Shevchenko wrote:
>
> On Mon, Apr 12, 2021 at 12:29 PM Steffen Dirkwinkel
> wrote:
> >
> > From: Steffen Dirkwinkel
> >
> > pmc_plt_clk* clocks are used for ethernet controllers so need to stay
> > turned on. This adds the affected board family to critclk_systems DMI
> > table so the clocks are marked as CLK_CRITICAL and not turned off.
> >
> > This replaces the previosly listed boards with a match for the whole
>
> "...previously..."
thanks
>
> > device family. There are new affected boards that would otherwise need
> > to be listed. There are only few unaffected boards in the family and
>
> "...only a few..."
will drop the phrase
>
> > having the clocks turned on is not an issue on those.
>
> "...not an issue."
Not an issue for these industrial PCs as sleep is an unusual use case.
Having no ethernet after boot/sleep is worse.
>
> > Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
> > Signed-off-by: Steffen Dirkwinkel
>
> I'm afraid it's a bit too much. Is there any guarantee all the boards
> based on x86 will be Baytrail only?
>
Sorry, I guess I should make this clearer in the message.
All boards with "CBxx63" are Baytrail.
> --
> With Best Regards,
> Andy Shevchenko
>
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans
Beckhoff Registered office: Verl, Germany | Register court: Guetersloh HRA 7075
Re: [PATCH] platform/x86: pmc_atom: Match all Beckhoff Automation baytrail boards with critclk_systems DMI table
On Mo, 2021-04-12 at 13:54 +0300, Andy Shevchenko wrote:
> CAUTION: External Email!!
>
>
> On Mon, Apr 12, 2021 at 1:39 PM linux-kernel-dev
> wrote:
> > On Mo, 2021-04-12 at 12:43 +0300, Andy Shevchenko wrote:
> > > On Mon, Apr 12, 2021 at 12:29 PM Steffen Dirkwinkel
> > > wrote:
>
> ...
>
> > > I'm afraid it's a bit too much. Is there any guarantee all the boards
> > > based on x86 will be Baytrail only?
> > >
> > Sorry, I guess I should make this clearer in the message.
> > All boards with "CBxx63" are Baytrail.
>
> Exactly! And this supports my idea that this shouldn't be done like in
> this patch.
> Are you guaranteeing that *all x86-based* boards produced by your
> company will be Baytrail only?
> Above tells that the answer is rather "no". So, I think we can't apply
> this patch in its current form.
All boards with DMI_PRODUCT_FAMILY="CBxx63" are Baytrail boards. We do produce
other x86 boards but the family
is exclusive to Baytrail.
I might be misunderstanding how the matching works. Does this match anything
other than CBxx63?
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
DMI_MATCH(DMI_PRODUCT_FAMILY, "CBxx63"),
},
I can switch it to DMI_EXACT_MATCH but even substring matching works.
>
> --
> With Best Regards,
> Andy Shevchenko
>
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans
Beckhoff Registered office: Verl, Germany | Register court: Guetersloh HRA 7075
Re: [PATCH] ARM: dts: imx53: fix EIM_D27/29 pad UART2 configuration
From: Patrick Brünn On Tue, Dec 1, 2015 at 20:52:25 PST, shawn...@kernel.org wrote: > On Thu, Nov 26, 2015 at 11:59:15AM +0100, linux-kernel-...@beckhoff.com wrote: >> MX53_PAD_EIM_D27__UART2_RXD_MUX and MX53_PAD_EIM_D29__UART2_RTS input_val >> must be configured as 0 instead of 1 to have UART2 muxed on EIM pins working > > I'm not sure why you think that. But the i.MX53 Reference Manual in my hands > doesn't agree with that. It says ... >> >> Signed-off-by: Patrick Brünn >> --- >> arch/arm/boot/dts/imx53-pinfunc.h | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/arch/arm/boot/dts/imx53-pinfunc.h >> b/arch/arm/boot/dts/imx53-pinfunc.h >> index aec406b..a4c973d 100644 >> --- a/arch/arm/boot/dts/imx53-pinfunc.h >> +++ b/arch/arm/boot/dts/imx53-pinfunc.h >> @@ -532,7 +532,7 @@ >> #define MX53_PAD_EIM_D26__IPU_DISP1_DAT_22 0x144 0x48c >> 0x000 0x7 0x0 >> #define MX53_PAD_EIM_D27__EMI_WEIM_D_27 0x148 >> 0x490 0x000 0x0 0x0 >> #define MX53_PAD_EIM_D27__GPIO3_27 0x148 0x490 >> 0x000 0x1 0x0 >> -#define MX53_PAD_EIM_D27__UART2_RXD_MUX 0x148 >> 0x490 0x880 0x2 0x1 >> +#define MX53_PAD_EIM_D27__UART2_RXD_MUX 0x148 >> 0x490 0x880 0x2 0x0 > > IOMUXC_UART2_IPP_UART_RXD_MUX_SELECT_INPUT DAISY field descriptions > > 000 - Selecting Pad: EIM_D26 for Mode: ALT2. > 001 - Selecting Pad: EIM_D27 for Mode: ALT2. > 010 - Selecting Pad: PATA_DMARQ for Mode: ALT3. > 011 - Selecting Pad: PATA_BUFFER_EN for Mode: ALT3. > 100 - Selecting Pad: GPIO_7 for Mode: ALT4. > 101 - Selecting Pad: GPIO_8 for Mode: ALT4. Thanks for the hint. I had a closer look at the reference manual and our schematics. Of course, you are right. The defines are good as they are, my patch was stupid. I just realized RXD and TXD are inverted on our hardware (CX9020 Embedded PC). Which requires a pinmux configuration like this: EIM_D26->UART2_RXD EIM_D27->UART2_TXD EIM_D28->UART2_RTS EIM_D29->UART2_CTS In my opinion the reference manual allows such a configuration, but I am not sure if it's appropriate for mainline. Would you accept a patch like the following: >8--8< ARM: dts: imx53: add EIM pad config for UART2 Add another pinmux configuration to mux UART2 on EIM pads: EIM_D26->UART2_RXD EIM_D27->UART2_TXD EIM_D28->UART2_RTS EIM_D29->UART2_CTS Signed-off-by: Patrick Brünn --- arch/arm/boot/dts/imx53-pinfunc.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/imx53-pinfunc.h b/arch/arm/boot/dts/imx53-pinfunc.h index aec406b..7d26d16 100644 --- a/arch/arm/boot/dts/imx53-pinfunc.h +++ b/arch/arm/boot/dts/imx53-pinfunc.h @@ -525,6 +525,7 @@ #define MX53_PAD_EIM_D26__EMI_WEIM_D_260x144 0x48c 0x000 0x0 0x0 #define MX53_PAD_EIM_D26__GPIO3_26 0x144 0x48c 0x000 0x1 0x0 #define MX53_PAD_EIM_D26__UART2_TXD_MUX0x144 0x48c 0x000 0x2 0x0 +#define MX53_PAD_EIM_D26__UART2_RXD_MUX0x144 0x48c 0x880 0x2 0x0 #define MX53_PAD_EIM_D26__FIRI_RXD 0x144 0x48c 0x80c 0x3 0x0 #define MX53_PAD_EIM_D26__IPU_CSI0_D_1 0x144 0x48c 0x000 0x4 0x0 #define MX53_PAD_EIM_D26__IPU_DI1_PIN110x144 0x48c 0x000 0x5 0x0 @@ -532,6 +533,7 @@ #define MX53_PAD_EIM_D26__IPU_DISP1_DAT_22 0x144 0x48c 0x000 0x7 0x0 #define MX53_PAD_EIM_D27__EMI_WEIM_D_270x148 0x490 0x000 0x0 0x0 #define MX53_PAD_EIM_D27__GPIO3_27 0x148 0x490 0x000 0x1 0x0 +#define MX53_PAD_EIM_D27__UART2_TXD_MUX0x148 0x490 0x000 0x2 0x0 #define MX53_PAD_EIM_D27__UART2_RXD_MUX0x148 0x490 0x880 0x2 0x1 #define MX53_PAD_EIM_D27__FIRI_TXD 0x148 0x490 0x000 0x3 0x0 #define MX53_PAD_EIM_D27__IPU_CSI0_D_0 0x148 0x490 0x000 0x4 0x0 @@ -541,6 +543,7 @@ #define MX53_PAD_EIM_D28__EMI_WEIM_D_280x14c 0x494 0x000 0x0 0x0 #define MX53_PAD_EIM_D28__GPIO3_28 0x14c 0x494 0x000 0x1 0x0 #define MX53_PAD_EIM_D28__UART2_CTS0x14c 0x494 0x000 0x2 0x0 +#define MX53_PAD_EIM_D28__UART2_RTS0x14c 0x494 0x87c 0x2 0x0 #define MX53_PAD_EIM_D28__IPU_DISPB0_SER_DIO 0x14c 0x494 0x82c 0x3 0x1 #define MX53_PAD_EIM_D28__CSPI_MOSI0x14c 0x494 0x788 0x4 0x1 #define MX53_PAD_EIM_
[PATCH v2] clk: imx5: ipu_di_sel clocks can set parent rates
From: Patrick Brünn
To obtain exact pixel clocks, allow the DI clock selectors to influence
the PLLs that they are derived from.
Commit 4591b13289b5 ("ARM: i.MX6: ipu_di_sel clocks can set parent
rates") did this for i.MX6.
Port it to enable high display resolutions on i.MX53 based platforms
such as CX9020 Embedded PC, too.
Signed-off-by: Patrick Brünn
---
v2: add clk maintainers to CC and fix commit message format
drivers/clk/imx/clk-imx51-imx53.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/imx/clk-imx51-imx53.c
b/drivers/clk/imx/clk-imx51-imx53.c
index c677034..29d4c44 100644
--- a/drivers/clk/imx/clk-imx51-imx53.c
+++ b/drivers/clk/imx/clk-imx51-imx53.c
@@ -519,10 +519,10 @@ static void __init mx53_clocks_init(struct device_node
*np)
mx53_ldb_di0_sel,
ARRAY_SIZE(mx53_ldb_di0_sel), CLK_SET_RATE_PARENT);
clk[IMX5_CLK_LDB_DI0_GATE] = imx_clk_gate2("ldb_di0_gate",
"ldb_di0_div", MXC_CCM_CCGR6, 28);
clk[IMX5_CLK_LDB_DI1_GATE] = imx_clk_gate2("ldb_di1_gate",
"ldb_di1_div", MXC_CCM_CCGR6, 30);
- clk[IMX5_CLK_IPU_DI0_SEL] = imx_clk_mux("ipu_di0_sel",
MXC_CCM_CSCMR2, 26, 3,
- mx53_ipu_di0_sel,
ARRAY_SIZE(mx53_ipu_di0_sel));
- clk[IMX5_CLK_IPU_DI1_SEL] = imx_clk_mux("ipu_di1_sel",
MXC_CCM_CSCMR2, 29, 3,
- mx53_ipu_di1_sel,
ARRAY_SIZE(mx53_ipu_di1_sel));
+ clk[IMX5_CLK_IPU_DI0_SEL] = imx_clk_mux_flags("ipu_di0_sel",
MXC_CCM_CSCMR2, 26, 3,
+ mx53_ipu_di0_sel,
ARRAY_SIZE(mx53_ipu_di0_sel), CLK_SET_RATE_PARENT);
+ clk[IMX5_CLK_IPU_DI1_SEL] = imx_clk_mux_flags("ipu_di1_sel",
MXC_CCM_CSCMR2, 29, 3,
+ mx53_ipu_di1_sel,
ARRAY_SIZE(mx53_ipu_di1_sel), CLK_SET_RATE_PARENT);
clk[IMX5_CLK_TVE_EXT_SEL] = imx_clk_mux_flags("tve_ext_sel",
MXC_CCM_CSCMR1, 6, 1,
mx53_tve_ext_sel,
ARRAY_SIZE(mx53_tve_ext_sel), CLK_SET_RATE_PARENT);
clk[IMX5_CLK_TVE_GATE] = imx_clk_gate2("tve_gate", "tve_pred",
MXC_CCM_CCGR2, 30);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
URGENT MAIL FOR YOU...
Dear , My name is Mrs. Bella Holbrook and I work with the International Monetary Fund (IMF), I am writing you to let you know that finally your ATM Card worth $650,000.00 USD has been delivered through UPS to Mr. Hart Leroy, who works with the IMF where it is going to be activated before final delivery to your home address. You can use the tracking number with the tracking site below to track the ATM Card to be sure it has been delivered to Mr. Hart, for activation. UPS Tracking number: 1z2876490390947593 UPS tracking site: http://www.ups.com/index.html Below is the contact information to Mr. Hart Leroy Contact Name: Mr. Hart Leroy Contact E-mail: imfonlinedepart...@qq.com Contact Number: +1505-240-6112 You are to contact Mr. Hart with his email address above then he will guide you on how your Card will be activated and delivered to your home address. Note: The only fee you are to send for the activation fee is just $250 USD so make sure you don’t send him more than $250 USD. Your card is already with him and you can track it with the tracking details given to you above for confirmation. Congratulations once more. Best Regards, Mrs. Bella Holbrook International Monetary Fund (IMF) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Klientskie bazi Tel/Viber/WhatsApp +79133913837 Email: mamontova...@gmail.com Skype: prodawez389 ICQ: 6288862 FOTO ONLINE: http://media.xtwind.com/images/2015/10/19/2ba70554b12778c54b6a8ac82a7cc178.pn
Klientskie bazi Tel/Viber/WhatsApp +79133913837 Email: mamontova...@gmail.com Skype: prodawez389 ICQ: 6288862 FOTO ONLINE: http://media.xtwind.com/images/2015/10/19/2ba70554b12778c54b6a8ac82a7cc178.png -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
КЛИЕНТСКИЕ БАЗЫ! Тел\Viber\Whatsapp: +79139393506 Email: mnoskova...@gmail.com Skype: prodawez389
КЛИЕНТСКИЕ БАЗЫ! Соберем для Вас по интернет базу данных потенциальных клиентов для Вашего Бизнеса! Много! Быстро! Недорого! Узнайте об этом подробнее по Тел: +79139393506 Viber: +79139393506 Whatsapp: +79139393506 Skype: prodawez389 Email: mnoskova...@gmail.com
КЛИЕНТСКИЕ БАЗЫ! Тел\Viber\Whatsapp: +79133913837 Email: vavdee...@gmail.com Skype: prodawez389
КЛИЕНТСКИЕ БАЗЫ! Соберем для Вас по интернет базу данных потенциальных клиентов для Вашего Бизнеса! Много! Быстро! Недорого! Узнайте об этом подробнее по Тел: +79133913837 Viber: +79133913837 Whatsapp: +79133913837 Skype: prodawez389 Email: vavdee...@gmail.com
KЛИЕHТCKИЕ БАЗЬI! Тeл: +791З9З9З5Oб
КЛИЕHТСКИЕ БAЗЬI! Тел: +791З9З9З5oб
Клиентские базы тел +79139393506 (tеlеgгam_whatsaрр_vibег) Skype: prodawez389 Email: prodawez...@yandex.ru
Клиентские базы тел +79139393506 (tеlеgгam_whatsapp_vibег) Skype: prodawez389 Email: prodawez...@yandex.ru
Клиентские базы тел +79133913837 (tеlеgram_whatsapp_vibеr) Skype: prodawez389 Email: prodawez...@yandex.ru
Клиентские базы тел +79133913837 (tеlеgгam_whatsaрр_vibег) Skype: prodawez389 Email: prodawez...@yandex.ru
Klientskie bazi Tel/Viber/WhatsApp +79133913837 Email: gorskov...@gmail.com Skype: prodawez389 ICQ: 6288862 FOTO ONLINE: http://media.xtwind.com/images/2015/10/19/2ba70554b12778c54b6a8ac82a7cc178.png
Klientskie bazi Tel/Viber/WhatsApp +79133913837 Email: mamontova...@gmail.com Skype: prodawez389 ICQ: 6288862 FOTO ONLINE: http://media.xtwind.com/images/2015/10/19/2ba70554b12778c54b6a8ac82a7cc178.png -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
