Re: Oddness in i_shared_lock and page_table_lock nesting hierarchies ?
>I was looking into the vmm code and trying to work out exactly how to fix >this, and there are > some questions in my mind - mainly a few cases (involving multiple vma >updates) which > I'm not sure about the cleanest way to tackle. > But before I bother anyone with those, I thought I ought to go through >the earlier discussions > that you had while coming up with what the fix should be. Maybe you've >already gone over > this once. > Could you point me to those ? Somehow I haven't been successful in >locating them. this link might be useful http://mail.nl.linux.org/linux-mm/2000-07/msg00038.html Anil Kumar Prasad, Hardware Design, IBM Global Services, Pune, INDIA Phone:6349724 , 4007117 extn:1310 - 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: jiffies wrap question...
On Fri, Nov 10, 2000 at 02:21:28AM -0500, Jeff Garzik wrote: > The following is a piece of code from the latter half of > schedule_timeout, in kernel/sched.c. Is it possible that > schedule_timeout could return an incorrect value, if the jiffy value > wraps between the first and last lines shown below. let's say the first line happens n ticks before the wrap and the second, m ticks afterwards. > expire = timeout + jiffies; expire = timeout + 2^32/2^64 - n = timeout - n > timeout = expire - jiffies; timeout = expire - m = timeout - n - m = timeout - (n+m) (n+m) is the time that actually passed while we were asleep, and timeout has the correct value (timeout - ticks that happened)> - 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: [BUG] /proc//stat access stalls badly for swapping process,2.4.0-test10
On Thu, 9 Nov 2000, Linus Torvalds wrote: > > > As to the real reason for stalls on /proc//stat, I bet it has nothing > to do with IO except indirectly (the IO is necessary to trigger the > problem, but the _reason_ for the problem lies elsewhere). > > And it has everything to do with the fact that the way Linux semaphores > are implemented, a non-blocking process has a HUGE advantage over a > blocking one. Linux kernel semaphores are extreme unfair in that way. > > What happens is that some process is getting a lot of VM faults and gets > its VM semaphore. No contention yet. it holds the semaphore over the > IO, and now another process does a "ps". > > The "ps" process goes to sleep on the semaphore. So far so good. > > The original process releases the semaphore, which increments the count, > and wakes up the process waiting for it. Note that it _wakes_ it, it does > not give the semaphore to it. Big difference. > > The process that got woken up will run eventually. Probably not all that > immediately, because the process that woke it (and held the semaphore) > just slept on a page fault too, so it's not likely to immediately > relinquish the CPU. > > The original running process comes back faulting again, finds the > semaphore still unlocked (the "ps" process is awake but has not gotten to > run yet), gets the semaphore, and falls asleep on the IO for the next > page. > > The "ps" process actually gets to run now, but it's a bit late. The > semaphore is locked again. > > Repeat until luck breaks the bad circle. > > (This schenario, btw, is much harder to trigger on SMP than on UP. And > it's completely separate from the issue of simple disk bandwidth issues > which can obviously cause no end of stalls on anything that needs the > disk, and which can also happen on SMP). Unfortunately, it didn't help in the scenario I'm running. time make -j30 bzImage: real14m19.987s (within stock variance) user6m24.480s sys 1m12.970s procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 31 2 1 12 1432 4440 12660 0 1227 151 202 848 89 11 0 34 4 1 1908 2584536 5376 248 1904 602 763 785 4094 63 32 5 13 19 1 64140 67728604 33784 106500 84612 43625 21683 19080 52168 28 22 50 I understood the above well enough to be very interested in seeing what happens with flush IO restricted. -Mike [try_to_free_pages()->swap_out()/shm_swap().. can fight over who gets to shrink the best candidate's footprint?] Thanks! - 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/
jiffies wrap question...
The following is a piece of code from the latter half of schedule_timeout, in kernel/sched.c. Is it possible that schedule_timeout could return an incorrect value, if the jiffy value wraps between the first and last lines shown below. expire = timeout + jiffies; init_timer(); timer.expires = expire; timer.data = (unsigned long) current; timer.function = process_timeout; add_timer(); schedule(); del_timer_sync(); timeout = expire - jiffies; -- Jeff Garzik | Building 1024 | Would you like a Twinkie? MandrakeSoft| - 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: Oddness in i_shared_lock and page_table_lock nesting hierarchies ?
From: [EMAIL PROTECTED] Date:Thu, 9 Nov 2000 17:46:53 +0530 I was looking into the vmm code and trying to work out exactly how to fix this Let me save you some time, below is the fix I sent to Linus this evening: diff -u --recursive --new-file --exclude=CVS --exclude=.cvsignore vanilla/linux/include/linux/mm.h linux/include/linux/mm.h --- vanilla/linux/include/linux/mm.hThu Nov 9 21:43:46 2000 +++ linux/include/linux/mm.hThu Nov 9 20:16:04 2000 @@ -417,8 +417,11 @@ extern void swapin_readahead(swp_entry_t); /* mmap.c */ +extern void lock_vma_mappings(struct vm_area_struct *); +extern void unlock_vma_mappings(struct vm_area_struct *); extern void merge_segments(struct mm_struct *, unsigned long, unsigned long); extern void insert_vm_struct(struct mm_struct *, struct vm_area_struct *); +extern void __insert_vm_struct(struct mm_struct *, struct vm_area_struct *); extern void build_mmap_avl(struct mm_struct *); extern void exit_mmap(struct mm_struct *); extern unsigned long get_unmapped_area(unsigned long, unsigned long); diff -u --recursive --new-file --exclude=CVS --exclude=.cvsignore vanilla/linux/mm/filemap.c linux/mm/filemap.c --- vanilla/linux/mm/filemap.c Thu Nov 9 21:43:46 2000 +++ linux/mm/filemap.c Thu Nov 9 20:08:24 2000 @@ -1813,11 +1813,13 @@ get_file(n->vm_file); if (n->vm_ops && n->vm_ops->open) n->vm_ops->open(n); + lock_vma_mappings(vma); spin_lock(>vm_mm->page_table_lock); vma->vm_pgoff += (end - vma->vm_start) >> PAGE_SHIFT; vma->vm_start = end; - insert_vm_struct(current->mm, n); + __insert_vm_struct(current->mm, n); spin_unlock(>vm_mm->page_table_lock); + unlock_vma_mappings(vma); return 0; } @@ -1837,10 +1839,12 @@ get_file(n->vm_file); if (n->vm_ops && n->vm_ops->open) n->vm_ops->open(n); + lock_vma_mappings(vma); spin_lock(>vm_mm->page_table_lock); vma->vm_end = start; - insert_vm_struct(current->mm, n); + __insert_vm_struct(current->mm, n); spin_unlock(>vm_mm->page_table_lock); + unlock_vma_mappings(vma); return 0; } @@ -1870,15 +1874,17 @@ vma->vm_ops->open(left); vma->vm_ops->open(right); } + lock_vma_mappings(vma); spin_lock(>vm_mm->page_table_lock); vma->vm_pgoff += (start - vma->vm_start) >> PAGE_SHIFT; vma->vm_start = start; vma->vm_end = end; setup_read_behavior(vma, behavior); vma->vm_raend = 0; - insert_vm_struct(current->mm, left); - insert_vm_struct(current->mm, right); + __insert_vm_struct(current->mm, left); + __insert_vm_struct(current->mm, right); spin_unlock(>vm_mm->page_table_lock); + unlock_vma_mappings(vma); return 0; } diff -u --recursive --new-file --exclude=CVS --exclude=.cvsignore vanilla/linux/mm/mlock.c linux/mm/mlock.c --- vanilla/linux/mm/mlock.cFri Oct 13 12:10:30 2000 +++ linux/mm/mlock.cThu Nov 9 17:47:00 2000 @@ -36,11 +36,13 @@ get_file(n->vm_file); if (n->vm_ops && n->vm_ops->open) n->vm_ops->open(n); + lock_vma_mappings(vma); spin_lock(>vm_mm->page_table_lock); vma->vm_pgoff += (end - vma->vm_start) >> PAGE_SHIFT; vma->vm_start = end; - insert_vm_struct(current->mm, n); + __insert_vm_struct(current->mm, n); spin_unlock(>vm_mm->page_table_lock); + unlock_vma_mappings(vma); return 0; } @@ -61,10 +63,12 @@ get_file(n->vm_file); if (n->vm_ops && n->vm_ops->open) n->vm_ops->open(n); + lock_vma_mappings(vma); spin_lock(>vm_mm->page_table_lock); vma->vm_end = start; - insert_vm_struct(current->mm, n); + __insert_vm_struct(current->mm, n); spin_unlock(>vm_mm->page_table_lock); + unlock_vma_mappings(vma); return 0; } @@ -96,15 +100,17 @@ vma->vm_ops->open(left); vma->vm_ops->open(right); } + lock_vma_mappings(vma); spin_lock(>vm_mm->page_table_lock); vma->vm_pgoff += (start - vma->vm_start) >> PAGE_SHIFT; vma->vm_start = start; vma->vm_end = end; vma->vm_flags = newflags; vma->vm_raend = 0; - insert_vm_struct(current->mm, left); - insert_vm_struct(current->mm, right); + __insert_vm_struct(current->mm, left); + __insert_vm_struct(current->mm, right); spin_unlock(>vm_mm->page_table_lock); + unlock_vma_mappings(vma); return 0; } diff -u --recursive --new-file --exclude=CVS --exclude=.cvsignore vanilla/linux/mm/mmap.c linux/mm/mmap.c --- vanilla/linux/mm/mmap.c Fri Oct 13 12:10:30 2000 +++ linux/mm/mmap.c Thu Nov 9 17:53:02 2000 @@ -67,7 +67,7 @@ } /* Remove one vm structure from the inode's i_mapping address space. */
[i386] CPU detection cleanup version 2
I have produced another version of the CPU detection cleanup patch. Now I have ported over mtrr.c, and fix a small handful of places I had missed because of the configurations I had used. The number one thing I *haven't* yet done with it -- which I'd like to -- is to integrate the handling of bugs (except the P6 SEP bug) into the same framework and pretty much eliminate asm/bugs.h, as well as splitting off the CPU detection into a separate file. However, due to the very late stage in the game, I wanted to worry about things that are important for correctness for now. Please do keep in mind this is not merely a cosmetic change. The old code was rather shockingly klugy and incorrect in a number of places. A lot of problems I thought were AMD CPUID bugs were in fact caused by Linux trying to use the Intel-defined and the AMD-defined flags as interchangeable (they're not.) The patch is at: ftp://ftp.kernel.org/pub/linux/kernel/people/hpa/cpuid-2.4.0-test11-pre2-2.diff Please give me reports on works/not works with output from /proc/cpuinfo and the cpuid.c program (in the same directory as the patch.) -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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/
[patch] Re: test11-pre2 compile error undefined reference to `bust_spinlocks'
John Kacur wrote:
>
> When attempting to compile test11-pre2, I get the following compile
> error.
>
> arch/i386/mm/mm.o: In function `do_page_fault':
> arch/i386/mm/mm.o(.text+0x781): undefined reference to `bust_spinlocks'
> make: *** [vmlinux] Error 1
It was inside an ifdef. Apologies.
This patch against test11-pre2 moves it to fault.c.
--- linux-2.4.0-test11-pre2/arch/i386/kernel/traps.cFri Nov 10 15:59:15 2000
+++ linux/arch/i386/kernel/traps.c Fri Nov 10 15:52:40 2000
@@ -63,6 +63,7 @@
struct desc_struct idt_table[256] __attribute__((__section__(".data.idt"))) = { {0,
0}, };
extern int console_loglevel;
+extern void bust_spinlocks(void);
static inline void console_silent(void)
{
@@ -394,19 +395,7 @@
__setup("nmi_watchdog=", setup_nmi_watchdog);
-extern spinlock_t console_lock, timerlist_lock;
static spinlock_t nmi_print_lock = SPIN_LOCK_UNLOCKED;
-
-/*
- * Unlock any spinlocks which will prevent us from getting the
- * message out (timerlist_lock is aquired through the
- * console unblank code)
- */
-void bust_spinlocks(void)
-{
- spin_lock_init(_lock);
- spin_lock_init(_lock);
-}
inline void nmi_watchdog_tick(struct pt_regs * regs)
{
--- linux-2.4.0-test11-pre2/arch/i386/mm/fault.cFri Nov 10 15:59:15 2000
+++ linux/arch/i386/mm/fault.c Fri Nov 10 16:02:03 2000
@@ -24,7 +24,6 @@
#include
extern void die(const char *,struct pt_regs *,long);
-extern void bust_spinlocks(void);
/*
* Ugly, ugly, but the goto's result in better assembly..
@@ -76,6 +75,19 @@
bad_area:
return 0;
+}
+
+extern spinlock_t console_lock, timerlist_lock;
+
+/*
+ * Unlock any spinlocks which will prevent us from getting the
+ * message out (timerlist_lock is aquired through the
+ * console unblank code)
+ */
+void bust_spinlocks(void)
+{
+ spin_lock_init(_lock);
+ spin_lock_init(_lock);
}
asmlinkage void do_invalid_op(struct pt_regs *, unsigned long);
-
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: test11-pre2 compile error undefined reference to `bust_spinlocks'
On Fri, 10 Nov 2000 00:32:49 -0500,
John Kacur <[EMAIL PROTECTED]> wrote:
>When attempting to compile test11-pre2, I get the following compile
>error.
>
>arch/i386/mm/mm.o: In function `do_page_fault':
>arch/i386/mm/mm.o(.text+0x781): undefined reference to `bust_spinlocks'
>make: *** [vmlinux] Error 1
Oops, wrong patch.
Index: 0-test11-pre2.1/arch/i386/kernel/traps.c
--- 0-test11-pre2.1/arch/i386/kernel/traps.c Fri, 10 Nov 2000 13:10:37 +1100 kaos
(linux-2.4/A/c/1_traps.c 1.1.2.2.1.1.2.1.2.3.1.2.3.1.1.2 644)
+++ 0-test11-pre2.1(w)/arch/i386/kernel/traps.c Fri, 10 Nov 2000 16:06:48 +1100 kaos
+(linux-2.4/A/c/1_traps.c 1.1.2.2.1.1.2.1.2.3.1.2.3.1.1.2 644)
@@ -382,6 +382,18 @@ static void unknown_nmi_error(unsigned c
printk("Do you have a strange power saving mode enabled?\n");
}
+extern spinlock_t console_lock, timerlist_lock;
+/*
+ * Unlock any spinlocks which will prevent us from getting the
+ * message out (timerlist_lock is acquired through the
+ * console unblank code)
+ */
+void bust_spinlocks(void)
+{
+ spin_lock_init(_lock);
+ spin_lock_init(_lock);
+}
+
#if CONFIG_X86_IO_APIC
int nmi_watchdog = 1;
@@ -394,19 +406,7 @@ static int __init setup_nmi_watchdog(cha
__setup("nmi_watchdog=", setup_nmi_watchdog);
-extern spinlock_t console_lock, timerlist_lock;
static spinlock_t nmi_print_lock = SPIN_LOCK_UNLOCKED;
-
-/*
- * Unlock any spinlocks which will prevent us from getting the
- * message out (timerlist_lock is aquired through the
- * console unblank code)
- */
-void bust_spinlocks(void)
-{
- spin_lock_init(_lock);
- spin_lock_init(_lock);
-}
inline void nmi_watchdog_tick(struct pt_regs * regs)
{
-
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: test11-pre2 compile error undefined reference to `bust_spinlocks'
Keith Owens wrote:
> Index: 0-test11-pre2.1/arch/i386/kernel/traps.c
> --- 0-test11-pre2.1/arch/i386/kernel/traps.c Fri, 10 Nov 2000 13:10:37 +1100 kaos
>(linux-2.4/A/c/1_traps.c 1.1.2.2.1.1.2.1.2.3.1.2.3.1.1.2 644)
> +++ 0-test11-pre2.1(w)/arch/i386/kernel/traps.c Fri, 10 Nov 2000 15:56:54 +1100 kaos
>(linux-2.4/A/c/1_traps.c 1.1.2.2.1.1.2.1.2.3.1.2.3.1.1.2 644)
> @@ -382,6 +382,17 @@ static void unknown_nmi_error(unsigned c
> printk("Do you have a strange power saving mode enabled?\n");
> }
>
> +/*
> + * Unlock any spinlocks which will prevent us from getting the
> + * message out (timerlist_lock is acquired through the
> + * console unblank code)
> + */
> +void bust_spinlocks(void)
> +{
> + spin_lock_init(_lock);
> + spin_lock_init(_lock);
> +}
> +
> #if CONFIG_X86_IO_APIC
>
> int nmi_watchdog = 1;
> @@ -396,17 +407,6 @@ __setup("nmi_watchdog=", setup_nmi_watch
>
> extern spinlock_t console_lock, timerlist_lock;
> static spinlock_t nmi_print_lock = SPIN_LOCK_UNLOCKED;
Did you actually try this? You are moving bust_spinlocks above the
'extern spinlock_t' declarations intended for it.
My solution was to move the 'extern spinlock_t ...' also :)
Jeff
--
Jeff Garzik |
Building 1024 | Would you like a Twinkie?
MandrakeSoft|
-
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.4.0 console_loglevel cleanup
25 separate source files declare extern int console_loglevel, many of
them define console_silent() and console_verbose() - unclean, unclean!
The patch against 2.4.0-test11-pre2 removes all the duplicate
declarations and adds console_loglevel, console_silent() and
console_verbose() to include/linux/kernel.h. This is not important and
can wait for 2.4.[12], the only reason I am sending this out now is
because the patch hits multiple architectures.
Index: 0-test11-pre2.1/include/linux/kernel.h
--- 0-test11-pre2.1/include/linux/kernel.h Sat, 23 Sep 2000 11:16:56 +1100 kaos
(linux-2.4/Z/50_kernel.h 1.1.1.2 644)
+++ 0-test11-pre2.1(w)/include/linux/kernel.h Fri, 10 Nov 2000 15:19:40 +1100 kaos
+(linux-2.4/Z/50_kernel.h 1.1.1.2 644)
@@ -63,6 +63,19 @@ extern int session_of_pgrp(int pgrp);
asmlinkage int printk(const char * fmt, ...)
__attribute__ ((format (printf, 1, 2)));
+extern int console_loglevel;
+
+extern inline void console_silent(void)
+{
+ console_loglevel = 0;
+}
+
+extern inline void console_verbose(void)
+{
+ if (console_loglevel)
+ console_loglevel = 15;
+}
+
#if DEBUG
#define pr_debug(fmt,arg...) \
printk(KERN_DEBUG fmt,##arg)
Index: 0-test11-pre2.1/kernel/sysctl.c
--- 0-test11-pre2.1/kernel/sysctl.c Wed, 08 Nov 2000 11:52:15 +1100 kaos
(linux-2.4/j/21_sysctl.c 1.1.1.4.1.2.1.2 644)
+++ 0-test11-pre2.1(w)/kernel/sysctl.c Fri, 10 Nov 2000 15:02:08 +1100 kaos
+(linux-2.4/j/21_sysctl.c 1.1.1.4.1.2.1.2 644)
@@ -41,7 +41,7 @@
/* External variables not in a header file. */
extern int panic_timeout;
-extern int console_loglevel, C_A_D;
+extern int C_A_D;
extern int bdf_prm[], bdflush_min[], bdflush_max[];
extern int sysctl_overcommit_memory;
extern int max_threads;
Index: 0-test11-pre2.1/kernel/ksyms.c
--- 0-test11-pre2.1/kernel/ksyms.c Wed, 08 Nov 2000 11:52:15 +1100 kaos
(linux-2.4/j/29_ksyms.c 1.1.2.5.2.3.1.7.1.8.2.2 644)
+++ 0-test11-pre2.1(w)/kernel/ksyms.c Fri, 10 Nov 2000 15:02:47 +1100 kaos
+(linux-2.4/j/29_ksyms.c 1.1.2.5.2.3.1.7.1.8.2.2 644)
@@ -53,7 +53,6 @@
#include
#endif
-extern int console_loglevel;
extern void set_device_ro(kdev_t dev,int flag);
extern void *sys_call_table;
Index: 0-test11-pre2.1/init/main.c
--- 0-test11-pre2.1/init/main.c Fri, 27 Oct 2000 22:11:48 +1100 kaos
(linux-2.4/j/46_main.c 1.1.2.2.1.1.2.5.1.2.1.1.2.1.3.1 644)
+++ 0-test11-pre2.1(w)/init/main.c Fri, 10 Nov 2000 15:03:06 +1100 kaos
+(linux-2.4/j/46_main.c 1.1.2.2.1.1.2.5.1.2.1.1.2.1.3.1 644)
@@ -80,8 +80,6 @@ extern void nubus_init(void);
extern char _stext, _etext;
extern char *linux_banner;
-extern int console_loglevel;
-
static int init(void *);
extern void init_IRQ(void);
Index: 0-test11-pre2.1/include/asm-sh/page.h
--- 0-test11-pre2.1/include/asm-sh/page.h Tue, 03 Oct 2000 12:24:51 +1100 kaos
(linux-2.4/r/11_page.h 1.3 644)
+++ 0-test11-pre2.1(w)/include/asm-sh/page.h Fri, 10 Nov 2000 15:03:21 +1100 kaos
+(linux-2.4/r/11_page.h 1.3 644)
@@ -76,8 +76,6 @@ typedef struct { unsigned long pgprot; }
#ifndef __ASSEMBLY__
-extern int console_loglevel;
-
/*
* Tell the user there is some problem.
*/
Index: 0-test11-pre2.1/include/asm-i386/page.h
--- 0-test11-pre2.1/include/asm-i386/page.h Thu, 19 Oct 2000 11:08:42 +1100 kaos
(linux-2.4/P/20_page.h 1.4 644)
+++ 0-test11-pre2.1(w)/include/asm-i386/page.h Fri, 10 Nov 2000 15:23:18 +1100 kaos
+(linux-2.4/P/20_page.h 1.4 644)
@@ -82,8 +82,6 @@ typedef struct { unsigned long pgprot; }
#ifndef __ASSEMBLY__
-extern int console_loglevel;
-
/*
* Tell the user there is some problem. Beep too, so we can
* see^H^H^Hhear bugs in early bootup as well!
Index: 0-test11-pre2.1/fs/ntfs/fs.c
--- 0-test11-pre2.1/fs/ntfs/fs.c Thu, 19 Oct 2000 11:08:42 +1100 kaos
(linux-2.4/c/b/13_fs.c 1.1.1.1.1.7 644)
+++ 0-test11-pre2.1(w)/fs/ntfs/fs.c Fri, 10 Nov 2000 15:16:55 +1100 kaos
+(linux-2.4/c/b/13_fs.c 1.1.1.1.1.7 644)
@@ -935,8 +935,7 @@ static int __init init_ntfs_fs(void)
/* Comment this if you trust klogd. There are reasons not to trust it
*/
#if defined(DEBUG) && !defined(MODULE)
- extern int console_loglevel;
- console_loglevel=15;
+ console_verbose();
#endif
printk(KERN_NOTICE "NTFS version " NTFS_VERSION "\n");
SYSCTL(1);
Index: 0-test11-pre2.1/drivers/nubus/nubus.c
--- 0-test11-pre2.1/drivers/nubus/nubus.c Fri, 26 May 2000 13:10:01 +1000 kaos
(linux-2.4/o/b/27_nubus.c 1.1 644)
+++ 0-test11-pre2.1(w)/drivers/nubus/nubus.c Fri, 10 Nov 2000 15:04:09 +1100 kaos
+(linux-2.4/o/b/27_nubus.c 1.1 644)
@@ -27,8 +27,6 @@
extern void via_nubus_init(void);
extern void oss_nubus_init(void);
-extern int console_loglevel;
-
/* Constants */
/* This is, of course, the size in bytelanes, rather than the size in
Index: 0-test11-pre2.1/drivers/macintosh/via-macii.c
--- 0-test11-pre2.1/drivers/macintosh/via-macii.c Fri, 26 May 2000 13:10:01 +1000 kaos
(linux-2.4/p/b/9_via-macii. 1.1 644)
+++ 0-test11-pre2.1(w)/drivers/macintosh/via-macii.c
Re: test11-pre2 compile error undefined reference to `bust_spinlocks'
On Fri, 10 Nov 2000 00:32:49 -0500,
John Kacur <[EMAIL PROTECTED]> wrote:
>When attempting to compile test11-pre2, I get the following compile
>error.
>
>arch/i386/mm/mm.o: In function `do_page_fault':
>arch/i386/mm/mm.o(.text+0x781): undefined reference to `bust_spinlocks'
>make: *** [vmlinux] Error 1
Index: 0-test11-pre2.1/arch/i386/kernel/traps.c
--- 0-test11-pre2.1/arch/i386/kernel/traps.c Fri, 10 Nov 2000 13:10:37 +1100 kaos
(linux-2.4/A/c/1_traps.c 1.1.2.2.1.1.2.1.2.3.1.2.3.1.1.2 644)
+++ 0-test11-pre2.1(w)/arch/i386/kernel/traps.c Fri, 10 Nov 2000 15:56:54 +1100 kaos
+(linux-2.4/A/c/1_traps.c 1.1.2.2.1.1.2.1.2.3.1.2.3.1.1.2 644)
@@ -382,6 +382,17 @@ static void unknown_nmi_error(unsigned c
printk("Do you have a strange power saving mode enabled?\n");
}
+/*
+ * Unlock any spinlocks which will prevent us from getting the
+ * message out (timerlist_lock is acquired through the
+ * console unblank code)
+ */
+void bust_spinlocks(void)
+{
+ spin_lock_init(_lock);
+ spin_lock_init(_lock);
+}
+
#if CONFIG_X86_IO_APIC
int nmi_watchdog = 1;
@@ -396,17 +407,6 @@ __setup("nmi_watchdog=", setup_nmi_watch
extern spinlock_t console_lock, timerlist_lock;
static spinlock_t nmi_print_lock = SPIN_LOCK_UNLOCKED;
-
-/*
- * Unlock any spinlocks which will prevent us from getting the
- * message out (timerlist_lock is aquired through the
- * console unblank code)
- */
-void bust_spinlocks(void)
-{
- spin_lock_init(_lock);
- spin_lock_init(_lock);
-}
inline void nmi_watchdog_tick(struct pt_regs * regs)
{
-
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/
test11-pre2 compile error undefined reference to `bust_spinlocks'
Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit When attempting to compile test11-pre2, I get the following compile error. arch/i386/mm/mm.o: In function `do_page_fault': arch/i386/mm/mm.o(.text+0x781): undefined reference to `bust_spinlocks' make: *** [vmlinux] Error 1 John Kacur - 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: The IrDA patches !!! (+ more flames)
On Thu, Nov 09, 2000 at 07:24:04PM -0800, Jean Tourrilhes wrote: > > I spent my full day going through my archives and splitting > the big patch of Dag into lots of small patches (see attached). I'm > glad I've got a big hard drive full of junk. By the way, while I'm in flaming mode, could somebody tell ESR that this patch split (as well as most of the patches themselves) was sponsored by HP ? He should check his fact more carefully before jumping on his guns, he seem one of the few who haven't visited the Wireless LAN Howto... Now I can cool down... Jean - 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/
CPU detection revamp (Request for comments)
Hi guys, I wanted to give you a preview of the CPUID revision patch; it is not 100% ready yet in that (a) it still has a bunch of debugging printk() and (b) I haven't ported over mtrr.c yet. This code took a lot longer to write than I had expected, mostly because I kept running into various forms of bugs with the *old* code. In fact, it looks like some of the bugs involving CPUID feature flags in the past have been due to the inconsistent handling of these flags in Linux. I believe the new code should be a lot better in this aspect, and should avoid bugs as much as possible. I would very much like this code to be tested and get success/fail reports on various CPUs, *especially* AMD (Athlon especially) and Cyrix chips. As I mentioned, you will have to compile without MTRR support in this version. I should have that fixed soon. The patch is at: ftp://ftp.kernel.org/pub/linux/kernel/people/hpa/cpuid-2.4.0-test11-pre2-1.diff In case of success, please send me the output of the new /proc/cpuinfo on your system. In case of failure, please compile and run the following program and send me the output, as well as /proc/cpuinfo from an unpatched kernel version: ftp://ftp.kernel.org/pub/linux/kernel/people/hpa/cpuid.c Many thanks, -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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: [test11-pre2] rrunner.c compiler error
> rrunner.c : In function 'rr_ioctl' > rrunner.c:1558: label 'out' used but not defined > make[2]: *** [rrunner.o] Error 1 My fault. Swap that 1158 line pair error = -EPERM; goto out; with return -EPERM - 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 2.2.18pre21
Ok so the PS/2 bug is real and the megaraid mystery continues Anything which isnt a strict bug fix or previously agreed is now 2.2.19 material. Alan 2.2.18pre21 o Environment controller update for sparc (Eric Brower) o No italian translation for config.help (Andrea Ferraris) o Fix type error in buz driver(Pete Zaitcev) o Resnchronize Apple PowerMac codebase(Paul Mackerras & co) o Merge powermac tree fixes into usb o Powermac input device handling changes o Fix console switch fonts o S/390 merge (IBM S/390 folks) (Merge grunt work done by Kurt Roeckx) o Make knfsd TCP an option(me) o Drop cisco info packets (0x2000)(Ivan Passos) o Add belkin USB serial cable (William Greathouse) 2.2.18pre20 o Fix ide-probe SMP build error (Ian Morgan) o Fix appletalk physical layer ioctl handling (Andi Kleen) o Sparc update(Dave Miller) o Update Stephen Tweedie's contact info (Stephen Tweedie) o Fix typo in esp and scsi_obsolete code (Dave Miller) o Bonding ioctl check fix (Willy Tarreau) o Fix ipv6 procfs bug (Al Viro) o Report PIV in proc as family 15 and uname as(me) model 6 as discussed o Redo Intel cache decodes as code not tables (me) and add new ones (based on updates by Asit Mallick & Andrew Ip) o Fix CMOS locking in machine_power_off paths (me) o Create build tree symlinks only if insmod is new enough not to be confused by it (Keith Owens) o Fix cmsg handling (Philippe Troin) o Tiny xpds driver changes(Dan Hollis) o Fix vmalloc sign bug(Ben LaHaise) o SMBFS fixes/changes for find_next problems and (Urban Widmark) to avoid truncate bug in netapps o Fix ntfs translation bug(Anton Altaparmakov) o Fix sparc problem with some soundcards and the (Jeff Garzik) _IOC magic o Update ppa driver to v2.05 (Tim Waugh) 2.2.18pre19 o Fix transproxy socket lookup(Val Henson) o Add ICS1893 PHY to the SiS900 driver(Lei-Chun Chang) o Fix documentation error in matroxfb (Vsevolod Sipakov) o Update IDE floppy maintainer(Paul Bristow) o Fix remaining cmos locking (Paul Gortmaker) o Fix sparc bitfield/compiler bits on sound (Dave Miller) o Update Pegasus USB driver (Petko Manolov) o Networking updates - move divert header (Andi Kleen) o Add ETH_P_ATM* defines (Matti Aarnio) o Fix one more missing GFP_KERNEL/sk->allocation (Dave Miller) o Fix ISDN multilink handler bug (Kai Germaschewski) o Fix ymfpci unload cases (Kai Germaschewski) 2.2.18pre18 o Fix off by one in net/ipv4/proc (Dave Miller) o Move the fpu emu patch that got away(Dave Miller) o K6 update for MTRR ability (Dave Jones) o Fix raid1/vm deadlock (Marcelo Tosatti) o Fix usb mouse userspace memory accesses (David Woodhouse) o Fix xpdsl if compiled in (typo) (Arjan van de Ven) o Rio fixes for modem handling. Fix a small (Patrick van de Lageweg) generic serial bug o IBMtr driver fixes for cable pulls, pcmcia (Burt Silverman, behaviour etcMike Sullivan) o Tidy up /dev/microcode messages (Daniel Roesen) o Add arpfilter (Andi Kleen) o IDE floppy updates for clik support, cleanups (Paul Bristow) o Fix irongate handling on Alpha (Soohoon Lee) o Fix HZ=100 assumption in aha152x.c (me) o Fix power management handling in i810 audio (me) (From an ALSA fix by Godmar Back) o Put the NFS block default back to 4K(Trond Myklebust) o Fix misleading comment in printk code (Riley Williams) o Fix fbcon scroll back/paste bug (Herbert Xu) o Fix rtc_lock for ide-probe, and hd.c(Richard Johnson) o Backport of 2.4 PR_GET/SET_KEEPCAPS (Brian Brunswick) (from Chris Evans 2.4 code) o LRU list corruption fix (Andrea Arcangeli) o Initial gcc 2.96+ support for kernel building (H J Lu) | Not a
[test11-pre2] rrunner.c compiler error
Hello, I received the following error while compiling test11-pre2: rrunner.c : In function 'rr_ioctl' rrunner.c:1558: label 'out' used but not defined make[2]: *** [rrunner.o] Error 1 make[2]: Leaving directory '/usr/src/linux/drivers/net' ... make: ** [mod_drivers] Error 2 out is located in the file, so I'm assuming its a bracing issue. Regards, Frank - 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: test11-pre2
Linus Torvalds wrote: > > Nothing stands out as affecting most people here. Security fix for /proc, > and various cleanups. Alpha and sparc fixes. If you use RAID or ramdisk, > upgrade. > > Linus > Only four level I's. Pretty good. PCMCIA problems fixed too. Jeff > - > > - pre2: > - Stephen Rothwell: directory notify could return with the lock held Level I > - Richard Henderson: CLOCKS_PER_SEC on alpha. > - Jeff Garzik: ramfs and highmem: kmap() the page to clear it > - Asit Mallick: enable the APIC in the official order Level I > - Neil Brown: avoid rd deadlock on io_request_lock by using a > private rd-request function. This also avoids unnecessary > request merging at this level. Level I > - Ben LaHaise: vmalloc threadign and overflow fix Level I > - Randy Dunlap: USB updates (plusb driver). PCI cacheline size. > - Neil Brown: fix a raid1 on top of lvm bug that crept in in pre1 > - Alan Cox: various (Athlon mmx copy, NULL ptr checks for > scsi_register etc). > - Al Viro: fix /proc permission check security hole. > - Can-Ru Yeou: SiS301 fbcon driver > - Andrew Morton: NMI oopser and kernel page fault punch through > both console_lock and timerlist_lock to make sure it prints out.. > - Jeff Garzik: clean up "kmap()" return type (it returns a kernel > virtual address, ie a "void *"). > - Jeff Garzik: network driver docs, various one-liners. > - David Miller: add generic "special" flag to page flags, to be > used by architectures as they see fit. Like keeping track of > cache coherency issues. > - David Miller: sparc64 updates, make sparc32 boot again > - Davdi Millner: spel "synchronous" correctly Spell "David Miller" correctly. 8). > - David Miller: networking - fix some bridge issues, and correct > IPv6 sysctl entries. > - Dan Aloni: make fork.c use proper macro rather than doing > get_exec_domain() by hand. > > - pre1: > - me: make PCMCIA work even in the absense of PCI irq's > - me: add irq mapping capabilities for Cyrix southbridges > - me: make IBMMCA compile right as a module > - me: uhhuh. Major atomic-PTE SMP race boo-boo. Fixed. > - Andrea Arkangeli: don't allow people to set security-conscious > bits in mxcsr through ptrace SETFPXREGS. > - Jürgen Fischer: aha152x update > - Andrew Morton, Trond Myklebust: file locking fixes > - me: TLB invalidate race with highmem > - Paul Fulghum: synclink/n_hdlc driver updates > - David Miller: export sysctl_jiffies, and have the proper no-sysctl > version handy > - Neil Brown: RAID driver deadlock and nsfd read access to > execute-only files fix > - Keith Owens: clean up module information passing, remove > "get_module_symbol()". > - Jeff Garzik: network (and other) driver fixes and cleanups > - Andrea Arkangeli: scheduler cleanup. > - Ching-Ling Li: fix ALi sound driver memory leak > - Anton Altaparmakov: upcase fix for NTFS > - Thomas Woller: CS4281 audio update > > - > 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/
[PATCH] obvious change to apm.c
Hi Linus, Obvious patch since daemonize() now does this stuff. Cheers, Stephen -- Stephen Rothwell, Open Source Researcher, Linuxcare, Inc. +61-2-62628990 tel, +61-2-62628991 fax [EMAIL PROTECTED], http://www.linuxcare.com/ Linuxcare. Support for the revolution. diff -ruN 2.4.0-test11pre2/arch/i386/kernel/apm.c 2.4.0-test11pre2-sfr/arch/i386/kernel/apm.c --- 2.4.0-test11pre2/arch/i386/kernel/apm.c Wed Nov 1 09:36:12 2000 +++ 2.4.0-test11pre2-sfr/arch/i386/kernel/apm.c Fri Nov 10 13:20:28 2000 @@ -1422,9 +1422,6 @@ kapmd_running = 1; - exit_files(current);/* daemonize doesn't do exit_files */ - current->files = init_task.files; - atomic_inc(>files->count); daemonize(); strcpy(current->comm, "kapm-idled"); - 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/
test11-pre2
Nothing stands out as affecting most people here. Security fix for /proc, and various cleanups. Alpha and sparc fixes. If you use RAID or ramdisk, upgrade. Linus - - pre2: - Stephen Rothwell: directory notify could return with the lock held - Richard Henderson: CLOCKS_PER_SEC on alpha. - Jeff Garzik: ramfs and highmem: kmap() the page to clear it - Asit Mallick: enable the APIC in the official order - Neil Brown: avoid rd deadlock on io_request_lock by using a private rd-request function. This also avoids unnecessary request merging at this level. - Ben LaHaise: vmalloc threadign and overflow fix - Randy Dunlap: USB updates (plusb driver). PCI cacheline size. - Neil Brown: fix a raid1 on top of lvm bug that crept in in pre1 - Alan Cox: various (Athlon mmx copy, NULL ptr checks for scsi_register etc). - Al Viro: fix /proc permission check security hole. - Can-Ru Yeou: SiS301 fbcon driver - Andrew Morton: NMI oopser and kernel page fault punch through both console_lock and timerlist_lock to make sure it prints out.. - Jeff Garzik: clean up "kmap()" return type (it returns a kernel virtual address, ie a "void *"). - Jeff Garzik: network driver docs, various one-liners. - David Miller: add generic "special" flag to page flags, to be used by architectures as they see fit. Like keeping track of cache coherency issues. - David Miller: sparc64 updates, make sparc32 boot again - Davdi Millner: spel "synchronous" correctly - David Miller: networking - fix some bridge issues, and correct IPv6 sysctl entries. - Dan Aloni: make fork.c use proper macro rather than doing get_exec_domain() by hand. - pre1: - me: make PCMCIA work even in the absense of PCI irq's - me: add irq mapping capabilities for Cyrix southbridges - me: make IBMMCA compile right as a module - me: uhhuh. Major atomic-PTE SMP race boo-boo. Fixed. - Andrea Arkangeli: don't allow people to set security-conscious bits in mxcsr through ptrace SETFPXREGS. - Jürgen Fischer: aha152x update - Andrew Morton, Trond Myklebust: file locking fixes - me: TLB invalidate race with highmem - Paul Fulghum: synclink/n_hdlc driver updates - David Miller: export sysctl_jiffies, and have the proper no-sysctl version handy - Neil Brown: RAID driver deadlock and nsfd read access to execute-only files fix - Keith Owens: clean up module information passing, remove "get_module_symbol()". - Jeff Garzik: network (and other) driver fixes and cleanups - Andrea Arkangeli: scheduler cleanup. - Ching-Ling Li: fix ALi sound driver memory leak - Anton Altaparmakov: upcase fix for NTFS - Thomas Woller: CS4281 audio update - 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: catch 22 - porting net driver from 2.2 to 2.4
> We figured that since we are in user context (do_ioctl) and use > spin_lock_bh() to protect us from other concurrent threads, it might > interfere with rtnl_lock() so we remove our lock just before calling > register_netdev() and lock again upon return but then the whole process just > stopped and didn't return to the prompt. from within kdb, we could see that Can't you just do this: #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,3,0) /* not sure about the 0 */ #define rtnl_LOCK() rtnl_lock() #define rtnl_UNLOCK() rtnl_unlock() #else #define rtnl_LOCK() /* nop */ #define rtnl_UNLOCK() /* nop */ #endif rtnl_LOCK(); register_netdevice(...); rtnl_UNLOCK(); that works for me (yes, from do_ioctl, but without the bh lock - I don't know if that's absolutely needed in your case). Olaf - 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: NFS, Can't get request slot
> Nov 10 04:33:17 spc81 kernel: nfs: server student not responding, still trying > Nov 10 04:33:17 spc81 kernel: nfs: server student OK These are all one second or subsecond timeouts > Nov 10 04:45:56 spc81 kernel: nfs: server student not responding, still trying > Nov 10 04:46:00 spc81 kernel: nfs: task 20457 can't get a request slot > Nov 10 04:46:00 spc81 kernel: nfs: server student OK One four second one here > We have changed the NIC on this server to 3Com 3c90x for no change in status. > Clients are using CNETPro120 200 and Intel eepro100 If samba is ok its not the NIC, it could be congestion on routers or hubs but you have tried rsize 1024 (and wsize ??) > Any more help is much appreciated. You might want to just bump up the NFS timeouts for those warning messages a couple of seconds. I dont think you have an actual problem. Timeouts are configurable in mount - 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: NFS, Can't get request slot
Alan, On a client running all by itself on our production network overnight, doing an "ls -lR /usr" and doing a compile (in a loop) is giving the same problems. A little snipit from /var/log/messages Nov 10 04:31:20 spc81 kernel: nfs: server student OK Nov 10 04:33:17 spc81 kernel: nfs: server student not responding, still trying Nov 10 04:33:17 spc81 kernel: nfs: server student OK Nov 10 04:34:59 spc81 kernel: nfs: server student not responding, still trying Nov 10 04:35:04 spc81 kernel: nfs: task 20823 can't get a request slot Nov 10 04:35:35 spc81 kernel: nfs: server student OK Nov 10 04:35:35 spc81 kernel: nfs: server student OK Nov 10 04:44:43 spc81 kernel: nfs: server student not responding, still trying Nov 10 04:44:44 spc81 kernel: nfs: server student OK Nov 10 04:45:56 spc81 kernel: nfs: server student not responding, still trying Nov 10 04:46:00 spc81 kernel: nfs: task 20457 can't get a request slot Nov 10 04:46:00 spc81 kernel: nfs: server student OK Nov 10 04:46:03 spc81 kernel: nfs: server student OK Nov 10 04:49:15 spc81 kernel: nfs: server student not responding, still trying Nov 10 04:49:15 spc81 kernel: nfs: server student OK Nov 10 04:49:25 spc81 kernel: nfs: server student not responding, still trying Nov 10 04:52:21 spc81 kernel: nfs: server student OK Nov 10 04:53:43 spc81 kernel: nfs: server student not responding, still trying Nov 10 04:53:43 spc81 kernel: nfs: server student OK Nov 10 04:54:01 spc81 kernel: nfs: server student not responding, still trying Nov 10 04:54:02 spc81 kernel: nfs: task 64822 can't get a request slot Nov 10 04:54:13 spc81 kernel: nfs: server student OK Nov 10 04:54:15 spc81 kernel: nfs: server student OK Nov 10 04:55:57 spc81 kernel: nfs: server student not responding, still trying Nov 10 04:55:59 spc81 kernel: nfs: task 29484 can't get a request slot Nov 10 04:56:21 spc81 kernel: nfs: server student OK Nov 10 04:56:23 spc81 kernel: nfs: server student OK Nov 10 04:58:15 spc81 kernel: nfs: server student not responding, still trying Nov 10 04:58:21 spc81 kernel: nfs: task 1477 can't get a request slot Nov 10 04:58:52 spc81 kernel: nfs: task 1478 can't get a request slot Nov 10 04:59:15 spc81 kernel: nfs: server student OK Shows that under no (or little) load this thing is failing. We have 20 networks with ~100 machines on each with this same problem. Only a few at a time are using Linux. We are trying to promote Linux as a great operating system, but this is not helping. Again the samba on win95 is puring along nicely plus every other service but for NFS. We have changed the NIC on this server to 3Com 3c90x for no change in status. Clients are using CNETPro120 200 and Intel eepro100 The servers are generally PIII500 512MB RAM. We have tried mount flags rsize=1024, 8192, 128, with no change. It looks like a server issue related to RPC. But I am only guessing here. Any more help is much appreciated. Thanks Grahame Jordan Alan Cox wrote: > By the evidence that we have gathered it seems that the Server is not > taxed too much as samba users are getting files OK etc. The can't get > request slot is plaguing many others in different ways. It looks like > an NFS issue. How can this be proven? Then we can work on the > problem. The request queue slot message means the server isnt responding (at least in the eyes of the client). Given you can get into the box that isnt the net card (at least not now). What mount options do you use ? - 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/ -- Grahame Jordan Network Manager Interim Technology Training Institute Mobile: +61 3 0408 058 209 Phone: +61 3 9243 2220 Fax: +61 3 9820 2010 e-mail: [EMAIL PROTECTED] Transforming the way people work with technology with INTEGRITY LEARNING INNOVATION TEAMWORK PERFORMANCE
Re: Module open() problems, Linux 2.4.0
> > I suppose. Look at what you just stated! This means that a reported > > value is now worthless. > > Correct. And it was always worthless. Right. The module "use count" is not a use count, it's a lock count. E.g. a driver may well increase this counter on open and then again when in a particular ioctl routine, if this situation isn't already locked right by the kernel. This can happen when a driver has more than one access point from user space, look at slip_open() in slip.c from 2.2. > It's the same de-facto standard as bogo-mips ~= CPU MHz. It was so, > but it was neither intended nor documented so. Remember the Landmark Test and those silly CPU-speed displays configured to show "Landmark MHz"? :-) Olaf - 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: Errors in 2.4-test11 build
"J . A . Magallon" <[EMAIL PROTECTED]> writes: > A suggestion. People being able to build kernels with egcs or other version, > would not be this suitable for another entry in /var/lib/rpm/alternatives, > named kgcc, and with priorities gcc-2.91.66, gcc-2.95.2, gcc-2.7.2.3, gcc-2.96 ? this could be a good idea, but i don't want to set kgcc for gcc-2.96, and we have only (in cooker) egcs- and gcc-2.96 in the main/ ditstrib. Ok and BTW: this problem is only for the mandrake devlopement distribution (cooker) 7.2 out of the box egcs/kgcc should work fine. -- MandrakeSoft Inc http://www.chmouel.org --Chmouel - 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: Errors in 2.4-test11 build
On Thu, 09 Nov 2000 21:13:36 Chmouel Boudjnah wrote: > "J . A . Magallon" <[EMAIL PROTECTED]> writes: > > > Trying to build 2.4.0-test11-pre1 I get the following: > > > > make[1]: Entering directory `/usr/src/linux-2.4.0-test11/arch/i386/kernel' > > kgcc -D__ASSEMBLY__ -D__KERNEL__ -I/usr/src/linux/include -traditional -c > > trampoline.S -o trampoline.o > > gcc: installation problem, cannot exec `tradcpp0': No such file or directory > > make[1]: *** [trampoline.o] Error 1 > > My egcs does not have a -traditional cpp (Mandrake 7.2, packages egcs and > > egcs-cpp). > > sorry this is an error with the egcs package can you upgrade to these > packages : > > ftp://ftp.chmouel.org/pub/people/chmou/kgcc/ > > and let me know if it's work for you (it does for me) and will do an > update soon. > Worked fine. A suggestion. People being able to build kernels with egcs or other version, would not be this suitable for another entry in /var/lib/rpm/alternatives, named kgcc, and with priorities gcc-2.91.66, gcc-2.95.2, gcc-2.7.2.3, gcc-2.96 ? -- Juan Antonio Magallon Lacarta #> cd /pub mailto:[EMAIL PROTECTED] #> more beer - 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: Linux 2.2.18pre20 MEGARAID hang
> [and, if you can, and this patch works, try to remove parts of the > patch until you find exactly what it is that makes it work] Thats what I need to know. Looking at the patch it makes no changes at all verus 2.2.18pre20 - 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: PCI-PCI bridges mess in 2.4.x
On Thu, Nov 09, 2000 at 11:33:47AM -0500, Wakko Warner wrote: > > It was posted to lkml, so no link (except if you want to dig through > > lkml mail archives). > > It booted but then it oops'ed before userland I belive. I tried it this > morning and didn't have much time. It did find the scsi controller (which > is across the bridge) and the drives attached so it does appear to be > working. Looks so far that I am the worst off. If I am trying to boot with a root on a SCSI device then either a controller is misdetected, or goes into an infinite "abort/reset" loop, or it does not initialize properly and disks are not found. This is a non-exclusive, logical, "or". :-) Booting to an IDE device makes difference only in that that if I can boot then SCSI disks will be simply ignored. If somebody is interested in a collection of dmesg outputs, with DEBUG printks, from such attempts then I am game. Ivan was getting these pretty consistently. :-) Michal - 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: PCI-PCI bridges mess in 2.4.x
On Thu, Nov 09, 2000 at 09:37:41PM +0100, Gerard Roudier wrote: > Hmmm... > The PCI spec. says that Limit registers define the top addresses > _inclusive_. Correct. > The spec. does not seem to imagine that a Limit register lower than the > corresponding Base register will ever exist anywhere, in my opinion. :-) Not correct. Here's a quote from `PCI-to-PCI Bridge Architecture Specification rev 1.1': The Memory Limit register _must_ be programmed to a smaller value than the Memory Base if there are no memory-mapped I/O addresses on the secondary side of the bridge. I/O is slightly different because it's optional for the bridge - but if it's implemented same rules apply. > This let me think that trying to be clever here is probably a very bad > idea. What is so catastrophic of having 1 to 4 bytes of addresses and no > more being possibly in a forwardable range? > Huh. 1 to 4 bytes? 4K for I/O and 1M for memory. And it's not trying to be clever (anymore :-) - just strictly following the Specs. I understand your point very well, btw. I asked similar questions to myself until I've had the docs. Ivan. - 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: Patch: Using clipped IDE disk larger than 32GB with old BIOS
> > # I might consider adding support for even newer 48-bit LBA
> > # extension (which I read in ATA spec).
>
> The 48-LBA stuff is on hold because it requires more than simple
> changes to ide-disk.c.
Yes, I guess this is currently a future issue. If this is going to
be done, there also needs fix in userland program, like fdisk and
hdparm.
> We have not voted on the final design of the 48-LBA and no drive
> or BIOS guys have any product ready for testing.
But we're definitely going to face the problem as we'll probably
see IDE disk larger then 128GB next year. What was the current
max - 80GB, I thought? That not so far away from 128GB.
> So you like that TASKFILE. ;-)
Actually it was the one I found out its usage first :-). Its
interface seems OK for me.
For TASK vs. CMD issue, I have no definite idea on it. But if sole
reason for CMD interface is to limit invalid/unsafe IDE command
submission, I guess they could (not should) go to userland as a
library (libsafeide?). I'll re-read the discussion so I can write
something more thought out.
--
T. Yamada <[EMAIL PROTECTED]> (http://www.imasy.or.jp/~tai/index.html.{ja,en})
PGP fingerprint = 6B 57 1B ED 65 4C 7D AE 57 1B 49 A7 F7 C8 23 46
-
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: Patch generation
On Thu, 9 Nov 2000, Ivan Passos wrote: > Where in the src tree can I find (or what is) the command to generate a > patch file from two Linux kernel src trees, one being the original and the > other being the newly changed one?? The syntex looks like this one: diff -urN old_tree new_tree > your_patch_file > I've tried 'diff -ruN', but that does diff's on several files that could > stay out of the comparison (such as the files in include/config, .files, > etc.). You can use the --exclude switch of diff, or make mrproper before you diff, or you can cp -al a clean source tree before you build the kernel on top of it. Another way, is to use *one* source tree, copying the files you change - adding them the '.orig' extention to their name. Then you run this script (I got it when Riel pasted it on IRC) for i in `find ./ -name \*.orig` ; do diff -u $i `dirname $i`/`basename $i .orig` ; done About the other method: cp -al is fast, creating a copy of tree without taking much diskspace, it copies the tree by hard linking the files. BTW, 'patch' unlinks files before modifing so you can have lots of kernel trees from different releases with little diskspace waste: [karrde@callisto ~/usr/src/kernel/work]$ ls -1 linux-2.4.0-test10 linux-2.4.0-test10.build linux-2.4.0-test11-pre1 linux-2.4.0-test6 I did 'cp -al linux-2.4.0-test10 linux-2.4.0-test10.build', and on linux-2.4.0-test10.build I did 'make bzImage' and all the rest. When Linus releasd test11-pre1 I did 'cp -al' from test10 to test11-pre1 and patched the test11-pre1 dir with the patch Linus released. the test10 dir remained intact. [karrde@callisto ~/usr/src/kernel/work]$ du . -s 193004 . 4 kernel trees, one after make dep ; make bzImage, and all taking together just 193MB, instead of about 400MB... hard links, gotta love'em. -- Dan Aloni [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/
Re: Kernel 2.2.17 bug found
On Thu, 09 Nov 2000 16:20:22 Andrea Pintori wrote: > I've a Debian dist, Kernel 2.2.17, no patches, all packages are stable. > > here what I found: > > [/tmp] mkdir old > [/tmp] chdir old > [/tmp/old] mv . ../new > [/tmp/old](should be /tmp/new !!) No, bash cwd is still "/tmp/old". > [/tmp/old] mkdir fff > error: cannot write... > [tmp/old] ls > fff > error: cannot write... > [/tmp/old] ls -la > total 0 (?) Right, "/tmp/old" does not exist, so nothing can be done with it. > [/tmp/old] cd .. > [/tmp] ls -la > * ./ > * ../ > * new/ > > Does anybody knew this bug? Is not a bug, I have also seen that int SGI IRIX. Try it in an NFS mounted disk. I don't remember exactly, but even you can ls it. Things on file system caches and so on... -- Juan Antonio Magallon Lacarta #> cd /pub mailto:[EMAIL PROTECTED] #> more beer - 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: [bug] usb-uhci locks up on boot half the time
In article <[EMAIL PROTECTED]>, David Ford <[EMAIL PROTECTED]> wrote: > >The oddity is that kdb shows the machine to lock up on the popf in >pci_conf_write_word()+0x2c. I never did get around to digging up this >routine and looking at the code, but I suspect this is a final return >from the routine. I'm rather confused however, I have no idea why a >flags pop would hang the hardware. Educated guess: it enables interrupts, after it has done something to the hardware that causes an infinite stream of them. Linus - 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/
Patch generation
Hello, Where in the src tree can I find (or what is) the command to generate a patch file from two Linux kernel src trees, one being the original and the other being the newly changed one?? I've tried 'diff -ruN', but that does diff's on several files that could stay out of the comparison (such as the files in include/config, .files, etc.). Thanks in advance for your help. Later, Ivan - 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: [bug] usb-uhci locks up on boot half the time
"Dunlap, Randy" wrote: > > Either. Currently bus (self) powered. This hub has worked > > fine on my other > > computers without any adverse affect. > > Bus-powered != self-powered. It had been a long day. I really do know the distinction :) It is currently bus powered and I've only once had it self powered several months ago. It is an SIIG 4 port hub, I hadn't seen any complaints about it doing a web search when I looked, so I purchased it. I have found that after unplug/plug the mouse and reboot, If I unplug the hub then the boot will continue fine, if I unplug the just the mouse (which is plugged into the hub), the machine will indeed hang. If I reset the power on the hub and plug it back in it will still hang. I must reset the power on the motherboard. The oddity is that kdb shows the machine to lock up on the popf in pci_conf_write_word()+0x2c. I never did get around to digging up this routine and looking at the code, but I suspect this is a final return from the routine. I'm rather confused however, I have no idea why a flags pop would hang the hardware. -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;14688 fn:David Ford end:vcard
2.4.0-test10 oops
Hi, attached oops came from writing to vfat fs. Jan Dvorak <[EMAIL PROTECTED]> ksymoops 2.3.5 on i686 2.4.0-test10. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test10/ (default) -m /boot/System.map (specified) No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? kernel BUG at file.c:79! invalid operand: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: 0019 ebx: ecx: c7cb4000 edx: 0001 esi: 000ed9c8 edi: c058cae0 ebp: c796ba40 esp: c7cb5e5c ds: 0018 es: 0018 ss: 0018 Process mc (pid: 310, stackpage=c7cb5000) Stack: c02ae005 c02ae187 004f 0200 1db39000 c7cb5eb4 c0134d38 c058cae0 000ed9c8 c796ba40 0001 1db39000 c066a000 c796ba40 0200 000ed9c8 c796ba40 c7f2697c 066a Call trace: [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 0f b7 47 20 66 89 45 0c 89 5d 04 80 4d 18 30 >>EIP; c015b77b<= Trace; c02ae005 Trace; c02ae187 Trace; c0134d38 <__block_prepare_write+f4/248> Trace; c01352c9 Trace; c015b6b4 Trace; c015d04e Trace; c015b6b4 Trace; c0128b98 Trace; c0126b42 Trace; c015b7ee Trace; c015b7c5 Trace; c013255b Trace; c010b113 Code; c015b77b <_EIP>: Code; c015b77b<= 0: 0f 0b ud2a <= Code; c015b77d 2: 83 c4 0c add$0xc,%esp Code; c015b780 5: 0f b7 47 20 movzwl 0x20(%edi),%eax Code; c015b784 9: 66 89 45 0c mov%ax,0xc(%ebp) Code; c015b788 d: 89 5d 04 mov%ebx,0x4(%ebp) Code; c015b78b 10: 80 4d 18 30 orb$0x30,0x18(%ebp) 1 warning issued. Results may not be reliable.
Re: [patch-2.4.0-test11-pre1] broken comment around paging_init()
On Thu, 9 Nov 2000, Tigran Aivazian wrote: > The comment above arch/i386/mm/init.c:paging_init() lies shamelessly -- we correction -- it doesn't lie since [0,4M] \subset [0,8M] -- it just doesn't tell the human everything he may want to see :) Regards, Tigran - 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/
[patch-2.4.0-test11-pre1] broken comment around paging_init()
Hi Linus, The comment above arch/i386/mm/init.c:paging_init() lies shamelessly -- we set up two page tables in head.S which cover 0-8M and not 0-4M. Also, the actual loop in head.S which does the job uses labels pg0 and empty_zero_page so the pointer to the second page table (pg1) is redundant. (strictly speaking, the comment in asm/pgtable.h about pg0 covering 0-4M only is confusing because it fails to mention the other one covering the next 4M but it is correct so I left it as is). Regards, Tigran diff -urN -X dontdiff linux/arch/i386/kernel/head.S work/arch/i386/kernel/head.S --- linux/i386/kernel/head.SWed Jul 5 20:03:12 2000 +++ work/arch/i386/kernel/head.SThu Nov 9 22:12:18 2000 @@ -403,9 +403,6 @@ .org 0x2000 ENTRY(pg0) -.org 0x3000 -ENTRY(pg1) - /* * empty_zero_page must immediately follow the page tables ! (The * initialization loop counts until empty_zero_page) diff -urN -X dontdiff linux/arch/i386/mm/init.c work/arch/i386/mm/init.c --- linux/arch/i386/mm/init.c Mon Oct 23 22:42:33 2000 +++ work/arch/i386/mm/init.cThu Nov 9 22:11:15 2000 @@ -437,7 +437,7 @@ } /* - * paging_init() sets up the page tables - note that the first 4MB are + * paging_init() sets up the page tables - note that the first 8MB are * already mapped by head.S. * * This routines also unmaps the page at virtual kernel address 0, so - 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: [PATCH] 2.2.18-pre20 AMI Megaraid & Dell Percraid drivers
On Thu, 9 Nov 2000, Byron Stanoszek wrote: > On Thu, 9 Nov 2000, Brian Marsden wrote: > > > 2.2.18pre20 (still) hangs on boot when it gets to the part where it > > detects the MEGARAID card. > > > > This is a shame, since 2.2.18 with NFS3 would be very nice on a big > > filestore such as the one this is running on. > > I've been running the megaraid and aacraid patches on our Dell 2.2.18 pre16-20 > kernels for almost 2-3 weeks now. We are now classifying these machines in the > 'production state' as they have been stable for me throughout the duration of > our testing and benchmarking process. > > The patches below are mutually exclusive and patch cleanly with 2.2.18-pre20. > I have not written them, but have cleaned them up a little and have performed > at least 2 weeks of extensive testing on them. Alan, if you will please, > include these patches in the next kernel (2.2.19 if anything) which will fix > the megaraid hanging problem and support Dell's Percraid controller (for 2/si, > 3/si, and 3/di models). I can confirm that the megaraid patch applies fine, boots fine and (so far) works fine. Thanks, Byron! Brian -- - Brian MarsdenEmail: [EMAIL PROTECTED] TSRI, San Diego, USA. Phone: +1 858 784 8698 Fax: +1 858 784 8299 - - 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: PCI-PCI bridges mess in 2.4.x
On Thu, 9 Nov 2000, Ivan Kokshaysky wrote: Hmmm... The PCI spec. says that Limit registers define the top addresses _inclusive_. The spec. does not seem to imagine that a Limit register lower than the corresponding Base register will ever exist anywhere, in my opinion. :-) This let me think that trying to be clever here is probably a very bad idea. What is so catastrophic of having 1 to 4 bytes of addresses and no more being possibly in a forwardable range? Gérard. > On Wed, Nov 08, 2000 at 03:48:11PM -0800, Richard Henderson wrote: > > Whee! We're back in Bootsville. > > Cool! > Meanwhile this base/limit stuff got confirmation :-) > Here is a patch against bridges-2.4.0t11-rth. > > Ivan. > > --- 2.4.0t11p1/drivers/pci/setup-bus.cWed Nov 8 19:44:42 2000 > +++ linux/drivers/pci/setup-bus.c Thu Nov 9 15:11:01 2000 > @@ -88,14 +88,14 @@ pbus_assign_resources_sorted(struct pci_ > ranges->io_end += io_reserved; > ranges->mem_end += mem_reserved; > > - /* ??? How to turn off a bus from responding to, say, I/O at > -all if there are no I/O ports behind the bus? Turning off > -PCI_COMMAND_IO doesn't seem to do the job. So we must > -allow for at least one unit. */ > - if (ranges->io_end == ranges->io_start) > - ranges->io_end += 1; > - if (ranges->mem_end == ranges->mem_start) > - ranges->mem_end += 1; > + /* Interesting case is when, say, io_end == io_start, i.e. > +there is no I/O behind the bridge at all. We initialize > +the bridge with base=io_start and limit=io_end-1, so > +in this case we'll have base > limit. According to > +the `PCI-to-PCI Bridge Architecture Specification', this > +means that the bridge will not forward any I/O transactions > +from the primary bus to the secondary bus and will forward > +all I/O transactions upstream. Exactly what we want. */ > > ranges->io_end = ROUND_UP(ranges->io_end, 4*1024); > ranges->mem_end = ROUND_UP(ranges->mem_end, 1024*1024); > > - > 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/
Re: Incorrectness for fun and profit
On Thu, 9 Nov 100 12:15:19 -0500 (EST),
Rick Hohensee <[EMAIL PROTECTED]> wrote:
>built the [2.4] kernel I'm using at the
>moment with gcc 2.7.2.3. I'm looking for "subtle run time bugs". OK, I'm
>desparate for entertainment. That's a given. Where should I look?
2.4.0-test10 kernel/module.c
static struct module kernel_module =
{
size_of_struct: sizeof(struct module),
name: "",
uc: {ATOMIC_INIT(1)},
flags: MOD_RUNNING,
syms: __start___ksymtab,
ex_table_start: __start___ex_table,
ex_table_end: __stop___ex_table
gcc 2.7.2.3 miscompiles structures that have internal labeled structure
initializers. uc gets misaligned, ex_table_start is then misaligned
and the exception table handling fails.
-
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/
Lockup in fdatasync
Hello, just installed 2.4.0-test10 on a SMP Intel machine and got following: NMI Watchdog detected LOCKUP on CPU1, registers: CPU:1 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 0086 eax: 0307 ebx: 0206 ecx: 0007 edx: 003f03af esi: 0307 edi: 000c ebp: 0001178e esp: c77efed8 ds: 0018 es: 0018 ss: 0018 Process syslogd (pid: 408, stackpage=c77ef000) Stack: c7330ae0 0002 c015fb01 0307 c7330ae0 0001 c7330ae0 0007 c015fcc3 0001 c7330ae0 c7330a20 c11f3a0c c777b2fc 0400 c0124a25 0001 0001 c77eff30 c11e8b00 c7330ae0 c0124ade Call Trace: [] [] [] [] [] [] [] [] [] Code: 80 3d a4 50 20 c0 00 f3 90 7e f5 e9 b7 7c f9 ff 80 3d 84 13 >>EIP; c01c7162<= Trace; c015fb01 Trace; c015fcc3 Trace; c0124a25 Trace; c0124ade Trace; c0124b4d Trace; c01249ec Trace; c015117d Trace; c0132c9e Trace; c010a7db Code; c01c7162 <_EIP>: Code; c01c7162<= 0: 80 3d a4 50 20 c0 00 cmpb $0x0,0xc02050a4 <= Code; c01c7169 7: f3 90 repz nop Code; c01c716b 9: 7e f5 jle0 <_EIP> Code; c01c716d b: e9 b7 7c f9 ffjmpfff97cc7 <_EIP+0xfff97cc7> c015ee29 Code; c01c7172 10: 80 3d 84 13 00 00 00 cmpb $0x0,0x1384 After this the sync hangs on wait_on_buffer and any access to /var/log/messages hangs on lock_page. The system is otherwise living (hope to see it living after a reboot too... :-(). What I was doing at the time is difficult to say exactly, but I was playing with modules, loading and unloading them (I wanted to make sure that I have compiled all I needed and I was also testing modules.conf configuration) - mainly ppa, iso9660 and such. The ppa driver need quite long to attach to the parport ZIP drive - after what time the lockup detector kicks in? There was no such problem prior and including -test8, so it happened somewhere in test9 or 10. I vaguely remember some discussion regarding datasync in the l-k - maybe this is related? Regards -- Stano - 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/
Comming to Share??? (re: Subcribe)
Hello Scot, Is Iomega ready to open the information needed to make you ATAPI products work correctly with Linux? Regards, Andre Hedrick CTO Timpanogas Research Group EVP Linux Development, TRG Linux ATA Development - 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: Module open() problems, Linux 2.4.0
In article <[EMAIL PROTECTED]> you wrote: > On Thu, 9 Nov 2000, Jeff Garzik wrote: >> There is NO guarantee that module use count == device open count. Never >> has been, AFAIK. It just happens to work out that way on a lot of >> pre-2.4 code. >> >> The kernel is free to bump the module reference count up and down as it >> pleases. For example, if a driver creates a kernel thread, that will >> increase its module usage count by one, for the duration of the kernel >> thread's lifetime. >> >> The only rule is that you cannot unload a module until its use count it >> zero. >> >> Jeff >> > I suppose. Look at what you just stated! This means that a reported > value is now worthless. Correct. And it was always worthless. > To restate, somebody decided that we didn't need this reported value > anymore. Therefore, it is okay to make it worthless. It was always wothless besides == 0 means: you can unload me now. > I don't agree. The De-facto standard has been that the module usage > count is equal to the open count. This became the standard because > of a long established history. It's the same de-facto standard as bogo-mips ~= CPU MHz. It was so, but it was neither intended nor documented so. > This is one of the tools we use to verify that an entire system > is functioning properly. It was the wrong tool. Christoph -- Always remember that you are unique. Just like everyone else. - 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: Used space in bytes
In article <8uf21i$ro7$[EMAIL PROTECTED]>, H. Peter Anvin <[EMAIL PROTECTED]> wrote: >Report a block size (really allocation unit size) st_blocks == 1? If you mean st_blksize, well: The value st_blocks gives the size of the file in 512-byte blocks. The value st_blksize gives the "preferred" block size for efficient file system I/O. (Writing to a file in smaller chunks may cause an inefficient read-modify- rewrite.) Telling programs 'please use 1-byte r/w buffers' is probably a bad idea. Mike. -- People get the operating system they deserve. - 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: Module open() problems, Linux 2.4.0
"Richard B. Johnson" wrote: > I suppose. Look at what you just stated! This means that a reported > value is now worthless. > > To restate, somebody decided that we didn't need this reported value > anymore. Therefore, it is okay to make it worthless. > > I don't agree. The De-facto standard has been that the module usage > count is equal to the open count. This became the standard because > of a long established history. > > This is one of the tools we use to verify that an entire system > is functioning properly. Now, somebody decided that I didn't need > this tool. You assumed the module count == device open count, when that was in fact never the case. The 2.4.x kernel changes merely shattered false assumptions you held on your part. The kernel thread example I described in my last e-mail holds true for kernel 2.2.x as well, maybe 2.0.x too. Jeff -- Jeff Garzik | Building 1024 | Would you like a Twinkie? MandrakeSoft| - 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: Module open() problems, Linux 2.4.0
On Thu, 9 Nov 2000, Jeff Garzik wrote: > "Richard B. Johnson" wrote: > > > > On Thu, 9 Nov 2000, Brian Gerst wrote: > > > > > "Richard B. Johnson" wrote: > > > > > > > > `lsmod` shows that a device is open twice when using Linux-2.4.0-test9 > > > > when, in fact, it has been opened only once. > > > > > > > > > > > > > > When the module is closed, the use-count goes to zero as expected. > > > > However, a single open() causes the use-count to be 2. > > > > > > This is harmless. It is caused by a try_inc_mod_count(module) in the > > > function calling device_open(), which is the proper way for module > > > locking to be handled when not holding the BKL. You can keep the > > > MOD_INC_USE_COUNT in the device driver for compatability with 2.2. > > > > > > Brian Gerst > > > > This may be, as you say, "harmless". It is, however, a bug. The > > reporting must be correct or large complex systems can't be > > developed or maintained. > > > > I had two persons, working nearly a week, trying to find out > > what one of over 200 processes had a device open when only > > one was supposed to have it opened. --Err we have to check > > our work here. The fact that something "works" is not > > sufficient. > > There is NO guarantee that module use count == device open count. Never > has been, AFAIK. It just happens to work out that way on a lot of > pre-2.4 code. > > The kernel is free to bump the module reference count up and down as it > pleases. For example, if a driver creates a kernel thread, that will > increase its module usage count by one, for the duration of the kernel > thread's lifetime. > > The only rule is that you cannot unload a module until its use count it > zero. > > Jeff > I suppose. Look at what you just stated! This means that a reported value is now worthless. To restate, somebody decided that we didn't need this reported value anymore. Therefore, it is okay to make it worthless. I don't agree. The De-facto standard has been that the module usage count is equal to the open count. This became the standard because of a long established history. This is one of the tools we use to verify that an entire system is functioning properly. Now, somebody decided that I didn't need this tool. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Pentium 4 and 2.4/2.5
On Wed, Nov 08, 2000 at 06:47:40PM +, Alan Cox wrote: > Ok. Issue settled. So 'rep nop' is safe. Ok that can get into the spinlocks > for 2.2.18 Just curious... What does "rep nop" actually accomplish, anyway? Simon- [ Stormix Technologies Inc. ][ NetNation Communications Inc. ] [ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]] [ Opinions expressed are not necessarily those of my employers. ] - 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: Used space in bytes
Followup to: <[EMAIL PROTECTED]> By author:Jan Kara <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Hello. > > I sent similar email a few weeks ago but discussion ended without > any useful results if I rememeber well. > > Quota in reiserfs is (and needs to be) accounted in bytes not in blocks. > I modified quota system to allow such thing so in kernel there's no > problem. But also 'quotacheck' needs to know how many space does given > file use. Currently it uses st_blocks from stat(2) to compute the space > used but for reiserfs we need precision in bytes, not in 512 byte blocks... > My proposal is to alter stat64() syscall to return also number of bytes > used (I tried to contact Ulrich Drepper <[EMAIL PROTECTED]> who should > be right person to ask about such things (at least I was said so) but go > no answer...). Does anybody have any better solution? > I know about two others - really ugly ones: >1) fs specific ioctl() >2) compute needed number of bytes from st_size and st_blocks, which is > currently possible but won't be in future > Report a block size (really allocation unit size) st_blocks == 1? -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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 2.2.18pre20 MEGARAID hang
2.2.18pre20 (still) hangs on boot when it gets to the part where it detects the MEGARAID card. This is a shame, since 2.2.18 with NFS3 would be very nice on a big filestore such as the one this is running on. Further details: lspci: 00:00.0 Host bridge: ServerWorks CNB20HE (rev 05) 00:00.1 Host bridge: ServerWorks CNB20HE (rev 05) 00:02.0 PCI bridge: Intel Corporation 80960RP [i960 RP Microprocessor/Bridge] (rev 05) 00:02.1 SCSI storage controller: Intel Corporation 80960RP [i960RP Microprocessor] (rev 05) 00:04.0 VGA compatible controller: Trident Microsystems Blade 3D PCI/AGP (rev 3a) 00:06.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)00:0f.0 ISA bridge: ServerWorks OSB4 (rev 4f) 00:0f.1 IDE interface: ServerWorks: Unknown device 0211 00:0f.2 USB Controller: ServerWorks: Unknown device 0220 (rev 04) 02:02.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) dmesg (from 2.2.17 on the same machine) attached. .config for 2.2.18pre20 attached. If I can help more, please CC me as I am not subscribed to this list. Brian Marsden -- - Brian MarsdenEmail: [EMAIL PROTECTED] TSRI, San Diego, USA. Phone: +1 858 784 8698 Fax: +1 858 784 8299 - # # Automatically generated make config: don't edit # # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set CONFIG_M686=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set CONFIG_X86_CPUID=y CONFIG_1GB=y # CONFIG_2GB is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_SMP=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # General setup # CONFIG_NET=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_QUIRKS=y # CONFIG_PCI_OPTIMIZE is not set CONFIG_PCI_OLD_PROC=y # CONFIG_MCA is not set # CONFIG_VISWS is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # CONFIG_BINFMT_JAVA is not set # CONFIG_PARPORT is not set # CONFIG_APM is not set # CONFIG_TOSHIBA is not set # # Plug and Play support # CONFIG_PNP=y # # Block devices # CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_IDEDMA=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_VIA82C586 is not set # CONFIG_BLK_DEV_CMD646 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_IDE_CHIPSETS is not set # # Additional Block Devices # # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_XD is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_PARIDE_PARPORT=y # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_HD is not set # # Networking options # CONFIG_PACKET=y # CONFIG_NETLINK is not set # CONFIG_FIREWALL is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_IP_ROUTER is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set CONFIG_IP_ALIAS=y # CONFIG_SYN_COOKIES is not set # # (it is safe to leave these untouched) # # CONFIG_INET_RARP is not set CONFIG_SKB_LARGE=y # CONFIG_IPV6 is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_BRIDGE is not set # CONFIG_NET_DIVERT is not set # CONFIG_LLC is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # CONFIG_CPU_IS_SLOW is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Telephony Support # # CONFIG_PHONE is not set # # SCSI support # CONFIG_SCSI=y
Re: Module open() problems, Linux 2.4.0
"Richard B. Johnson" wrote:
>
> On Thu, 9 Nov 2000, Brian Gerst wrote:
>
> > "Richard B. Johnson" wrote:
> > >
> > > `lsmod` shows that a device is open twice when using Linux-2.4.0-test9
> > > when, in fact, it has been opened only once.
> > >
>
> > >
> > > When the module is closed, the use-count goes to zero as expected.
> > > However, a single open() causes the use-count to be 2.
> >
> > This is harmless. It is caused by a try_inc_mod_count(module) in the
> > function calling device_open(), which is the proper way for module
> > locking to be handled when not holding the BKL. You can keep the
> > MOD_INC_USE_COUNT in the device driver for compatability with 2.2.
> >
> > Brian Gerst
>
> This may be, as you say, "harmless". It is, however, a bug. The
> reporting must be correct or large complex systems can't be
> developed or maintained.
>
> I had two persons, working nearly a week, trying to find out
> what one of over 200 processes had a device open when only
> one was supposed to have it opened. --Err we have to check
> our work here. The fact that something "works" is not
> sufficient.
It is not a bug. The only values that matter are zero and non-zero. As
long as the refcounting is symmetric, it all comes out in the wash.
Remove the MOD_{INC,DEC}_USE_COUNT from your driver if it bothers you
that much and you don't care about 2.2 compatability.
--
Brian Gerst
-
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: Module open() problems, Linux 2.4.0
"Richard B. Johnson" wrote: > > On Thu, 9 Nov 2000, Brian Gerst wrote: > > > "Richard B. Johnson" wrote: > > > > > > `lsmod` shows that a device is open twice when using Linux-2.4.0-test9 > > > when, in fact, it has been opened only once. > > > > > > > > > > When the module is closed, the use-count goes to zero as expected. > > > However, a single open() causes the use-count to be 2. > > > > This is harmless. It is caused by a try_inc_mod_count(module) in the > > function calling device_open(), which is the proper way for module > > locking to be handled when not holding the BKL. You can keep the > > MOD_INC_USE_COUNT in the device driver for compatability with 2.2. > > > > Brian Gerst > > This may be, as you say, "harmless". It is, however, a bug. The > reporting must be correct or large complex systems can't be > developed or maintained. > > I had two persons, working nearly a week, trying to find out > what one of over 200 processes had a device open when only > one was supposed to have it opened. --Err we have to check > our work here. The fact that something "works" is not > sufficient. There is NO guarantee that module use count == device open count. Never has been, AFAIK. It just happens to work out that way on a lot of pre-2.4 code. The kernel is free to bump the module reference count up and down as it pleases. For example, if a driver creates a kernel thread, that will increase its module usage count by one, for the duration of the kernel thread's lifetime. The only rule is that you cannot unload a module until its use count it zero. Jeff -- Jeff Garzik | Building 1024 | Would you like a Twinkie? MandrakeSoft| - 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: accessing on-card ram/rom
On Wed, 8 Nov 2000 [EMAIL PROTECTED] wrote: > I looked at the IO-mapping.txt file. It says that > on x86 architecture it should not make any difference. > It also says that "on x86 it _is_ the same memory space. So > on x86 it actually works to just dereference a pointer". For bus_to_virt() to give a usable virtual address, such a virtual mapping must exist and additionnally be part of the linear kernel mapping. A PCI MMIO address is generally _not_ even mapped by default by the kernel. On the other hand, bus_to_virt() hasn't the proper semantic for your problem, since it applies to main memory addresses as seen from the PCI BUS, and you want an MMIO address usable by the CPU (=virtual). Hmmm... ioremap() just create a virtual mapping for the CPU to access the MMIO window of your PCI chip just fine. Gérard. > Any inputs on this ? > > Thanks and regards, > -hiren > > > -Original Message- > > From: Jeff Garzik [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, November 08, 2000 2:53 PM > > To: MEHTA,HIREN (A-SanJose,ex1) > > Cc: '[EMAIL PROTECTED]' > > Subject: Re: accessing on-card ram/rom > > > > > > "MEHTA,HIREN (A-SanJose,ex1)" wrote: > > > I have a PCI card which has on-card ram/rom which gets mapped > > > into pci address space and there is a separate base register > > > for this memory. Now the question is : can I access this on-card > > > memory by converting the pci base address into the virtual address > > > using bus_to_virt and adding the required offset ? Or do I need > > > to use ioremap function to map the physical address space starting > > > from the pci base address into the kernel virtual address space ? > > > Or is there any other interface to access the on-card memory ? > > > Is it that bus_to_virt can be used only for the normal RAM ? > > > > Use ioremap. > > > > For more details, read linux/Documentation/IO-mapping.txt. > > > > Jeff > > > > > > -- > > Jeff Garzik | "When I do this, my computer freezes." > > Building 1024 | -user > > MandrakeSoft| "Don't do that." > > | -level 1 > > > - > 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/
Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
Date: Thu, 9 Nov 2000 14:26:33 + (GMT) From: Alan Cox <[EMAIL PROTECTED]> > Actually, he's been quite specific. It's ok to have binary modules as > long as they conform to the interface defined in /proc/ksyms. What is completely unclear is if he has the authority to say that given that there is code from other people including the FSF merged into the tree. He said it long enough ago that presumably people who merged code in would have accepted it as an implicit agreement, if it had been documented in the COPYING file. Unfortuantely, it wasn't so documented, so I agree it's unclear. I've taken to telling folks who ask about binary modules to talk to their legal department. The whole question is simply to complicated for anyone else to work on. ... and at that point we run intothe oft-debated (but never tested in a court of law) question of into the whether or not Copyright can infect across a link, especially since the link is done by the end-user. (Yes, there are some questions about inline functions in the header files.) The intent of what the FSF would like the case to be is clear, but it's not clear at all that Copyright law works that way; intent doesn't matter if the laws don't give you the right to sue on those grounds. See a lawyer and get official legal advice indeed - Ted - 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: Module open() problems, Linux 2.4.0
In article <[EMAIL PROTECTED]> you wrote: > This may be, as you say, "harmless". It is, however, a bug. The > reporting must be correct or large complex systems can't be > developed or maintained. No. It is not. The module usage count doesn't have a direct relation to the number of open devices. The module count just makes the modules un-removable if it is non-zero. It doesn't matter at all, when and where you in- and decrease it, as long as the module is always protected against unload when in use (e.g. opened). Christoph -- Always remember that you are unique. Just like everyone else. - 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/
[PATCH] generate man pages from inline documentation
Hi Linus,
this patch adds some infrastructure and modifies scripts/kernel-doc to
support generating man pages from the inline documentation.
Please apply (for all the poeple that prefer man pages over sgml)
Christoph
P.S. it does also removed an older stub for this that slipped in some
time ago.
--
Always remember that you are unique. Just like everyone else.
diff -uNr --exclude-from=dontdiff linux-2.4.0t11p1/Documentation/DocBook/Makefile
linux/Documentation/DocBook/Makefile
--- linux-2.4.0t11p1/Documentation/DocBook/Makefile Thu Oct 19 13:21:14 2000
+++ linux/Documentation/DocBook/MakefileThu Nov 9 21:50:26 2000
@@ -82,11 +82,6 @@
$(TOPDIR)/scripts/docgen $(APISOURCES) \
kernel-api.sgml
-kernel-api-man: $(APISOURCES)
- @rm -rf $(TOPDIR)/Documentation/man
- $(TOPDIR)/scripts/kernel-doc -man $^ | \
- $(PERL) $(TOPDIR)/scripts/split-man $(TOPDIR)/Documentation/man
-
parportbook: $(JPG-parportbook)
parportbook.ps: $(EPS-parportbook)
parportbook.sgml: parportbook.tmpl $(TOPDIR)/drivers/parport/init.c
diff -uNr --exclude-from=dontdiff linux-2.4.0t11p1/Makefile linux/Makefile
--- linux-2.4.0t11p1/Makefile Thu Nov 9 15:50:14 2000
+++ linux/Makefile Thu Nov 9 21:50:26 2000
@@ -82,6 +82,13 @@
export MODLIB
#
+# MANPATH specifies where to install the manpages created from
+# inline documentation
+#
+
+MANDIR := /usr/share/man
+
+#
# standard CFLAGS
#
@@ -371,6 +378,7 @@
rm -f net/khttpd/times.h
rm -f submenu*
rm -rf modules
+ rm -rf Documentation/man
$(MAKE) -C Documentation/DocBook clean
mrproper: clean archmrproper
@@ -421,6 +429,25 @@
htmldocs: sgmldocs
$(MAKE) -C Documentation/DocBook html
+
+mandocs:
+ @rm -rf $(TOPDIR)/Documentation/man
+ chmod 755 $(TOPDIR)/scripts/kernel-doc
+ chmod 755 $(TOPDIR)/scripts/split-man
+ ( \
+ find include/asm-$(ARCH) -name '*.h' -print; \
+ find $(SUBDIRS) init -name '*.c' -print; \
+ find include -type d \( -name "asm-*" -o -name config \) \
+ -prune -o -name '*.h' -print \
+ ) | xargs $(TOPDIR)/scripts/kernel-doc | \
+ $(TOPDIR)/scripts/split-man \
+ $(TOPDIR)/Documentation/man
+
+install-man: mandocs
+ test -d $(MANDIR)/man9 || mkdir -p $(MANDIR)/man9
+ cp $(TOPDIR)/Documentation/man/*.9 $(MANDIR)/man9
+
+
sums:
find . -type f -print | sort | xargs sum > .SUMS
diff -uNr --exclude-from=dontdiff linux-2.4.0t11p1/scripts/kernel-doc
linux/scripts/kernel-doc
--- linux-2.4.0t11p1/scripts/kernel-doc Wed Oct 18 15:54:06 2000
+++ linux/scripts/kernel-docThu Nov 9 22:04:55 2000
@@ -537,7 +537,7 @@
my ($parameter, $section);
my $count;
-print ".TH \"$args{'module'}\" 4 \"$args{'function'}\" \"25 May 1998\" \"API
Manual\" LINUX\n";
+print ".TH \"$args{'function'}\" 9 \"$args{'function'}\" \"25 May 1998\" LINUX\n";
print ".SH NAME\n";
print $args{'function'}." \\- ".$args{'purpose'}."\n";
@@ -563,13 +563,13 @@
$parenth = "";
}
-print ".SH Arguments\n";
+print ".SH ARGUMENTS\n";
foreach $parameter (@{$args{'parameterlist'}}) {
print ".IP \"".$parameter."\" 12\n";
output_highlight($args{'parameters'}{$parameter});
}
foreach $section (@{$args{'sectionlist'}}) {
- print ".SH \"$section\"\n";
+ print ".SH \"", uc $section, "\"\n";
output_highlight($args{'sections'}{$section});
}
}
diff -uNr --exclude-from=dontdiff linux-2.4.0t11p1/scripts/split-man
linux/scripts/split-man
--- linux-2.4.0t11p1/scripts/split-man Thu Jan 1 01:00:00 1970
+++ linux/scripts/split-man Thu Nov 9 21:50:26 2000
@@ -0,0 +1,33 @@
+#!/usr/bin/perl
+#
+# split-man: create man pages from kernel-doc -man output
+#
+# Author: Tim Waugh <[EMAIL PROTECTED]>
+# Modified by: Christoph Hellwig <[EMAIL PROTECTED]>
+#
+
+use strict;
+
+die "$0: where do I put the results?\n" unless ($#ARGV >= 0);
+die "$0: can't create $ARGV[0]: $!\n" unless mkdir $ARGV[0], 0777;
+
+my $state = 0;
+
+while () {
+ s/(\w+)/\\fB\1\\fP/g; # fix smgl uglinesses
+ s/\$(\w+)/\\fI\1\\fP/g;
+ if (/^\.TH \"[^\"]*\" 9 \"([^\"]*)\"/) {
+ close OUT unless ($state++ == 0);
+ my $fn = "$ARGV[0]/$1.9";
+ if (open OUT, ">$fn") {
+ print STDERR "creating $fn\n";
+ } else {
+ die "can't open $fn: $!\n";
+ }
+ print OUT $_;
+ } elsif ($state != 0) {
+ print OUT $_;
+ }
+}
+
+close OUT;
-
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: Errors in 2.4-test11 build
"J . A . Magallon" <[EMAIL PROTECTED]> writes: > Trying to build 2.4.0-test11-pre1 I get the following: > > make[1]: Entering directory `/usr/src/linux-2.4.0-test11/arch/i386/kernel' > kgcc -D__ASSEMBLY__ -D__KERNEL__ -I/usr/src/linux/include -traditional -c > trampoline.S -o trampoline.o > gcc: installation problem, cannot exec `tradcpp0': No such file or directory > make[1]: *** [trampoline.o] Error 1 > My egcs does not have a -traditional cpp (Mandrake 7.2, packages egcs and > egcs-cpp). sorry this is an error with the egcs package can you upgrade to these packages : ftp://ftp.chmouel.org/pub/people/chmou/kgcc/ and let me know if it's work for you (it does for me) and will do an update soon. -- MandrakeSoft Inc http://www.chmouel.org --Chmouel - 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: Module open() problems, Linux 2.4.0
On Thu, 9 Nov 2000, Brian Gerst wrote: > "Richard B. Johnson" wrote: > > > > `lsmod` shows that a device is open twice when using Linux-2.4.0-test9 > > when, in fact, it has been opened only once. > > > > > > When the module is closed, the use-count goes to zero as expected. > > However, a single open() causes the use-count to be 2. > > This is harmless. It is caused by a try_inc_mod_count(module) in the > function calling device_open(), which is the proper way for module > locking to be handled when not holding the BKL. You can keep the > MOD_INC_USE_COUNT in the device driver for compatability with 2.2. > > Brian Gerst This may be, as you say, "harmless". It is, however, a bug. The reporting must be correct or large complex systems can't be developed or maintained. I had two persons, working nearly a week, trying to find out what one of over 200 processes had a device open when only one was supposed to have it opened. --Err we have to check our work here. The fact that something "works" is not sufficient. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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/
Subcribe
Subcribe
Re: ping -f kills ne2k (was:[patch] NE2000)
Jorge Nerin wrote: > > Paul Gortmaker wrote: > > > > > > > > Well, I have tried it with 2.4.0-test10, both SMP and non-SMP, and the > > > result is a little confusing. > > > > > > Under SMP a ping -s 5 -f other_host takes down the network access > > > with no messages (ne2k-pci), and no possibility of being restored > > > without a reboot. > > > > > > Under UP the same command works ok, but after a while the dots stop for > > > 30sec, then ping prints an 'E' and the dots continue. strace revealed > > > this: > > > > Another suggestion - if you have your heart set on using ping > > as your network stress tool, you may want to try using multiple > > instances of MTU sized pings versus a single "ping -s 5". > > In this way you aren't involving any IP frag code and its associated > > bean counting - giving us one less factor to consider. > > > > Oh, and since you get a silent failure, maybe you would be interested > > in testing this patch I was (originally) saving for 2.5.x. -- It adds > > watchdog transmit timeout functionality to 8390.c (which is used by > > the ne2k-pci driver). Last time I updated it was a couple of months > > ago, but nothing has changed since then. > > > > Paul. > > > > Tested with ping -f -s 1400 (1400 in order not to reach 1500) > It took about half an hour and more than one million packets, but I > finally took the net down, with 12 concurrent pings. > > To eliminate factors I have deleted all the NAT rules wich gave messages > about dropped packets, and unloaded all the iptables modules. > > I have to make the test without the test check in sock_wait_for_wmem: > if ((current->state & (TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE)) > == 0) > BUG(); > > Because as I said in a previous msg it gave me BUG()s very early in the > tests, and I still had network access. > > If someone has a better sugestion as a nic stress tool I can try it, but > now I only have two ways of reaching this limits, ping -f of big > packets, and sometimes (only 4 or 5) during a copy of a large file over > NFS, but it's not a easy way to cause this. > > -- > Jorge Nerin > <[EMAIL PROTECTED]> Well, now it's kernel 2.4.0-test11-pre1 + 8390nmi, and the same conditions, about 8 pings concurrent, and this time it took only 202k packets to take the ne2k-pci down, but this time the watchdog says: Nov 9 16:00:52 quartz kernel: NETDEV WATCHDOG: eth0: transmit timed out Nov 9 16:00:52 quartz kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=1792. Nov 9 16:00:54 quartz kernel: NETDEV WATCHDOG: eth0: transmit timed out Nov 9 16:00:54 quartz kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=117. Nov 9 16:00:56 quartz kernel: NETDEV WATCHDOG: eth0: transmit timed out Nov 9 16:00:56 quartz kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=117. Nov 9 16:00:58 quartz kernel: NETDEV WATCHDOG: eth0: transmit timed out Nov 9 16:00:58 quartz kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=117. Nov 9 16:01:00 quartz kernel: NETDEV WATCHDOG: eth0: transmit timed out Nov 9 16:01:00 quartz kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=117. Nov 9 16:01:02 quartz kernel: NETDEV WATCHDOG: eth0: transmit timed out Nov 9 16:01:02 quartz kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=117. And never comes alive again. -- Jorge Nerin <[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/
Problems with NFS in 2.4test10
Hi, First a description of my machine: I use a Dual Celeron System with glibc-2.1.3 and linux-2.4test10 . For information on peripherial devices I give the output of /proc/pci PCI devices found: Bus 0, device 0, function 0: Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 2). Master Capable. Latency=64. Prefetchable 32 bit memory at 0xe000 [0xe3ff]. Bus 0, device 1, function 0: PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 2). Master Capable. Latency=64. Min Gnt=128. Bus 0, device 7, function 0: ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 2). Bus 0, device 7, function 1: IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1). Master Capable. Latency=64. I/O at 0xf000 [0xf00f]. Bus 0, device 7, function 2: USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1). IRQ 19. Master Capable. Latency=64. I/O at 0xe000 [0xe01f]. Bus 0, device 7, function 3: Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 2). Bus 0, device 8, function 0: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS) (rev 0). IRQ 16. I/O at 0xe400 [0xe41f]. Bus 0, device 11, function 0: VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+] (rev 0). Non-prefetchable 32 bit memory at 0xe500 [0xe57f]. I have another computer (a K6) which is used as NFS server (running Universal NFS Server 2.2beta41 under glibc-2.0.7 and linux-2.2.16 ) I try to Encode WAV files to MP3s, which are both hosted on the K6. The files are located on a ReiserFS partition, which is mounted via NFS from the Dual Celeron. My Dual Celeron locks up regularily during this operation. The encoding process simply stops and the whole computer locks up. (No pinging possible). I first suspected that it had something to do with the Kernel NFS _Server_ which I use on the Dual Celeron, but since in this case the Dual Celeron acts as client, this shouldn't be the reason right ? Any Ideas how to track down this problem (like putting some printk's in strategically important locations ?) so long Ingo PS: I might be a hardware problem, since dual Celerons should be impossible... But i do a lot of compiling on this machine and it never locked up, or threw errors during compiling. So I suspect it isn't the hardware. - 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: B/W G3 - big IDE problems with 2.4.0-test10
On Thu, 9 Nov 2000, Benjamin Herrenschmidt wrote: > Did you try the bitkeeper PPC kernel ? (or Paul Mackerras rsync tree ?) Tried linuxcare's PPC kernel tree (fetched via rsync) and it is working. Some changes had to be dealt with, but I'm sorting this stuff out. I've discovered that I shouldn't use DRI. :) Also, with 2.4.0-test10, in 16bpp depth, I get weird white pixels on solid color areas. 24bpp mode takes care of it. Derrik Pates | Sysadmin, Douglas School|_ #linuxOS on EFnet [EMAIL PROTECTED] | District (dsdk12.net) | | | and now OPN too! Student @ South Dakota School of Mines | __| |___ _ _ _ ___ _ _ & Technology (www.sdsmt.edu) |/ _ / -_) ' \ '\/ _ \ ' \ () UNIX: Because you want to USE your computer.|\___,\___|_||_||_\___/_||_| - 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/
Missing ACKs with Linux 2.2/2.4?
Hi, I've been experiencing some very strange network behaviour under various versions of Linux, which can be provoked by just sending small amounts of data to the echo port on a server. The server is a Cobalt RAQ-3i (AMD-K6, kernel claims to be 2.2.12C3) While I can only recreate the behaviour using this as a server, tcp dumps of the network traffic seem to point the finger of blame at Linux when it is a client. The client machines are running 'cat text | nc cobalt-box 7'. "Text" is a 8679 byte file. The problem: several versions of the Linux kernel seem to be not sending ACKs correctly to the server, causing a three second delay in reading the text file back from the echo port. Other UNIX platforms get the data back instantly (I've tried Solaris, FreeBSD, Digital UNIX and IRIX). Linux 2.0.36 doesn't seem to show the problem. Linux 2.2.5, 2.2.13, 2.4.0-test10 do. Heres a trace of the problem: the client here, hydra, is a Redhat 6 box, with a 2.2.5 kernel. (tcpdump running on hydra) 10:10:15.842522 hydra.3700 > cobalt-box.echo: S 2004401205:2004401205(0) win 32120 (DF) 10:10:15.842703 cobalt-box.echo > hydra.3700: S 605846935:605846935(0) ack 2004401206 win 32120 (DF) 10:10:15.842744 hydra.3700 > cobalt-box.echo: . ack 1 win 32120 (DF) 10:10:15.843688 hydra.3700 > cobalt-box.echo: . 1:1449(1448) ack 1 win 32120 (DF) 10:10:15.844251 cobalt-box.echo > hydra.3700: . ack 1449 win 31856 (DF) 10:10:15.844299 hydra.3700 > cobalt-box.echo: . 1449:2897(1448) ack 1 win 32120 (DF) 10:10:15.844310 hydra.3700 > cobalt-box.echo: . 2897:4345(1448) ack 1 win 32120 (DF) 10:10:15.845002 cobalt-box.echo > hydra.3700: P 1:1449(1448) ack 1449 win 31856 (DF) 10:10:15.845050 hydra.3700 > cobalt-box.echo: . ack 1 win 32120 (DF) 10:10:15.845009 cobalt-box.echo > hydra.3700: . ack 4345 win 30408 (DF) 10:10:15.845076 hydra.3700 > cobalt-box.echo: . 4345:5793(1448) ack 1 win 32120 (DF) 10:10:15.845090 hydra.3700 > cobalt-box.echo: . 5793:7241(1448) ack 1 win 32120 (DF) 10:10:15.845101 hydra.3700 > cobalt-box.echo: FP 7241:8680(1439) ack 1 win 32120 (DF) 10:10:15.845773 cobalt-box.echo > hydra.3700: P 1449:2897(1448) ack 4345 win 31856 (DF) 10:10:15.845820 hydra.3700 > cobalt-box.echo: . ack 1 win 32120 (DF) 10:10:15.845780 cobalt-box.echo > hydra.3700: . ack 7241 win 30408 (DF) 10:10:15.845869 cobalt-box.echo > hydra.3700: . ack 8681 win 30408 (DF) 10:10:18.836367 cobalt-box.echo > hydra.3700: P 1:1449(1448) ack 8681 win 31856 (DF) 10:10:18.836421 hydra.3700 > cobalt-box.echo: . ack 1449 win 31856 (DF) 10:10:18.836961 cobalt-box.echo > hydra.3700: P 1449:2897(1448) ack 8681 win 31856 (DF) 10:10:18.844490 hydra.3700 > cobalt-box.echo: . ack 2897 win 31856 (DF) 10:10:18.845024 cobalt-box.echo > hydra.3700: P 2897:4345(1448) ack 8681 win 31856 (DF) 10:10:18.845148 cobalt-box.echo > hydra.3700: P 4345:5793(1448) ack 8681 win 31856 (DF) 10:10:18.845202 hydra.3700 > cobalt-box.echo: . ack 5793 win 30408 (DF) 10:10:18.845280 cobalt-box.echo > hydra.3700: P 5793:7241(1448) ack 8681 win 31856 (DF) 10:10:18.845400 cobalt-box.echo > hydra.3700: FP 7241:8680(1439) ack 8681 win 31856 (DF) 10:10:18.845446 hydra.3700 > cobalt-box.echo: . ack 8681 win 28960 (DF) 27 packets received by filter 0 packets dropped by kernel Note the three second delay! From my reading of this, hydra never ACKs any of the data received from the server prior to the delay. Only when the server re-sends the first 1448 bytes after a three second timeout, does it decide to ACK it. hydra does however seem to send out two identical 'ack 1' packets. Has the second one got the wrong number in it? Any ideas whats going on? I'm no expert at reading tcpdumps, if anyone can shed some light on the problem, I'd be most greatful. Cheers, Ben - 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: Module open() problems, Linux 2.4.0
"Richard B. Johnson" wrote:
>
> `lsmod` shows that a device is open twice when using Linux-2.4.0-test9
> when, in fact, it has been opened only once.
>
> lsmod is version 2.3.15, the latest-and-greatest.
>
> Here are the open/close routines for a module.
>
> /*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
> /*
> * Open the device.
> */
> static int device_open(struct inode *inp, struct file *fp)
> {
> DEB(printk("%s open\n", info->dev));
> MOD_INC_USE_COUNT; /* Increment usage count */
> return 0;
> }
> /*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
> /*
> * Close the device.
> */
> static int device_close(struct inode *inp, struct file *fp)
> {
> DEB(printk("%s close\n", info->dev));
> MOD_DEC_USE_COUNT; /* Decrement usage count */
> return 0;
> }
>
> When the module is closed, the use-count goes to zero as expected.
> However, a single open() causes the use-count to be 2.
This is harmless. It is caused by a try_inc_mod_count(module) in the
function calling device_open(), which is the proper way for module
locking to be handled when not holding the BKL. You can keep the
MOD_INC_USE_COUNT in the device driver for compatability with 2.2.
--
Brian Gerst
-
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/
Module open() problems, Linux 2.4.0
`lsmod` shows that a device is open twice when using Linux-2.4.0-test9
when, in fact, it has been opened only once.
lsmod is version 2.3.15, the latest-and-greatest.
Here are the open/close routines for a module.
/*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
/*
* Open the device.
*/
static int device_open(struct inode *inp, struct file *fp)
{
DEB(printk("%s open\n", info->dev));
MOD_INC_USE_COUNT; /* Increment usage count */
return 0;
}
/*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
/*
* Close the device.
*/
static int device_close(struct inode *inp, struct file *fp)
{
DEB(printk("%s close\n", info->dev));
MOD_DEC_USE_COUNT; /* Decrement usage count */
return 0;
}
When the module is closed, the use-count goes to zero as expected.
However, a single open() causes the use-count to be 2.
In a possibly-related observation, during the change-root from
an initial RAM disk to the root file system during boot, the
d_count used to be reported as '1'. It is now '3'.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
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: Persistent module storage - modutils design
On Tue, Nov 07, 2000 at 01:55:59PM +, Alan Cox wrote: > > Note! This _has_ to be in the / filesystem so it works before mounting the > > rest of the stuff (if ever). This would rule out /var, and leave just > > /lib/modules/. Makes me quite unhappy... > > The /lib filesystem is likely not writable so /var is the right default. In theory yes. In practice /var is often a mounted filesyste so for modules loaded before /var is mounted this solution gets somewhat ugly. Ralf - 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: [BUG] /proc//stat access stalls badly for swapping process,2.4.0-test10
As to the real reason for stalls on /proc//stat, I bet it has nothing
to do with IO except indirectly (the IO is necessary to trigger the
problem, but the _reason_ for the problem lies elsewhere).
And it has everything to do with the fact that the way Linux semaphores
are implemented, a non-blocking process has a HUGE advantage over a
blocking one. Linux kernel semaphores are extreme unfair in that way.
What happens is that some process is getting a lot of VM faults and gets
its VM semaphore. No contention yet. it holds the semaphore over the
IO, and now another process does a "ps".
The "ps" process goes to sleep on the semaphore. So far so good.
The original process releases the semaphore, which increments the count,
and wakes up the process waiting for it. Note that it _wakes_ it, it does
not give the semaphore to it. Big difference.
The process that got woken up will run eventually. Probably not all that
immediately, because the process that woke it (and held the semaphore)
just slept on a page fault too, so it's not likely to immediately
relinquish the CPU.
The original running process comes back faulting again, finds the
semaphore still unlocked (the "ps" process is awake but has not gotten to
run yet), gets the semaphore, and falls asleep on the IO for the next
page.
The "ps" process actually gets to run now, but it's a bit late. The
semaphore is locked again.
Repeat until luck breaks the bad circle.
(This schenario, btw, is much harder to trigger on SMP than on UP. And
it's completely separate from the issue of simple disk bandwidth issues
which can obviously cause no end of stalls on anything that needs the
disk, and which can also happen on SMP).
NOTE! If somebody wants to fix this, the fix should be reasonably simple
but needs to be quite exhaustively checked and double-checked. It's just
too easy to break the semaphores by mistake.
The way to make semaphores more fair is to NOT allow a new process to just
come in immediately and steal the semaphore in __down() if there are other
sleepers. This is most easily accomplished by something along the lines of
the following in __down() in arch/i386/kernel/semaphore.c
spin_lock_irq(_lock);
sem->sleepers++;
+
+ /*
+* Are there other people waiting for this?
+* They get to go first.
+*/
+ if (sleepers > 1)
+ goto inside;
for (;;) {
int sleepers = sem->sleepers;
/*
* Add "everybody else" into it. They aren't
* playing, because we own the spinlock.
*/
if (!atomic_add_negative(sleepers - 1, >count)) {
sem->sleepers = 0;
break;
}
sem->sleepers = 1; /* us - see -1 above */
+inside:
spin_unlock_irq(_lock);
schedule();
tsk->state = TASK_UNINTERRUPTIBLE|TASK_EXCLUSIVE;
spin_lock_irq(_lock);
}
spin_unlock_irq(_lock);
But note that teh above is UNTESTED and also note that from a throughput
(as opposed to latency) standpoint being unfair tends to be nice.
Anybody want to try out something like the above? (And no, I'm not
applying it to my tree yet. It needs about a hundred pairs of eyes to
verify that there isn't some subtle "lost wakeup" race somewhere).
Linus
-
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: Installing kernel 2.4
On Thu, 09 Nov 2000, David Woodhouse wrote: > [EMAIL PROTECTED] said: > > I think a default whereby the kernel built will run on any > > Linux-capable machine of that architecture would be sensible - so if I > > grab the 2.4.0t10 tarball and build it now, with no changes, I'll be > > able to boot the kernel on any x86 machine. > > I have four machines on my desk at the moment. The workstation is a dual > P-III. I suppose I agree that it might be nice if the kernel for that also > worked on the embedded 386 board. But it'd also be nice if it worked on the > Alpha and the SH boards which are also on my desk. How about putting the > whole lot into a single kernel image? It's the logical extension of what's > being suggested. No. In the x86 case, it is a question of "do we deliberately restrict this kernel to running only on a Pentium II in order to make it x% faster". My suggestion does not duplicate any code, or (with a few exceptions) include any redundant code for any platform (maths emulation, e.g., would be an exception). Yours duplicates code, rather than just not optimising it as aggressively. James. - 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: [patch] NE2000
Hi,
I have to own up and say that it was me :-) you'll see that DECnet is the
only protocol to use these macros at the moment. I'm sure though that I
only copied what IPv4 was doing at the time, along with the hints I had
from yourself and Dave,
Steve.
>
> Hello!
>
> > Alexey! Even someone understood all this already, look
> > to include/net/sock.h SOCK_SLEEP_{PRE,POST} macros :-)
> >
> > I will compose a patch to fix all this.
>
> O! But who was this wiseman? 8)
>
> Alexey
> -
> 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/
Re: test9: running tasks not in run-queue
"David S. Miller" wrote: > >Date:Wed, 8 Nov 2000 15:11:49 -0800 >From: Mike Kravetz <[EMAIL PROTECTED]> > >The following code in __wake_up_common() is then >executed: > >if (best_exclusive) >best_exclusive->state = TASK_RUNNING; >wq_write_unlock_irqrestore(>lock, flags); > > test10 fixes this error, now it sets TASK_RUNNING and > adds the task back to the runqueue all under the runqueue > lock. In our preemptable kernel work we often put (or leave) tasks on the run queue that are not in state TASK_RUNNING and want to treat them as if they are in state TASK_RUNNING. We thus changed the test in schedule() to "task_on_runqueue(prev)" George - 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: [patch] NE2000
Hello!
> Alexey! Even someone understood all this already, look
> to include/net/sock.h SOCK_SLEEP_{PRE,POST} macros :-)
>
> I will compose a patch to fix all this.
O! But who was this wiseman? 8)
Alexey
-
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: Porting Linux v2.2.x Ethernet driver to v2.4.x?
...and the attached document, referred to in the previous mail. :) I think I posted this recently, but it's small so a repost is no big deal. -- Jeff Garzik | Building 1024 | Would you like a Twinkie? MandrakeSoft| Network Devices, the Kernel, and You! Introduction The following is a random collection of documentation regarding network devices. struct net_device synchronization rules === dev->open: Locking: Inside rtnl_lock() semaphore. Sleeping: OK dev->stop: Locking: Inside rtnl_lock() semaphore. Sleeping: OK dev->do_ioctl: Locking: Inside rtnl_lock() semaphore. Sleeping: OK dev->get_stats: Locking: Inside dev_base_lock spinlock. Sleeping: NO dev->hard_start_xmit: Locking: Inside dev->xmit_lock spinlock. Sleeping: NO dev->tx_timeout: Locking: Inside dev->xmit_lock spinlock. Sleeping: NO dev->set_multicast_list: Locking: Inside dev->xmit_lock spinlock. Sleeping: NO
RE: Porting Linux v2.2.x Ethernet driver to v2.4.x?
Search the lkml archives. Here are 2 instances to find: from jamal, 2000-jan-6: [ANNOUNCE] SOFTNETing Network Drivers HOWTO from kuznet, 2000-feb-14: "softnet" drivers: an attempt to clarify from dave miller, 2000-feb-9: new network driver interface changes, README http://www.uwsg.indiana.edu/hypermail/linux/kernel/0002.1/0408.html from jamal, 2000-feb-10: ditto http://www.uwsg.indiana.edu/hypermail/linux/kernel/0002.1/0461.html from dave miller, 2000-feb-12: ditto ___ |randy.dunlap_at_intel.com503-677-5408| |NOTE: Any views presented here are mine alone| |& may not represent the views of my employer.| --- > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, November 09, 2000 10:01 AM > To: [EMAIL PROTECTED] > Subject: Porting Linux v2.2.x Ethernet driver to v2.4.x? > > > > > Hello. > > I am about to modify a Linux v2.2.x-compatible Ethernet > driver to allow it to > work in the new v2.4.x kernel. Are there any documents which > describe the > differences in the device driver models (particularly PCI and > Ethernet) of the 2 > kernel versions? If so, where can I find them? > > Thank you. > > (Sorry about the advertisement below.) > > > > > PLANET PROJECT will connect millions of people worldwide > through the combined > technology of 3Com and the Internet. Find out more and register now at > http://www.planetproject.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/
Re: Porting Linux v2.2.x Ethernet driver to v2.4.x?
[EMAIL PROTECTED] wrote: > > Hello. > > I am about to modify a Linux v2.2.x-compatible Ethernet driver to allow it to > work in the new v2.4.x kernel. Are there any documents which describe the > differences in the device driver models (particularly PCI and Ethernet) of the 2 > kernel versions? If so, where can I find them? Not all in one place. Read: Documentation/pci.txt Documentation/DMA-mapping.txt Documentation/IO-mapping.txt and the attached document, regarding netdevice member locking rules. Your best reference is other PCI ethernet drivers. grep for 'pci_module_init' in drivers/net/*.c of the most recent 2.4.x kernel, for a good start. Also... before you start thinking about gunking-up your driver with all sorts of backwards-compatibility code... remember that most 2.4.x drivers can easily be backported to 2.2.x with a few magic macros and static inline functions. I have an example of this sort of thing at http://gtf.org/garzik/drivers/kcompat24/ Jeff -- Jeff Garzik | Building 1024 | Would you like a Twinkie? MandrakeSoft| - 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: PATCH: rd - deadlock removal
On Thu, 9 Nov 2000, Jens Axboe wrote: > > > The second is more elegant in that it side steps the problem by > > giving rd.c a make_request function instead of using the default > > _make_request. This means that io_request_lock is simply never > > claimed my rd. > > And this solution is much better, even given the freeze I think that > is the way to go. I agree, I already applied it. The second approach just makes the problem go away, and also avoids needlessly merging the request etc. I suspect that the lack of request-merging could also eventually be used to simplify the driver a bit, as it now wouldn't need to worry about that issue any more at all. Linus - 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/
Porting Linux v2.2.x Ethernet driver to v2.4.x?
Hello. I am about to modify a Linux v2.2.x-compatible Ethernet driver to allow it to work in the new v2.4.x kernel. Are there any documents which describe the differences in the device driver models (particularly PCI and Ethernet) of the 2 kernel versions? If so, where can I find them? Thank you. (Sorry about the advertisement below.) PLANET PROJECT will connect millions of people worldwide through the combined technology of 3Com and the Internet. Find out more and register now at http://www.planetproject.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/
Re: getting a process name from task struct
Chris Swiedler wrote: > > Is it possible to get a process's name / full execution path (from > kernelspace) given only a task struct? I can't find any pointers to this > information in the task struct, and I don't know where else it might be. ps > seems to be able to get the process name, but that's from userspace. > Apologies in advance if this is a stupid question. > > chris > Try the "comm" member of task_struct. (Clear name, right?) George - 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/
getting a process name from task struct
Is it possible to get a process's name / full execution path (from kernelspace) given only a task struct? I can't find any pointers to this information in the task struct, and I don't know where else it might be. ps seems to be able to get the process name, but that's from userspace. Apologies in advance if this is a stupid question. chris - 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: catch 22 - porting net driver from 2.2 to 2.4
do_ioctl is inside rtnl_lock... Remember if you need to alter the rules, you can always queue work in the current context, and have a kernel thread handle the work. The nice thing about a kernel thread is that you start with a [almost] clean state, when it comes to locks. Jeff -- Jeff Garzik | Building 1024 | Would you like a Twinkie? MandrakeSoft| - 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: OOPS loading cs46xx module, test11-pre1
Christoph Hellwig wrote:
>
> On Thu, Nov 09, 2000 at 12:02:45PM -0500, Jeff Garzik wrote:
> > > I have an (untested) update for the cs46xx driver in Linux 2.4.
> > > It includes Nils' 2.2 changes, use of initcalls (so compiled-in
> > > should work) and use of the 2.4 PCI interface.
> >
> > Patch Generally looks ok. Comments:
> >
> > 1) This code is weird:
> > >if (copy_to_user(buffer, dmabuf->rawbuf + swptr, cnt)) {
> > >- if (!ret) ret = -EFAULT;
> > >- return ret;
> > >+ if (!ret)
> > >+ ret = -EFAULT;
> > >+ break;
> > >}
> >
> > If you have an error condition (ret != 0), then you should not attempt
> > the copy_to_user at all.
> > If you do not have an error condition, you should unconditionally assign
> > -EFAULT to 'ret'.
>
> Makes sense. But I did not change the logic at all ...
> Ask the Author (Alan or Nils) what this is about.
Now that I have looked at the code around it, it looks ok. It returns
the bytes copied to userspace so far, like a good read function should.
> > 6) remove check for pci_present(), redundant
>
> Lot's of pci drivers do this. Anyway I will removed this in the next version.
It's been redundant since the 2.1.x days, maybe even before that. There
-might- be a rare case where a driver really needs to check for the
presence of a PCI BIOS. Maybe. But for all cases where you have
if (!pci_present()) probe_pci=0;
/* ... */
if (probe_pci) {
pci_register_driver(...)
or
pdev = pci_find_device(...);
}
you can remove the pci_present check. All PCI probe functions return
sane values in the absence of PCI support (or PCI devices).
> > of course for cs46xx, you will want to keep the version printk...
> >
> > 8) xxx_MODULE_NAME was a dumb and overly-lengthy creation of mine. Use
> > instead MODNAME.
>
> It doesn't really matter ...
besides perpetuating a bad idea, that is.
Jeff
--
Jeff Garzik |
Building 1024 | Would you like a Twinkie?
MandrakeSoft|
-
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/
catch 22 - porting net driver from 2.2 to 2.4
Hello, This is a bit long and I apologize (since there are kdb captures in it). We are developing an advanced networking services driver (loadable module) and are having problems porting it to work on 2.4.x kernel. The driver is supposed to provide services such as fault tolerance, load balancing, link aggregation and VLAN. It does that by creating a group of "virtual" adapters that are bound on top of a team of network adapters. This works great on 2.2 kernels but demonstrated a few problems on 2.4.0-test9 The only problem we have left now has to do with insmod/rmmod. for good reasons, we cant just call init_etherdev() like base drivers do, so we created our own version that handles memory and name allocations and calls register_netdevice() on it's own the same as init_etherdev(). since we've got several "virtual" adapters that are part of a topology being built progressively, we can't perform their registrations during module_init() but rather through an IOCTL and here is our problem: if we call register_netdevice(), we get the following message: RTNL: assertion failed at devinet.c(775):inetdev_event we figured this is because we neglected rtnl_lock() so instead we try using register_netdev() to handle this for us but then we get: Scheduling in interrupt kernel BUG at sched.c:696! Entering kdb (current=0xc51a8000, pid 1075) on processor 1 Panic: invalid operand due to panic @ 0xc011aa71 eax = 0x001b ebx = 0x0020 ecx = 0xc030d80c edx = 0x esi = 0xc030b5b4 edi = 0x esp = 0xc51a9d34 eip = 0xc011aa71 ebp = 0xc51a9d8c ss = 0x0018 cs = 0x0010 eflags = 0x00010246 ds = 0x0018 es = 0x0018 origeax = 0x = 0xc51a9d00 [1]kdb> bt EBP EIP Function(args) 0xc51a9d8c 0xc011aa71 schedule+0x935 (0xc2c9e000, 0xc4482520, 0xc51a9e10) kernel .text 0xc010 0xc011a13c 0xc011aa80 0xc51a9db8 0xc0107b8d __down+0xf5 kernel .text 0xc010 0xc0107a98 0xc0107c68 0xc51a9dcc 0xc0107f43 __down_failed+0xb (0xc51a9de4, 0xd082de5c, 0xc2c9e000, 0xc60a8320, 0xc51a9dfc) kernel .text 0xc010 0xc0107f38 0xc0107f4c 0xc023a7a9 stext_lock+0x4919 kernel .text.lock 0xc0235e90 0xc0235e90 0xc023bd80 0xc51a9dd4 0xc01f2e81 rtnl_lock+0x11 (0xc2c9e000) kernel .text 0xc010 0xc01f2e70 0xc01f2e88 0xc51a9de4 0xd082de5c [ians]iansInitEtherdev+0x20 (0xc4482520) ians .text 0xd082d060 0xd082de3c 0xd082de78 . . (boring chain of calls) . 0xc51a9ec4 0xd082dbcd [ians]doControlIoctl+0x15d (0xc2c9e200, 0xc51a9f20, 0x89f0) ians .text 0xd082d060 0xd082da70 0xd082dc40 0xc51a9ee4 0xc01ef09f dev_ifsioc+0x33f (0xc51a9f20, 0x89f0, 0xc51a9f20) kernel .text 0xc010 0xc01eed60 0xc01ef0b0 0xc51a9f40 0xc01ef29d dev_ioctl+0x1ed (0x89f0, 0xba58) kernel .text 0xc010 0xc01ef0b0 0xc01ef300 0xc51a9f64 0xc021a70c inet_ioctl+0x18c (0xc339d13c, 0x89f0, 0xba58) kernel .text 0xc010 0xc021a580 0xc021a720 0xc51a9f84 0xc01e8f06 sock_ioctl+0x9e (0xc339d040, 0xc38e0900, 0x89f0, 0xba58) kernel .text 0xc010 0xc01e8e68 0xc01e8f6c 0xc51a9fbc 0xc014f5fd sys_ioctl+0x26d (0x3, 0x89f0, 0xba58, 0x4000ae60, 0xbba4) kernel .text 0xc010 0xc014f390 0xc014f6a0 0xc010965f system_call+0x33 kernel .text 0xc010 0xc010962c 0xc0109664 We figured that since we are in user context (do_ioctl) and use spin_lock_bh() to protect us from other concurrent threads, it might interfere with rtnl_lock() so we remove our lock just before calling register_netdev() and lock again upon return but then the whole process just stopped and didn't return to the prompt. from within kdb, we could see that all CPU's are running in idle but if we try to return to the prompt the whole system hangs. sometimes it hangs if we try to run ifconfig -a to see if the virtual adapters appear. I can't use it without locks, I can't use it with locks and I can't complete the operation if I remove my own locks - catch 22. The other problem has to do with rmmod - here we get called in our cleanup_module function and from it we try to call unregister_netdev() for each registered virtual adapter. in this case, we get: Scheduling in interrupt kernel BUG at sched.c:696! Entering kdb (current=0xc38c8000, pid 1602) on processor 0 Panic:
Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
On 9 Nov 2000, Mike Coleman wrote: > Alexander Viro <[EMAIL PROTECTED]> writes: > > RMS had repeatedly demonstrated what he's worth as a designer > > and programmer. Way below zero. You may like or dislike his ideology, > > but when it comes to technical stuff... Not funny. > > Huh? > > > > *Hello*? GNU gcc? GNU emacs? Way below zero? *Hello*?!? > > Yes. GNU emacs. Bloated and ugly like hell. gcc. Codebase is anything but pretty. Your point being? And no, it's not trolling. RMS really got no taste - read his postings on _technical_ GNU lists and see yourself. Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. $DEITY witness, we've got enough ugly code, but compared to the average level of GNU codebase kernel looks wonderful. Sorry. I think that I've spent enough time dealing with both to be able to compare. - 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: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
Alexander Viro <[EMAIL PROTECTED]> writes: > RMS had repeatedly demonstrated what he's worth as a designer > and programmer. Way below zero. You may like or dislike his ideology, > but when it comes to technical stuff... Not funny. Huh? *Hello*? GNU gcc? GNU emacs? Way below zero? *Hello*?!? -- [O]ne of the features of the Internet [...] is that small groups of people can greatly disturb large organizations. --Charles C. Mann - 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: [bug] usb-uhci locks up on boot half the time
On Thu, Nov 09, 2000 at 09:06:31AM -0800, Dunlap, Randy wrote: > > Bus-powered != self-powered. > > Self-powered means that it has its own power cord. > > Bus-powered means that it gets its power from the USB cable. You're right, I used the wrong terms (but used the correct descriptions). I meant that "bus-powered" hubs are flaky and have problems, like Randy said. Sorry any confusion this might have caused. greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg - 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: OOPS loading cs46xx module, test11-pre1
On Thu, Nov 09, 2000 at 12:02:45PM -0500, Jeff Garzik wrote:
> > I have an (untested) update for the cs46xx driver in Linux 2.4.
> > It includes Nils' 2.2 changes, use of initcalls (so compiled-in
> > should work) and use of the 2.4 PCI interface.
>
> Patch Generally looks ok. Comments:
>
> 1) This code is weird:
> >if (copy_to_user(buffer, dmabuf->rawbuf + swptr, cnt)) {
> >- if (!ret) ret = -EFAULT;
> >- return ret;
> >+ if (!ret)
> >+ ret = -EFAULT;
> >+ break;
> >}
>
> If you have an error condition (ret != 0), then you should not attempt
> the copy_to_user at all.
> If you do not have an error condition, you should unconditionally assign
> -EFAULT to 'ret'.
Makes sense. But I did not change the logic at all ...
Ask the Author (Alan or Nils) what this is about.
> 2) this patch enabled cs_mmap, and removes a check for vma->vm_offset !=
> 0. Also that is clearly 2.2.x code, simply removing the check is
> wrong. You should replace the check with one that checks vma->vm_pgoff
> != 0.
Sorry, forgot to add this back in the patch I sent.
> 3) is there method or madness to the delay changes? they are not
> explained, just changed...
Not shure. This was accepted in 2.2.18pre, so it should be sane.
> 4) cs_probe is marked __init but cs_remove is marked __devexit. on
> hotplug, cs_probe simply doesn't exist in the kernel anymore... boom.
Ok, should be fixed.
> 5) there is no need to appear zeroes to the end of these cs_pci_tbl
> entries. Just end each with "PCI_ANY_ID,"...
> + { PCI_VENDOR_ID_CIRRUS, 0x6001, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0
> },
> + { PCI_VENDOR_ID_CIRRUS, 0x6003, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0
> },
> + { PCI_VENDOR_ID_CIRRUS, 0x6004, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0
> },
That's true. But i think it looks cleaner if all members are present.
> 6) remove check for pci_present(), redundant
Lot's of pci drivers do this. Anyway I will removed this in the next version.
> 7) use pci_module_init for hotplug. quite simply:
>
> init_module() { return pci_module_init(_driver); }
Ok.
> of course for cs46xx, you will want to keep the version printk...
>
> 8) xxx_MODULE_NAME was a dumb and overly-lengthy creation of mine. Use
> instead MODNAME.
It doesn't really matter ...
Christoph
--
Always remember that you are unique. Just like everyone else.
-
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/
Incorrectness for fun and profit
In 2.4 init/main.c we have... * Versions of gcc older than that listed below may actually compile * and link okay, but the end product can have subtle run time bugs. * To avoid associated bogus bug reports, we flatly refuse to compile * with a gcc that is known to be too old from the very beginning. */ #if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 1) #error Sorry, your GCC is too old. It builds incorrect kernels. #endif Note that I've elided the 9 from the minor version number. I also tweaked the #define asmlinkage in whereveritis.h to look a bit more like 2.2, got rid of the arch=bla switch to gcc, and built the kernel I'm using at the moment with gcc 2.7.2.3. I'm looking for "subtle run time bugs". OK, I'm desparate for entertainment. That's a given. Where should I look? Everything I'm cognizant of so far is real pretty. I WANT BUGS! WHERE ARE THE BUGS? This is not a bogus bug report. This is a repeatable bug request. Incorrectly yours, Rick Hohensee :; cLIeNUX0 /dev/tty12 12:43:36 / :;get /Linux/version Linux version 2.4.0-test10 (@cLIeNUX) (gcc version 2.7.2.3) #10 Thu Nov 9 03:11:45 2000 :; cLIeNUX0 /dev/tty12 13:03:02 / :; - 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: [bug] usb-uhci locks up on boot half the time
> From: David Ford [mailto:[EMAIL PROTECTED]] > [snip] > > Is the external hub a externally powered hub, or self > powered hub (does > > it get it's power from a plug in the wall, or from the USB > bus)? Self > > powered hubs are notoriously flaky and have been known to > > evil things to the USB bus. > > Either. Currently bus (self) powered. This hub has worked > fine on my other > computers without any adverse affect. Bus-powered != self-powered. Self-powered means that it has its own power cord. Bus-powered means that it gets its power from the USB cable. Unlike Greg, I would have said that bus-powered hubs can be a problem -- especially when you plug too many devices into them that need lots of power. What we saw at the USB PlugFest was hubs just shutting down when we did this. :( ~Randy - 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/
changelog
hi all, Sorry, but i could not find a more appropriate group list to post this on. my fault in anyways. I like to keep track of what is installed after each RPM or any other install command is performed. Like dates inatlled and who installed it, Like create a log of changes,... what is the command for it?. how do i incorporate the date and who command into with install command. J _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.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/
Re: why do we need pg1?
On Thu, 9 Nov 2000, Tigran Aivazian wrote: > Hi, > > The code which sets up the page table at pg0 (in head.S) goes all the way > until it hits empty_zero_page so I don't understand why we need the label > pg1 in between, since it is never referred to by any other code? > > Also, is the comment in asm/pgtable.h > > /* page table for 0-4MB for everybody */ > extern unsigned long pg0[1024]; > > true or false? Isn't it for 0-8M as head.S claims? after a minute of thought, the answer to the second question is now obvious, but the answer to the first one still is _not_. Regards, Tigran - 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: is there a limit on bss size?
On Fri, 6 Oct 2000, Philipp Rumpf wrote: > On Fri, Oct 06, 2000 at 12:32:35PM +0300, Petko Manolov wrote: > > It is not so difficult as it looks. > > I don't see it being difficult at all ... > > > The master pgd looking as: > > > > .org 0x1000 > > ENTRY(swapper_pg_dir) > > .long 0x00102007 > > .long 0x00103007 > > .fill BOOT_USER_PGD_PTRS-2,4,0 > > /* default: 766 entries */ > > .long 0x00102007 > > .long 0x00103007 > > /* default: 254 entries */ > > .fill BOOT_KERNEL_PGD_PTRS-2,4,0 > > > > > > should become: > > > > > > .org 0x1000 > > ENTRY(swapper_pg_dir) > > .long 0x00102007 > > .long 0x00103007 > > # every entry addresses 4 MB exactly > > # so add as much as you want > > .long 0x0010X007 > > .fill BOOT_USER_PGD_PTRS-X+2,4,0 > > I'm unconvinced we need to map more than 4 MB into low virtual addresses; > nothing seems to break with > > ENTRY(swapper_pg_dir) > .long 0x00102007 > .fill BOOT_USER_PGD_PTRS-1,4,0 > Hi Phillip, Ah, _now_ I understand what you are talking about (took me only slightly over a month ;) and so can answer -- try making a huge bzImage (a few megs) and boot with it. That was the main reason Werner added the extra stuff somewhere around 2.3.99-preX. Having said that, I still don't see why we actually need a specific label (like pg1) for each successive page worth of pte's if we are filling them with data starting from pg0 until we hit empty_zero_page (as I asked in my other message). Regards, Tigran PS. I cc'd the guy who was looking to extend the page tables for booting with huge bss also... - 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: PCI-PCI bridges mess in 2.4.x
> It was posted to lkml, so no link (except if you want to dig through > lkml mail archives). It booted but then it oops'ed before userland I belive. I tried it this morning and didn't have much time. It did find the scsi controller (which is across the bridge) and the drives attached so it does appear to be working. Maybe they can add that patch in for test11pre2 (or 3 if 2 is already out) -- Lab tests show that use of micro$oft causes cancer in lab animals - 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: PCI-PCI bridges mess in 2.4.x
> It was posted to lkml, so no link (except if you want to dig through > lkml mail archives). It booted but then it oops'ed before userland I belive. I tried it this morning and didn't have much time. It did find the scsi controller (which is across the bridge) and the drives attached so it does appear to be working. Maybe they can add that patch in for test11pre2 (or 3 if 2 is already out) -- Lab tests show that use of micro$oft causes cancer in lab animals - 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/
[PATCH] Reserve VM for root (was: Re: Looking for better VM)
On Wed, 8 Nov 2000, Rik van Riel wrote:
> OK. This is a lot more reasonable.
Just the same what was in my first in email.
> I'm actually looking into putting non-overcommit as a configurable
> option in the kernel.
Nice to hear, please make it a boot time option, not a compile time
one. Also a control for how many percent the kernel can overcommit
would be nice -- this is how modern Unices do.
> However, this does not save you from the fact that the
> system is essentially deadlocked when nothing can get
> more memory and nothing goes away.
I've also never said OOM killer should be disabled. In theory the
non-overcommitting systems deadlock, Linux survives. Ironically
usually it's just the opposite in practice. Any user can
deadlock/crash Linux [default install, no quotas] but not an
non-overcommitting system [root can clean up]. Here is an example code
"simulating" a leaking daemon that will "deadlock" Linux even with
your OOM killer patch [that is anyway *MUCH* better than the actually
non-existing one in 2.2.x kernels]:
main() { while(1) if (fork()) malloc(1); }
With the patch below I could ssh to the host and killall the offending
processes. To enable reserving VM space for root do
echo -1 > /proc/sys/vm/overcommit_memory
The number of reserved pages can be tuned via /proc/sys/vm/reserved,
default is 5% of the RAM (note, RAM won't be reserved, but VM).
BTW, I wanted to take a look at the frequently mentioned beancounter patch,
here is the current state,
http://www.asp-linux.com/en/products/ubpatch.shtml
"Sorry, due to growing expenses for support of public version of ASPcomplete
we do not provide sources till first official release."
Szaka
diff -ur linux.orig/include/linux/sysctl.h linux/include/linux/sysctl.h
--- linux.orig/include/linux/sysctl.h Thu Nov 9 08:20:19 2000
+++ linux/include/linux/sysctl.hThu Nov 9 06:30:11 2000
@@ -122,7 +122,8 @@
VM_PAGECACHE=7, /* struct: Set cache memory thresholds */
VM_PAGERDAEMON=8, /* struct: Control kswapd behaviour */
VM_PGT_CACHE=9, /* struct: Set page table cache parameters */
- VM_PAGE_CLUSTER=10 /* int: set number of pages to swap together */
+ VM_PAGE_CLUSTER=10, /* int: set number of pages to swap together */
+ VM_RESERVED=11 /* int: number of pages reserved for root */
};
diff -ur linux.orig/kernel/sysctl.c linux/kernel/sysctl.c
--- linux.orig/kernel/sysctl.c Thu Nov 9 08:20:19 2000
+++ linux/kernel/sysctl.c Thu Nov 9 06:27:33 2000
@@ -37,6 +37,7 @@
extern int bdf_prm[], bdflush_min[], bdflush_max[];
extern char binfmt_java_interpreter[], binfmt_java_appletviewer[];
extern int sysctl_overcommit_memory;
+extern int vm_reserved;
extern int nr_queued_signals, max_queued_signals;
#ifdef CONFIG_KMOD
@@ -259,6 +260,8 @@
_cache_water, 2*sizeof(int), 0600, NULL, _dointvec},
{VM_PAGE_CLUSTER, "page-cluster",
_cluster, sizeof(int), 0600, NULL, _dointvec},
+ {VM_RESERVED, "reserved",
+_reserved, sizeof(int), 0600, NULL, _dointvec},
{0}
};
diff -ur linux.orig/mm/mmap.c linux/mm/mmap.c
--- linux.orig/mm/mmap.cThu Nov 9 08:20:19 2000
+++ linux/mm/mmap.c Thu Nov 9 08:17:10 2000
@@ -40,6 +40,7 @@
kmem_cache_t *vm_area_cachep;
int sysctl_overcommit_memory;
+int vm_reserved;
/* Check that a process has enough memory to allocate a
* new virtual mapping.
@@ -59,7 +60,7 @@
long free;
/* Sometimes we want to use more memory than we have. */
- if (sysctl_overcommit_memory)
+ if (sysctl_overcommit_memory == 1)
return 1;
free = buffermem >> PAGE_SHIFT;
@@ -67,6 +68,8 @@
free += nr_free_pages;
free += nr_swap_pages;
free -= (page_cache.min_percent + buffer_mem.min_percent +
2)*num_physpages/100;
+ if (sysctl_overcommit_memory == -1 && current->uid && free < vm_reserved)
+ return 0;
return free > pages;
}
@@ -872,6 +875,11 @@
void __init vma_init(void)
{
+ struct sysinfo i;
+
+ si_meminfo();
+ vm_reserved = (i.totalram >> PAGE_SHIFT) / 20;
+
vm_area_cachep = kmem_cache_create("vm_area_struct",
sizeof(struct vm_area_struct),
0, SLAB_HWCACHE_ALIGN,
-
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/
[glynis@butterfly.hjsoft.com: test10 and cpia_usb camera]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
i'm happy to see my cheap little camera working again.
i have observations though:
using uhci.o, i only get black image from video camera in xawtv.
using usb-uhci.o, i get a picture, but i periodically get:
kernel: usb-uhci.c: interrupt, status , frame #
kernel: *_comp parameters have gone AWOL (140/189/137/169)
and xawtv scrolls messages:
rate: video is frames behind.
also, the camera does not operetae the first time i plug it in, it
must first be unplugged, then reconnected.
before cpia broke a couple test kernels back, i used to use uhci.o
quite successfully, but usb-uhci.o did not work.
}John Flinchbaugh{__
| [EMAIL PROTECTED] http://www.hjsoft.com/~glynis/ |
~~Powered by Linux: Reboots are for hardware upgrades only~~
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjoKzhEACgkQCGPRljI8080hhQCeJIVoOkslT1Ij9EZibB1Z3p1P
kSEAn2nAs8jKAZ1diAGgdjvHCEwBq2+R
=dJWF
-END PGP SIGNATURE-
-
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 do we need pg1?
Hi, The code which sets up the page table at pg0 (in head.S) goes all the way until it hits empty_zero_page so I don't understand why we need the label pg1 in between, since it is never referred to by any other code? Also, is the comment in asm/pgtable.h /* page table for 0-4MB for everybody */ extern unsigned long pg0[1024]; true or false? Isn't it for 0-8M as head.S claims? Regards, Tigran - 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: Kernel 2.2.17 bug found
On Thu, Nov 09, 2000 at 05:20:22PM +0200, Andrea Pintori wrote: > I've a Debian dist, Kernel 2.2.17, no patches, all packages are stable. > > here what I found: > > [/tmp] mkdir old > [/tmp] chdir old > [/tmp/old] mv . ../new > [/tmp/old](should be /tmp/new !!) > [/tmp/old] mkdir fff > error: cannot write... > [tmp/old] ls > fff > error: cannot write... > [/tmp/old] ls -la > total 0 (?) > [/tmp/old] cd .. > [/tmp] ls -la > * ./ > * ../ > * new/ > > Does anybody knew this bug? Not a bug... possibly a typo though. The "[/tmp/old] mv . ../new" line destroys the definition of "current directory". The "mkdir fff" can't work since the current directory is no longer there, and is indicated by the lines: [/tmp/old] ls -la total 0 (?) There is nothing to take a directory of. - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - 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: Kernel 2.2.17 bug found
On Thu, 9 Nov 2000, Andrea Pintori wrote: > I've a Debian dist, Kernel 2.2.17, no patches, all packages are stable. > > here what I found: > > [/tmp] mkdir old > [/tmp] chdir old > [/tmp/old] mv . ../new > [/tmp/old](should be /tmp/new !!) The shell might not read this all the while so the name you see may not change until you change directory. > [/tmp/old] mkdir fff > error: cannot write... This should not happen and it doesn't happen in kernel version 2.4.0-test0 > [tmp/old] ls > fff > error: cannot write... > [/tmp/old] ls -la > total 0 (?) > [/tmp/old] cd .. > [/tmp] ls -la > * ./ > * ../ > * new/ > Script started on Thu Nov 9 10:45:35 2000 # pwd /tmp # mkdir old # cd old # pwd /tmp/old # mv ../old ../new # pwd /tmp/old The shell hasn't re-read the current directory # ls # >foo Make a file called foo # ls foo It's there okay # rm fooRemove the file # mkdir bar Make a directory # ls bar It's there # cd bar # pwd /tmp/new/barNow, the shell re-read the directory, it is correct # cd .. # pwd /tmp/newBack where we were, shell reads correct directory. # cd .. # ls new typescript # rm -r new # exit exit Script done on Thu Nov 9 10:47:23 2000 Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Kernel 2.2.17 bug found
On Thu, Nov 09, 2000 at 05:20:22PM +0200, Andrea Pintori <[EMAIL PROTECTED]> wrote: > > I've a Debian dist, Kernel 2.2.17, no patches, all packages are stable. I've Debian unstable, Kernel 2.2.17 > here what I found: > > [/tmp] mkdir old > [/tmp] chdir old > [/tmp/old] mv . ../new > [/tmp/old](should be /tmp/new !!) Uhm, no. $PWD only gets updated on cd, not on mv. Thus, the old value is OK! > [/tmp/old] mkdir fff > error: cannot write... > [tmp/old] ls > fff > error: cannot write... This seems wrong. But I'd rather say this is a bug in your shell, not in the kernel! /tmp> mkdir old /tmp> cd old /tmp/old> mv . ../new /tmp/old> mkdir fff /tmp/old> ls -al total 12 drwxr-xr-x3 jean-luc jean-luc 4096 Nov 9 16:46 . drwxrwxrwt8 root root 4096 Nov 9 16:46 .. drwxr-xr-x2 jean-luc jean-luc 4096 Nov 9 16:46 fff /tmp/old> cd ../new /tmp/new> ls -al total 12 drwxr-xr-x3 jean-luc jean-luc 4096 Nov 9 16:46 . drwxrwxrwt8 root root 4096 Nov 9 16:46 .. drwxr-xr-x2 jean-luc jean-luc 4096 Nov 9 16:46 fff Works for both bash-2.04 and zsh-3.1.9-dev7 (as in Debian unstable). > Does anybody knew this bug? Well, I can't even reproduce it ;) Ciao, Thomas -- Thomas Köhler Email: [EMAIL PROTECTED] | LCARS - Linux <>
Re: Kernel 2.2.17 bug found
Tim Waugh wrote: > You forgot to 'cd .' Look for "pebsak" messages in /var/log/syslog ;) - 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: Kernel 2.2.17 bug found
On Thu, Nov 09, 2000 at 05:20:22PM +0200, Andrea Pintori wrote: > [/tmp/old] mv . ../new > [/tmp/old](should be /tmp/new !!) You forgot to 'cd .' Tim. */ PGP signature
