* Re: lk maintainers
From: Denis Vlasenko @ 2002-12-18 10:49 UTC (permalink / raw)
To: Zwane Mwaikambo; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.50.0212171118520.8420-100000@montezuma.mastecende.com>
On 17 December 2002 21:55, Zwane Mwaikambo wrote:
> On Tue, 17 Dec 2002, Denis Vlasenko wrote:
> > Martin Dalecki <martin@dalecki.de> [11 mar 2002]
> > IDE subsystem maintainer for 2.5
> > (mail Vojtech Pavlik <vojtech@suse.cz> too)
>
> Should this entry still be there?
It was true as of 11 March 2002 ;)
I imagine Martin reading this one day and think
"whee, they did not erase me from the history...".
He would be pleased.
> > Eric S. Raymond <esr@thyrsus.com> [5 feb 2002]
> > Send kernel configuration bug reports and suggestions to me.
> > Also I'll be more than happy to accept help enties for kernel
> > config options (Configure.help).
>
> Can't say i've seen this fellow in a while either.
If 'lk maintainers' will get excessively long, I'll start pruning.
Do you think I should do it now?
--
vda
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-18 6:06 UTC (permalink / raw)
To: Brian Gerst; +Cc: Andi Kleen, mingo, linux-kernel, davej
In-Reply-To: <3E0006D2.3000907@quark.didntduck.org>
On Wed, 18 Dec 2002, Brian Gerst wrote:
>
> How about this patch? Instead of making a per-cpu trampoline, write to
> the msr during each context switch.
I wanted to avoid slowing down the context switch, but I didn't actually
time how much the MSR write hurts you (it needs to be conditional, though,
I think).
Linus
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Brian Gerst @ 2002-12-18 6:00 UTC (permalink / raw)
To: Ulrich Drepper
Cc: Nakajima, Jun, Linus Torvalds, Matti Aarnio, Hugh Dickins,
Dave Jones, Ingo Molnar, linux-kernel, hpa
In-Reply-To: <3DFFD55E.6020305@redhat.com>
Ulrich Drepper wrote:
> Nakajima, Jun wrote:
>
>>AMD (at least Athlon, as far as I know) supports sysenter/sysexit. We tested it on an Athlon box as well, and it worked fine. And sysenter/sysexit was better than int/iret too (about 40% faster) there.
>
>
> That's good to know but not what I meant.
>
> I referred to syscall/sysret opcodes. They are broken in their own way
> (destroying ecx on kernel entry) but at least they preserve eip.
>
syscall is pretty much unusable unless the NMI is changed to a task
gate. syscall does not change %esp on entry to the kernel, so an NMI
before the manual stack switch would still use the user stack, which is
not guaranteed to be valid - oops. x86-64 gets around this by using an
interrupt stack, its replacement for task gates.
--
Brian Gerst
^ permalink raw reply
* converting cap_set_pg() to for_each_task_pid()
From: William Lee Irwin III @ 2002-12-18 5:57 UTC (permalink / raw)
To: chris; +Cc: greg, linux-kernel
I have a pending patch that converts cap_set_pg() to the
for_each_task_pid() API. Could you review this, and if it
pass, include it in your tree?
Thanks,
Bill
cap_set_pg() wants to find all processes in a given process group. This
converts it to use for_each_task_pid().
capability.c | 16 +++++++++-------
1 files changed, 9 insertions(+), 7 deletions(-)
diff -urpN wli-2.5.51-bk1-4/kernel/capability.c wli-2.5.51-bk1-5/kernel/capability.c
--- wli-2.5.51-bk1-4/kernel/capability.c 2002-12-09 18:45:43.000000000 -0800
+++ wli-2.5.51-bk1-5/kernel/capability.c 2002-12-11 18:32:44.000000000 -0800
@@ -84,13 +84,15 @@ static inline void cap_set_pg(int pgrp,
kernel_cap_t *inheritable,
kernel_cap_t *permitted)
{
- task_t *g, *target;
-
- do_each_thread(g, target) {
- if (target->pgrp != pgrp)
- continue;
- security_capset_set(target, effective, inheritable, permitted);
- } while_each_thread(g, target);
+ task_t *g, *target;
+ struct list_head *l;
+ struct pid *pid;
+
+ for_each_task_pid(pgrp, PIDTYPE_PGID, g, l, pid) {
+ target = g;
+ while_each_thread(g, target)
+ security_capset_set(target, effective, inheritable, permitted);
+ }
}
/*
^ permalink raw reply
* Re: uml-patch-2.5.52-1
From: William Lee Irwin III @ 2002-12-18 5:53 UTC (permalink / raw)
To: Jeff Dike; +Cc: linux-kernel, user-mode-linux-devel
In-Reply-To: <200212180054.gBI0s0D11497@karaya.com>
On Tue, Dec 17, 2002 at 07:54:00PM -0500, Jeff Dike wrote:
> This patch updates UML to 2.5.52. As far as UML itself is concerned, this
> is identical to all recent 2.5 UML releases.
> The file corruption that I saw with the 2.5.50 UML seems to be gone; however
> Oleg Drokin is maintaining his own 2.5 UML repo, with forward ports of my 2.4
> updates, and he's reporting corruption with his 2.5.52. I've exercised this
> patch with kernel builds and various other loads and seen no problem, so it's
> possible the problem is in his pool and not mine - however, caveat user.
> The 2.5.52 UML patch is available at
> http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.5.52-1.bz2
> For the other UML mirrors and other downloads, see
> http://user-mode-linux.sourceforge.net/dl-sf.html
I have a pending patch against your tree. Could you review this, and if
it pass, include it in your tree?
Thanks,
Bill
get_task() really wants to do find_task_by_pid().
This calls find_task_by_pid() directly.
process_kern.c | 10 ++--------
1 files changed, 2 insertions(+), 8 deletions(-)
diff -urpN uml-2.5.52-1/arch/um/kernel/process_kern.c uml-2.5.52-2/arch/um/kernel/process_kern.c
--- uml-2.5.52-1/arch/um/kernel/process_kern.c 2002-12-17 19:54:03.000000000 -0800
+++ uml-2.5.52-2/arch/um/kernel/process_kern.c 2002-12-17 21:51:29.000000000 -0800
@@ -52,16 +52,10 @@ struct cpu_task cpu_tasks[NR_CPUS] = { [
struct task_struct *get_task(int pid, int require)
{
- struct task_struct *task, *ret;
+ struct task_struct *ret;
- ret = NULL;
read_lock(&tasklist_lock);
- for_each_process(task){
- if(task->pid == pid){
- ret = task;
- break;
- }
- }
+ ret = find_task_by_pid(pid);
read_unlock(&tasklist_lock);
if(require && (ret == NULL)) panic("get_task couldn't find a task\n");
return(ret);
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-18 5:38 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: Linus Torvalds, Ulrich Drepper, Matti Aarnio, Hugh Dickins,
Dave Jones, Ingo Molnar, Linux Kernel List
In-Reply-To: <1040189657.1562.11.camel@ixodes.goop.org>
Jeremy Fitzhardinge wrote:
> On Tue, 2002-12-17 at 09:55, Linus Torvalds wrote:
>
>>Uli, how about I just add one ne warchitecture-specific ELF AT flag, which
>>is the "base of sysinfo page". Right now that page is all zeroes except
>>for the system call trampoline at the beginning, but we might want to add
>>other system information to the page in the future (it is readable, after
>>all).
>
>
> The P4 optimisation guide promises horrible things if you write within
> 2k of a cached instruction from another CPU (it dumps the whole trace
> cache, it seems), so you'd need to be careful about mixing mutable data
> and the syscall code in that page.
>
> Immutable data should be fine.
>
Yes, you really want to use a second page.
-hpa
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Jeremy Fitzhardinge @ 2002-12-18 5:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ulrich Drepper, Matti Aarnio, Hugh Dickins, Dave Jones,
Ingo Molnar, Linux Kernel List, H. Peter Anvin
In-Reply-To: <Pine.LNX.4.44.0212170948380.2702-100000@home.transmeta.com>
On Tue, 2002-12-17 at 09:55, Linus Torvalds wrote:
> Uli, how about I just add one ne warchitecture-specific ELF AT flag, which
> is the "base of sysinfo page". Right now that page is all zeroes except
> for the system call trampoline at the beginning, but we might want to add
> other system information to the page in the future (it is readable, after
> all).
The P4 optimisation guide promises horrible things if you write within
2k of a cached instruction from another CPU (it dumps the whole trace
cache, it seems), so you'd need to be careful about mixing mutable data
and the syscall code in that page.
Immutable data should be fine.
J
^ permalink raw reply
* problem in compiling nlmtest.c
From: imran @ 2002-12-18 5:24 UTC (permalink / raw)
To: NFS
[-- Attachment #1: Type: text/plain, Size: 916 bytes --]
Hi
currently i am working with NLM test utility available under
nfs-utils-0.3.3. while compiling nlmtest.c I am getting following error
debian:/home/imran/LockStudy/nfs-utils-0.3.3/tools/nlmtest# make
gcc -g -O2 -D_GNU_SOURCE -Isupport/include -Wall -pipe -DVERSION="\"nfs-ut
ils 0.3.3\"" -D
NFS3_SUPPORTED -c -o nlmtest.o nlmtest.c
nlmtest.c: In function `main':
nlmtest.c:101: incompatible type for argument 1 of `nlm_test_1'
nlmtest.c:135: incompatible type for argument 1 of `nlm_unlock_1'
nlmtest.c:153: incompatible type for argument 1 of `nlm_lock_1'
make: *** [nlmtest.o] Error 1
I have updated host.h with appropriate host name and appropriate directory
could anybody help me to build nlmtest.o
Thanks and regards
################################
Imran Sheth
Senior Software Engineer
Patni Computer System
SDF 5, Unit 141,SEEPZ
Andheri
ph : 28291454 extn:5017
################################
[-- Attachment #2: Type: text/html, Size: 1690 bytes --]
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Brian Gerst @ 2002-12-18 5:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andi Kleen, mingo, linux-kernel, davej
In-Reply-To: <Pine.LNX.4.44.0212170850250.2702-100000@home.transmeta.com>
[-- Attachment #1: Type: text/plain, Size: 1538 bytes --]
Linus Torvalds wrote:
>
> On 17 Dec 2002, Andi Kleen wrote:
>
>>Linus Torvalds <torvalds@transmeta.com> writes:
>>
>>>That NMI problem is pretty fundamentally unfixable due to the stupid
>>>sysenter semantics, but we could just make the NMI handlers be real
>>>careful about it and fix it up if it happens.
>>
>>You just have to make the NMI a task gate with an own TSS, then the
>>microcode will set up an own stack for you.
>
>
> Actually, I came up with a much simpler solution (which I didn't yet
> implement, but should be just a few lines).
>
> The simpler solution is to just make the temporary ESP stack _look_ like
> it's a real process - ie make it 8kB per CPU (instead of the current 4kB)
> and put a fake "thread_info" at the bottom of it with the right CPU
> number etc. That way if an NMI comes in (in the _extremely_ tiny window),
> it will still see a sane picture of the system. It will basically think
> that we had a micro-task-switch between two instructions.
>
> It's also entirely possible that the NMI window may not actually even
> exist, since I'm not even sure that Intel checks for pending interrupt
> before the first instruction of a trap handler.
How about this patch? Instead of making a per-cpu trampoline, write to
the msr during each context switch. This means that the stack pointer
is valid at all times, and also saves memory and a cache line bounce. I
also included some misc cleanups.
Tested on an Athlon XP.
sysenter: 158.854423 cycles
int80: 273.658134 cycles
--
Brian Gerst
[-- Attachment #2: sysenter-1 --]
[-- Type: text/plain, Size: 5572 bytes --]
diff -urN linux-2.5.52-bk2/arch/i386/kernel/cpu/common.c linux/arch/i386/kernel/cpu/common.c
--- linux-2.5.52-bk2/arch/i386/kernel/cpu/common.c Sat Dec 14 12:32:00 2002
+++ linux/arch/i386/kernel/cpu/common.c Tue Dec 17 23:21:55 2002
@@ -487,7 +487,7 @@
BUG();
enter_lazy_tlb(&init_mm, current, cpu);
- t->esp0 = thread->esp0;
+ load_esp0(t, thread->esp0);
set_tss_desc(cpu,t);
cpu_gdt_table[cpu][GDT_ENTRY_TSS].b &= 0xfffffdff;
load_TR_desc();
diff -urN linux-2.5.52-bk2/arch/i386/kernel/process.c linux/arch/i386/kernel/process.c
--- linux-2.5.52-bk2/arch/i386/kernel/process.c Sat Dec 14 12:32:04 2002
+++ linux/arch/i386/kernel/process.c Tue Dec 17 23:29:54 2002
@@ -440,7 +440,7 @@
/*
* Reload esp0, LDT and the page table pointer:
*/
- tss->esp0 = next->esp0;
+ load_esp0(tss, next->esp0);
/*
* Load the per-thread Thread-Local Storage descriptor.
diff -urN linux-2.5.52-bk2/arch/i386/kernel/sysenter.c linux/arch/i386/kernel/sysenter.c
--- linux-2.5.52-bk2/arch/i386/kernel/sysenter.c Tue Dec 17 23:21:45 2002
+++ linux/arch/i386/kernel/sysenter.c Tue Dec 17 23:31:01 2002
@@ -20,22 +20,12 @@
static void __init enable_sep_cpu(void *info)
{
- unsigned long page = __get_free_page(GFP_ATOMIC);
int cpu = get_cpu();
- unsigned long *esp0_ptr = &(init_tss + cpu)->esp0;
- unsigned long rel32;
+ struct tss_struct *tss = init_tss + cpu;
- rel32 = (unsigned long) sysenter_entry - (page+11);
-
-
- *(short *) (page+0) = 0x258b; /* movl xxxxx,%esp */
- *(long **) (page+2) = esp0_ptr;
- *(char *) (page+6) = 0xe9; /* jmp rl32 */
- *(long *) (page+7) = rel32;
-
- wrmsr(0x174, __KERNEL_CS, 0); /* SYSENTER_CS_MSR */
- wrmsr(0x175, page+PAGE_SIZE, 0); /* SYSENTER_ESP_MSR */
- wrmsr(0x176, page, 0); /* SYSENTER_EIP_MSR */
+ wrmsr(MSR_IA32_SYSENTER_CS, __KERNEL_CS, 0);
+ wrmsr(MSR_IA32_SYSENTER_ESP, tss->esp0, 0);
+ wrmsr(MSR_IA32_SYSENTER_EIP, (unsigned long) sysenter_entry, 0);
printk("Enabling SEP on CPU %d\n", cpu);
put_cpu();
@@ -60,14 +50,15 @@
};
unsigned long page = get_zeroed_page(GFP_ATOMIC);
+ if (cpu_has_sep) {
+ memcpy((void *) page, sysent, sizeof(sysent));
+ enable_sep_cpu(NULL);
+ smp_call_function(enable_sep_cpu, NULL, 1, 1);
+ } else
+ memcpy((void *) page, int80, sizeof(int80));
+
__set_fixmap(FIX_VSYSCALL, __pa(page), PAGE_READONLY);
- memcpy((void *) page, int80, sizeof(int80));
- if (!boot_cpu_has(X86_FEATURE_SEP))
- return 0;
-
- memcpy((void *) page, sysent, sizeof(sysent));
- enable_sep_cpu(NULL);
- smp_call_function(enable_sep_cpu, NULL, 1, 1);
+
return 0;
}
diff -urN linux-2.5.52-bk2/arch/i386/kernel/vm86.c linux/arch/i386/kernel/vm86.c
--- linux-2.5.52-bk2/arch/i386/kernel/vm86.c Sat Dec 14 12:32:02 2002
+++ linux/arch/i386/kernel/vm86.c Tue Dec 17 23:21:55 2002
@@ -113,7 +113,7 @@
do_exit(SIGSEGV);
}
tss = init_tss + smp_processor_id();
- tss->esp0 = current->thread.esp0 = current->thread.saved_esp0;
+ load_esp0(tss, current->thread.saved_esp0);
current->thread.saved_esp0 = 0;
ret = KVM86->regs32;
return ret;
@@ -283,7 +283,8 @@
info->regs32->eax = 0;
tsk->thread.saved_esp0 = tsk->thread.esp0;
tss = init_tss + smp_processor_id();
- tss->esp0 = tsk->thread.esp0 = (unsigned long) &info->VM86_TSS_ESP0;
+ tsk->thread.esp0 = (unsigned long) &info->VM86_TSS_ESP0;
+ load_esp0(tss, tsk->thread.esp0);
tsk->thread.screen_bitmap = info->screen_bitmap;
if (info->flags & VM86_SCREEN_BITMAP)
diff -urN linux-2.5.52-bk2/include/asm-i386/cpufeature.h linux/include/asm-i386/cpufeature.h
--- linux-2.5.52-bk2/include/asm-i386/cpufeature.h Sun Sep 15 22:18:22 2002
+++ linux/include/asm-i386/cpufeature.h Tue Dec 17 23:29:27 2002
@@ -7,6 +7,8 @@
#ifndef __ASM_I386_CPUFEATURE_H
#define __ASM_I386_CPUFEATURE_H
+#include <linux/bitops.h>
+
#define NCAPINTS 4 /* Currently we have 4 32-bit words worth of info */
/* Intel-defined CPU features, CPUID level 0x00000001, word 0 */
@@ -74,6 +76,7 @@
#define cpu_has_pae boot_cpu_has(X86_FEATURE_PAE)
#define cpu_has_pge boot_cpu_has(X86_FEATURE_PGE)
#define cpu_has_apic boot_cpu_has(X86_FEATURE_APIC)
+#define cpu_has_sep boot_cpu_has(X86_FEATURE_SEP)
#define cpu_has_mtrr boot_cpu_has(X86_FEATURE_MTRR)
#define cpu_has_mmx boot_cpu_has(X86_FEATURE_MMX)
#define cpu_has_fxsr boot_cpu_has(X86_FEATURE_FXSR)
diff -urN linux-2.5.52-bk2/include/asm-i386/msr.h linux/include/asm-i386/msr.h
--- linux-2.5.52-bk2/include/asm-i386/msr.h Sat Dec 14 12:32:05 2002
+++ linux/include/asm-i386/msr.h Tue Dec 17 23:21:55 2002
@@ -53,6 +53,10 @@
#define MSR_IA32_BBL_CR_CTL 0x119
+#define MSR_IA32_SYSENTER_CS 0x174
+#define MSR_IA32_SYSENTER_ESP 0x175
+#define MSR_IA32_SYSENTER_EIP 0x176
+
#define MSR_IA32_MCG_CAP 0x179
#define MSR_IA32_MCG_STATUS 0x17a
#define MSR_IA32_MCG_CTL 0x17b
diff -urN linux-2.5.52-bk2/include/asm-i386/processor.h linux/include/asm-i386/processor.h
--- linux-2.5.52-bk2/include/asm-i386/processor.h Sat Dec 14 12:32:08 2002
+++ linux/include/asm-i386/processor.h Tue Dec 17 23:26:16 2002
@@ -14,6 +14,7 @@
#include <asm/types.h>
#include <asm/sigcontext.h>
#include <asm/cpufeature.h>
+#include <asm/msr.h>
#include <linux/cache.h>
#include <linux/config.h>
#include <linux/threads.h>
@@ -416,6 +417,13 @@
{~0, } /* ioperm */ \
}
+static inline void load_esp0(struct tss_struct *tss, unsigned long esp0)
+{
+ tss->esp0 = esp0;
+ if (cpu_has_sep)
+ wrmsr(MSR_IA32_SYSENTER_ESP, esp0, 0);
+}
+
#define start_thread(regs, new_eip, new_esp) do { \
__asm__("movl %0,%%fs ; movl %0,%%gs": :"r" (0)); \
set_fs(USER_DS); \
^ permalink raw reply
* Re: [Fwd: [Bug 136] New: FSID returned from statvfs always 0]
From: Andrew Morton @ 2002-12-18 5:15 UTC (permalink / raw)
To: Andries Brouwer; +Cc: H. Peter Anvin, linux-fsdevel
In-Reply-To: <20021209230418.GA9444@win.tue.nl>
Andries Brouwer wrote:
>
> On Mon, Dec 09, 2002 at 02:15:12PM -0800, H. Peter Anvin wrote:
>
> > > The general idea is that f_fsid contains some random stuff such that
> > > the pair (f_fsid,ino) uniquely determines a file.
>
> > This, of course, is the exact POSIX definition of the st_dev part of
> > struct stat: (st_dev, st_ino) uniquely identifies the file.
>
> Yes, but the difference is that (st_dev, st_ino) only identifies
> the file within a single machine, and may stop working when you
> have NFS mounts.
>
> The traditional implementations use st_dev and NFS filehandles
> and a hash of the filesystem type.
>
If this feature is to have any value, should not the fsid remain stable
as the disk gets moved around the machine?
I'm not sure I saw sufficient solidity in this discussion to be able to
generate&justify a patch.
^ permalink raw reply
* LCD going off
From: Ramprasad @ 2002-12-18 5:03 UTC (permalink / raw)
To: Linux Fbdev development list
Hi All,
I am using 2.4.18-rmk4 patch on an assbet like board . I am using
sharp mono LCD touch panel.
My problem is , i have an USB master support on my board and when i
plug an USB diskon key , after some time (Say 50 sec - 70 sec ) the
screen going blank... and never comes back.
can any body give some pointers.
Thanks in advance,
Ramprasad
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* [STATUS 2.5] December 18, 2002
From: Guillaume Boissiere @ 2002-12-18 4:56 UTC (permalink / raw)
To: linux-kernel
Nothing new in the kernel status list this week.
A lot of stabilization work and bug fixes.
In case you want to check it out anyway, here the URL again:
http://www.kernelnewbies.org/status/
It also looks like the bug database is working out well,
more than half the bugs entered so far have been resolved.
Cheers,
-- Guillaume
----------------------
Below a snapshot of the bugzilla database, ordered by severity
(see http://bugzilla.kernel.org/ for full details)
44 blo khoa@us.ibm.com OPEN radeonfb does not compile at all - seems incomplete? or w...
118 blo mbligh@aracnet.com OPEN Load IDE-SCSI module causes OOPS in 2.5.49
66 blo zaitcev@yahoo.com ASSI SMP Kernel Compile for Sparc32 fails
123 blo alan@lxorguk.ukuu.org.uk ASSI SiL 680 IDE controller has "issues"
157 hig mbligh@aracnet.com OPEN Makefile bug? sound/synth/emux/built-in.o
180 hig davej@codemonkey.org.uk OPEN Broken agpgart on i815 (maybe other ICH too)
10 hig andrew.grover@intel.com ASSI USB HCs may have improper interrupt configuration with AC...
71 hig andrew.grover@intel.com ASSI RTL8100BL (8139) do not work on acpi UP without local apic
111 hig wli@holomorphy.com ASSI hugetlbfs does not align pages
113 hig alan@lxorguk.ukuu.org.uk ASSI CMD649 or ALI15X3 problem under 2.5.49 and since many pre...
129 hig greg@kroah.com ASSI usb-storage crashes my pc when i plug in a SIIG Compact F...
130 hig green@namesys.com ASSI problems mounting root partition with 2.5.48+ kernels
11 nor mbligh@aracnet.com OPEN Intermezzo Compile Failure
18 nor vojtech@suse.cz OPEN Synaptics touchpad driver
46 nor vojtech@suse.cz OPEN ide-scsi causing (Two mice: unwanted double-clicks & erra...
48 nor mbligh@aracnet.com OPEN APM suspend and PCMCIA not cooperating
49 nor mbligh@aracnet.com OPEN register_console() called in illegal context
54 nor mbligh@aracnet.com OPEN 100% reproduceable "null TTY for (####) in tty_fasync"
57 nor greg@kroah.com OPEN usb-storage oops on loading
58 nor mbligh@aracnet.com OPEN OHCI-1394: sleeping function called from illegal context ...
69 nor mbligh@aracnet.com OPEN Framebuffer bug
72 nor khoa@us.ibm.com OPEN Framebuffer scrolls at the wrong times/places
79 nor khoa@us.ibm.com OPEN Framebuffer scrolling problem
94 nor mbligh@aracnet.com OPEN file remain locked after sapdb process exist.
104 nor khoa@us.ibm.com OPEN MIPS fails to build: asm/thread_info.h doesn't exist
110 nor khoa@us.ibm.com OPEN Current bk Linux-2.5, VFS Kernel Panic from Devfs + NO UN...
115 nor mbligh@aracnet.com OPEN Kernel modules won't load
117 nor mbligh@aracnet.com OPEN build failure: arch/ppc/kernel/process.c
122 nor mbligh@aracnet.com OPEN emu10k1 OSS troubles
126 nor vojtech@suse.cz OPEN bzImage build failure on input devices support as module
134 nor mbligh@aracnet.com OPEN 2.5.50 breaks pcmcia cards
135 nor mbligh@aracnet.com OPEN SB16/Alsa doesn't work
138 nor khoa@us.ibm.com OPEN Build error: drivers/video/sis/sis_main.h:299: parse erro...
143 nor alan@lxorguk.ukuu.org.uk OPEN unable to read cd audio from atapi cdrom/cdrw/dvd device,...
144 nor mbligh@aracnet.com OPEN error return not checked in register_disk (fs/partitions/...
145 nor mbligh@aracnet.com OPEN ALSA: SB-AWE ISA detection fails
149 nor vojtech@suse.cz OPEN Laptop with touchpad and "pointer". Pointer never works
150 nor greg@kroah.com OPEN [PNP][2.5] IDE Detection problems (wrong IRQ and wrong ID...
153 nor mbligh@aracnet.com OPEN compile failure on drivers/char/riscom8.c
154 nor mbligh@aracnet.com OPEN compile failure on drivers/char/esp.c
155 nor mbligh@aracnet.com OPEN compile failure on drivers/char/specialix.c
158 nor mbligh@aracnet.com OPEN depmod should be in README
159 nor mbligh@aracnet.com OPEN compile failure on drivers/isdn/i4l/isdn_net_lib.c
160 nor jgarzik@pobox.com OPEN With 2 different nic on one system, dhcp configuration fails
161 nor mbligh@aracnet.com OPEN VESAfb in 2.5 somehow influences X resolution.
162 nor khoa@us.ibm.com OPEN compile failure on drivers/media/video/bttv-cards.c
163 nor mbligh@aracnet.com OPEN Impossible to setup MTRR registers
164 nor vojtech@suse.cz OPEN Linking Failure: drivers/built-in.o
167 nor khoa@us.ibm.com OPEN compile failure on drivers/media/video/zr36120.c
168 nor khoa@us.ibm.com OPEN compile failure on drivers/media/video/saa7185.c
169 nor khoa@us.ibm.com OPEN compile failure on drivers/media/video/bt819.c
171 nor vojtech@suse.cz OPEN 2.5.51 at kb driver leaves kb ib state that prevents (sof...
172 nor mbligh@aracnet.com OPEN tdfxfb.c can't be compiled
174 nor khoa@us.ibm.com OPEN link failure in function dvb_generic_ioctl: undefined ref...
179 nor mbligh@aracnet.com OPEN boot from 21 sec/track floppy
181 nor greg@kroah.com OPEN Kernel oops when connecting USB digital camera
182 nor mbligh@aracnet.com OPEN compile fails because of multiple undefined references in...
5 nor mbligh@aracnet.com ASSI 64GB highmem BUG()
7 nor willy@debian.org ASSI file lock accounting broken
9 nor dbrownell@users.sourceforge... ASSI Ehci do not leave system in a sensible state for bios on ...
15 nor alan@lxorguk.ukuu.org.uk ASSI No dma on first hard drive
16 nor willy@debian.org ASSI reproduceable oops in lock_get_status
36 nor andmike@us.ibm.com ASSI Long tape rewind causes abort on aic7xxx
37 nor alan@lxorguk.ukuu.org.uk ASSI IDE problems on old pre-PCI HW
39 nor alan@lxorguk.ukuu.org.uk ASSI undefined reference to `boot_gdt_table'
43 nor jgarzik@pobox.com ASSI e100 drivers crashes on non cache-coherent platforms
51 nor paul@laufernet.com ASSI isapnp does not register devices in /proc/isapnp
52 nor andmike@us.ibm.com ASSI aic7xxx driver fails to boot on netfinity 7000
53 nor alan@lxorguk.ukuu.org.uk ASSI IDE cd-rom I/O error
63 nor wli@holomorphy.com ASSI compile error with CONFIG_HUGETLB_PAGE yes
100 nor johnstul@us.ibm.com ASSI LTP - gettimeofday02 fails (time is going backwards)
105 nor johnstul@us.ibm.com ASSI gettimeofday cripples system running with notsc
106 nor mochel@osdl.org ASSI sysfs hierarchy can begin to disintegrate
119 nor andrew.grover@intel.com ASSI 2.5.49 - Dell Latitude weirdness at shutdown
131 nor alan@lxorguk.ukuu.org.uk ASSI "hda: lost interrupt"; "hda: dma_intr: bad DMA status" on...
132 nor acme@conectiva.com.br ASSI windows ip check ARP packet replied by kernel when proxy_...
136 nor akpm@digeo.com ASSI FSID returned from statvfs always 0
140 nor andmike@us.ibm.com ASSI isp1020 driver reports error
151 nor jejb@hansenpartnership.com ASSI compile failure on drivers/block/ps2esdi.c
156 nor alan@lxorguk.ukuu.org.uk ASSI compile failure on drivers/ide/pci/nvidia.c
165 nor jgarzik@pobox.com ASSI Kernel crashes after stop network and remove e100.
166 nor jgarzik@pobox.com ASSI e100 spits out strange message during startup.
142 low mbligh@aracnet.com OPEN problem with ver_linux script and procps version
8 low alan@lxorguk.ukuu.org.uk ASSI i2o_scsi does not handle reset properly
28 low jgarzik@pobox.com ASSI Compile time warnings from starfire driver (with PAE enab...
29 low akpm@digeo.com ASSI Debug: sleeping function called from illegal context at m...
83 low zippel@linux-m68k.org ASSI Wish: ability to quickly cycle through (NEW) config options
146 low akpm@digeo.com ASSI Assertion failure in do_get_write_access() at fs/jbd/tra...
170 low akpm@digeo.com ASSI poisoned oops in dump_orphan_list
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Andrew Morton @ 2002-12-18 4:53 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Linus Torvalds, LKML
In-Reply-To: <20021218154023.29726d09.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
>
> Hi Linus, Andrew,
>
> On Tue, 17 Dec 2002 20:07:53 -0800 (PST) Linus Torvalds <torvalds@transmeta.com> wrote:
> >
> > Btw, on another tangent - Andrew Morton reports that APM is unhappy about
> > the fact that the fast system call stuff required us to move the segments
> > around a bit. That's probably because the APM code has the old APM segment
> > numbers hardcoded somewhere, but I don't see where (I certainly knew about
> > the segment number issue, and tried to update the cases I saw).
>
> I looked at this yesterday and decided that it was OK as well.
>
> > Debugging help would be appreciated, especially from somebody who knows
> > the APM code.
>
> It would help to know what "unhappy" means :-)
The lcall seems to be going awry. It oopses when apmd starts up,
and the sysenter patch is the trigger.
CPU: 0
EIP: 00b8:[<000044d7>] Not tainted
EFLAGS: 00010202
EIP is at 0x44d7
eax: 000000c8 ebx: 00000001 ecx: 00000000 edx: 00000000
esi: c02e0091 edi: 000000ff ebp: ceed1ec4 esp: ceed1e74
ds: 0000 es: 0000 ss: 0068
Process apmd (pid: 679, threadinfo=ceed0000 task=cfa058a0)
Stack: 0000530a 00b844e8 00000000 ceed1ec4 c0112739 00000060 ceed1ec4 000000ff
00000068 00000068 ceed1f32 c02e0091 000000ff 00000202 ceed0000 cf706c24
00000000 00000000 c0130000 c1740000 ceed1f04 c0112b72 0000530a 00000001
Call Trace:
[<c0112739>] apm_bios_call+0x75/0xf4
[<c0130000>] cache_init_objs+0x34/0xd8
[<c0112b72>] apm_get_power_status+0x42/0x84
[<c012d843>] __alloc_pages+0x77/0x244
[<c0113828>] apm_get_info+0x38/0xe4
[<c016982d>] proc_file_read+0xa9/0x1ac
[<c0141b53>] vfs_read+0xb7/0x138
[<c0141dee>] sys_read+0x2a/0x40
[<c0108e67>] syscall_call+0x7/0xb
> Does the following fix it for you? Untested, assumes cache lines are 32
> bytes.
>
I cleverly left the laptop at work. Shall test tomorrow.
^ permalink raw reply
* Re: 2.5.52-wli-1
From: William Lee Irwin III @ 2002-12-18 4:53 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-kernel
In-Reply-To: <20021218045012.GA12963@gtf.org>
On Tue, Dec 17, 2002 at 08:44:43PM -0800, William Lee Irwin III wrote:
>> Available from:
>> ftp://ftp.kernel.org/pub/linux/kernel/people/wli/kernels/2.5.52-wli-1/
>> Notable events:
>> (1) I switched to mainline releases since intermediate -bk snapshots
>> vaporize after the following mainline release.
On Tue, Dec 17, 2002 at 11:50:12PM -0500, Jeff Garzik wrote:
> hpa has rightly criticized my snapshot script for doing this, so this
> should actually be fixed on my end not yours :)
Not a big deal here, most of this stuff is "dusty corners" material so
the worst I get is offsets as the various header cleanups progress.
Bill
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-18 4:52 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: LKML, Andrew Morton
In-Reply-To: <20021218154023.29726d09.sfr@canb.auug.org.au>
On Wed, 18 Dec 2002, Stephen Rothwell wrote:
>
> It would help to know what "unhappy" means :-)
Andrew reported an oops in the BIOS. I ahev the full oops info somewhere,
but quite frankly it isn't that readable. It shows
EIP: 00b8:[<000044d7>] Not tainted
ds: 0000 es: 0000 ss: 0068
Call Trace:
[<c0112739>] apm_bios_call+0x75/0xf4
[<c0130000>] cache_init_objs+0x34/0xd8
[<c0112b72>] apm_get_power_status+0x42/0x84
[<c012d843>] __alloc_pages+0x77/0x244
[<c0113828>] apm_get_info+0x38/0xe4
[<c016982d>] proc_file_read+0xa9/0x1ac
[<c0141b53>] vfs_read+0xb7/0x138
[<c0141dee>] sys_read+0x2a/0x40
[<c0108e67>] syscall_call+0x7/0xb
and I suspect the problem is that 0 in ds/es..
> Does the following fix it for you? Untested, assumes cache lines are 32
> bytes.
Andrew?
Linus
^ permalink raw reply
* Re: 2.5.52-wli-1
From: Jeff Garzik @ 2002-12-18 4:50 UTC (permalink / raw)
To: William Lee Irwin III, linux-kernel
In-Reply-To: <20021218044443.GC12812@holomorphy.com>
On Tue, Dec 17, 2002 at 08:44:43PM -0800, William Lee Irwin III wrote:
> Available from:
> ftp://ftp.kernel.org/pub/linux/kernel/people/wli/kernels/2.5.52-wli-1/
>
> Notable events:
>
> (1) I switched to mainline releases since intermediate -bk snapshots
> vaporize after the following mainline release.
hpa has rightly criticized my snapshot script for doing this, so this
should actually be fixed on my end not yours :)
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-18 4:49 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ulrich Drepper, Matti Aarnio, Hugh Dickins, Dave Jones,
Ingo Molnar, linux-kernel
In-Reply-To: <3DFFFBF1.7000507@transmeta.com>
On Tue, 17 Dec 2002, H. Peter Anvin wrote:
>
> This confuses me -- there seems to be no reason this shouldn't work as
> long as %esp == %ebp on sysexit. The SYSEXIT-trashed GPRs seem like a
> bigger problem.
The thing is, the argument save area == the kernel stack frame. This is
part of the reason why Linux has very fast system calls - there is
absolutely _zero_ extraneous setup. No argument fetching and marshalling,
it's all part of just setting up the regular kernel stack.
So to get the right argument in arg6, the argument _needs_ to be saved in
the %ebp entry on the kernel stack. Which means that on return from the
system call (which may not actually be through a "sysenter" at all, if
signals happen it will go through the generic paths), %ebp will have been
updated as part of the kernel stack unwinding.
Which is ok for a regular fast system call (ebp will get restored
immediately), but it is NOT ok for the system call restart case, since in
that case we want %ebp to contain the old stack pointer, not the sixth
argument.
If we just save the stack pointer value (== the initial %ebx value), the
right thing will get restored, but then system calls will see the stack
pointer value as arg6 - because of the 1:1 relationship between arguments
and stack save.
Linus
^ permalink raw reply
* 2.5.52-wli-1
From: William Lee Irwin III @ 2002-12-18 4:44 UTC (permalink / raw)
To: linux-kernel
Available from:
ftp://ftp.kernel.org/pub/linux/kernel/people/wli/kernels/2.5.52-wli-1/
Notable events:
(1) I switched to mainline releases since intermediate -bk snapshots
vaporize after the following mainline release.
(2) The driverfs oops fix got merged.
(3) A new patch dynamically sizes the pidhash to save memory on tiny boxen.
(4) A new patch has a small experiment with pte_chain pointer block sizes.
01_numaq_io
My NUMA-Q has PCI-PCI bridges and I've not quite gotten
them working yet. Here's the workaround. If someone
would be kind enough to make PCI segments not require
3 cleanup passes and an accessor that changes semantics
between each pass and after the last one I'd be much obliged.
02_do_sak
Update __do_SAK() to use for_each_task_pid(). It was
looking for all tasks in a given session.
03_proc_super
Keep count of real processes (not threads) and don't
walk the tasklist in proc_fill_super().
04_cap_set_pg
Use for_each_task_pid() in cap_set_pg(). It's trying
to find all tasks in a given pgrp.
05_vm86 Bugfix for not using release on exit() but instead
scanning for a matching task pointer, which is oopsable.
06_uml_get_task
get_task() is attempting to do find_task_by_pid().
Call find_task_by_pid() and remove tasklist scanning.
07_numaq_mem_map
Speed up NUMA-Q mem_map initialization by freeing
higher-order pages during highpage init.
08_numaq_pgdat
Allocate pgdat's from node-local memory on NUMA-Q.
09_has_stopped_jobs
Remove the unused has_stopped_jobs() function and
rename __has_stopped_jobs() to has_stopped_jobs().
10_inode_wait
Increase the size of the inode wait table.
11_pgd_ctor
Use slab ctor's to reduce the initialization costs of
PAE pgd's and pmd's.
12_pidhash_size
Dynamically size the pidhash hashtable at boot-time,
proportional to memory. 128KB isn't used until 1GB RAM.
Kernel BSS reduced by (almost) 128KB.
13_rmap_nrpte
Try forcibly increasing NRPTE to just slightly above the
mean pte_chain length for theoretically less allocation
overhead and/or L2 cache footprint (note: they're already
>= L1_CACHE_BYTES). If this doesn't work, all you'll get
is internal fragmentation (measurable by comparing the
slab info to nr_reverse_maps).
I'm not 100% sure I want to keep core VM stuff in here...
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Stephen Rothwell @ 2002-12-18 4:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: LKML, Andrew Morton
In-Reply-To: <Pine.LNX.4.44.0212172005500.1230-100000@home.transmeta.com>
Hi Linus, Andrew,
On Tue, 17 Dec 2002 20:07:53 -0800 (PST) Linus Torvalds <torvalds@transmeta.com> wrote:
>
> Btw, on another tangent - Andrew Morton reports that APM is unhappy about
> the fact that the fast system call stuff required us to move the segments
> around a bit. That's probably because the APM code has the old APM segment
> numbers hardcoded somewhere, but I don't see where (I certainly knew about
> the segment number issue, and tried to update the cases I saw).
I looked at this yesterday and decided that it was OK as well.
> Debugging help would be appreciated, especially from somebody who knows
> the APM code.
It would help to know what "unhappy" means :-)
Does the following fix it for you? Untested, assumes cache lines are 32
bytes.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff -ruN 2.5.52-200212181207/include/asm-i386/segment.h 2.5.52-200212181207-apm/include/asm-i386/segment.h
--- 2.5.52-200212181207/include/asm-i386/segment.h 2002-12-18 15:25:48.000000000 +1100
+++ 2.5.52-200212181207-apm/include/asm-i386/segment.h 2002-12-18 15:38:34.000000000 +1100
@@ -65,9 +65,9 @@
#define GDT_ENTRY_APMBIOS_BASE (GDT_ENTRY_KERNEL_BASE + 11)
/*
- * The GDT has 23 entries but we pad it to cacheline boundary:
+ * The GDT has 25 entries but we pad it to cacheline boundary:
*/
-#define GDT_ENTRIES 24
+#define GDT_ENTRIES 28
#define GDT_SIZE (GDT_ENTRIES * 8)
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-18 4:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ulrich Drepper, Matti Aarnio, Hugh Dickins, Dave Jones,
Ingo Molnar, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212171716020.1362-100000@home.transmeta.com>
Linus Torvalds wrote:
> On Tue, 17 Dec 2002, Linus Torvalds wrote:
>
>>How about this diff? It does both the 6-parameter thing _and_ the
>>AT_SYSINFO addition.
>
>
> The 6-parameter thing is broken. It's clever, but playing games with %ebp
> is not going to work with restarting of the system call - we need to
> restart with the proper %ebp.
>
This confuses me -- there seems to be no reason this shouldn't work as
long as %esp == %ebp on sysexit. The SYSEXIT-trashed GPRs seem like a
bigger problem.
-hpa
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-18 4:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ulrich Drepper, Nakajima, Jun, Matti Aarnio, Hugh Dickins,
Dave Jones, Ingo Molnar, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212171956170.1230-100000@home.transmeta.com>
Linus Torvalds wrote:
>>
>>Destroying %ecx is a lot less destructive than destroying %eip and %esp...
>
> Actually, as far as the kernel is concerned, they are about equally bad.
>
Right, but from a user-mode point of view it means at least one extra
instruction.
> Destroying %eip is the _least_ bad register to destroy, since the kernel
> can control that part, and it is trivial to just have a single call site.
Trivial, perhaps, but it requires a call/ret pair in userspace, which is
a fairly expensive form of push/pop.
> The good news is that since both of them suck, it's easier to make the
> six-argument decision. Since six arguments are problematic for all major
> "fast" system calls, my executive decision is to just say that
> six-argument system calls will just have to continue using the old and
> slower system call interface. It's kind of a crock, but it's simply due to
> silly CPU designers.
Oh, so you're not going to do the "read from stack" thing? (Agreed, by
the way, on the CPU design -- both SYSENTER and SYSCALL suck. SYSCALL
was changed rather substantially in x86-64 for that reason.)
-hpa
^ permalink raw reply
* Re: counting shell args
From: dashielljt @ 2002-12-18 4:13 UTC (permalink / raw)
To: Scott Taylor; +Cc: linux-admin
In-Reply-To: <5.1.1.6.0.20021217073814.01c6d4f0@mustang>
I think that was in reference to csh. I studied that about 9 or 10 years
ago and hadn't had a chance to use it since. Too much windows mind rot
between then and n now.Jude <dashielljt(at)gmpexpress-dot-net>
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-18 4:15 UTC (permalink / raw)
To: Ulrich Drepper
Cc: Matti Aarnio, Hugh Dickins, Dave Jones, Ingo Molnar, linux-kernel,
hpa
In-Reply-To: <Pine.LNX.4.44.0212171159440.1095-100000@home.transmeta.com>
On Tue, 17 Dec 2002, Linus Torvalds wrote:
>
> How about this diff? It does both the 6-parameter thing _and_ the
> AT_SYSINFO addition.
The 6-parameter thing is broken. It's clever, but playing games with %ebp
is not going to work with restarting of the system call - we need to
restart with the proper %ebp.
I pushed out the AT_SYSINFO stuff, but we're back to the "needs to use
'int $0x80' for system calls that take 6 arguments" drawing board.
The only sane way I see to fix the %ebp problem is to actually expand the
kernel "struct ptregs" to have separate "ebp" and "arg6" fields (so that
we can re-start with the right ebp, and have arg6 as the right argument on
the stack). That would work but is not really worth it.
Linus
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-18 4:15 UTC (permalink / raw)
To: Ulrich Drepper
Cc: Matti Aarnio, Hugh Dickins, Dave Jones, Ingo Molnar, linux-kernel,
hpa
In-Reply-To: <3DFF8668.9080209@redhat.com>
On Tue, 17 Dec 2002, Ulrich Drepper wrote:
> > - 0x55, /* push %ebp */
> > + 0x55, /* push %ebp */
> > + 0x5d, /* pop %ebp */
> > - 0x5d, /* pop %ebp */
>
> Instead of duplicating the push/pop %ebp just use the first one by using
No, it's not duplicating it. Look closer. It's just _moving_ it, so that
the old %ebp value will naturally be pointed to by %esp, which is what we
want.
Anyway, I reverted the %ebp games from my kernel, because they are
fundamentally not restartable and thus not really a good idea. Besides, it
might be wrong to try to optimize the fast system calls to handle six
arguments too, if that makes the (much more common case) the other system
calls slower. So the six-argument case might as well just continue to use
"int 0x80".
Linus
^ permalink raw reply
* trouble building iptables-1.2.7a on 2.4.17
From: Don Cohen @ 2002-12-18 4:02 UTC (permalink / raw)
To: netfilter, netfilter-devel
(Not sure whether this should go to user or devel list.)
Below is the transcript.
iptables-1.2.7a INSTALL says requires >=2.4.4, so 2.4.17 should work,
right? INSTALL also mentions patch-o-matic, but latest patch-o-matic
README says >= 2.4.18. Does that mean I shouldn't need it or that I
have to get an earlier patch-o-matic or what?
====
[root@router2 /root]# cd iptables-1.2.7a/
[root@router2 iptables-1.2.7a]# make KERNEL_DIR=/home/user/linux-2.4.17
Making dependencies: please wait...
Extensions found:
cc -O2 -Wall -Wunused -I/home/user/linux-2.4.17/include -Iinclude/ -DIPTABLES_VERSION=\"1.2.7a\" -fPIC -o\
extensions/libipt_ah_sh.o -c extensions/libipt_ah.c
ld -shared -o extensions/libipt_ah.so extensions/libipt_ah_sh.o
cc -O2 -Wall -Wunused -I/home/user/linux-2.4.17/include -Iinclude/ -DIPTABLES_VERSION=\"1.2.7a\" -fPIC -o\
extensions/libipt_conntrack_sh.o -c extensions/libipt_conntrack.c
In file included from extensions/libipt_conntrack.c:15:
include/linux/netfilter_ipv4/ipt_conntrack.h:28: `IP_CT_DIR_MAX' undeclared here (not in a function)
include/linux/netfilter_ipv4/ipt_conntrack.h:29: `IP_CT_DIR_MAX' undeclared here (not in a function)
include/linux/netfilter_ipv4/ipt_conntrack.h:29: `IP_CT_DIR_MAX' undeclared here (not in a function)
extensions/libipt_conntrack.c: In function `parse_status':
extensions/libipt_conntrack.c:103: `IPS_EXPECTED' undeclared (first use in this function)
extensions/libipt_conntrack.c:103: (Each undeclared identifier is reported only once
extensions/libipt_conntrack.c:103: for each function it appears in.)
extensions/libipt_conntrack.c:105: `IPS_SEEN_REPLY' undeclared (first use in this function)
extensions/libipt_conntrack.c:107: `IPS_ASSURED' undeclared (first use in this function)
extensions/libipt_conntrack.c: In function `parse':
extensions/libipt_conntrack.c:202: `IP_CT_DIR_ORIGINAL' undeclared (first use in this function)
extensions/libipt_conntrack.c:259: `IP_CT_DIR_REPLY' undeclared (first use in this function)
extensions/libipt_conntrack.c: In function `print_status':
extensions/libipt_conntrack.c:364: `IPS_EXPECTED' undeclared (first use in this function)
extensions/libipt_conntrack.c:368: `IPS_SEEN_REPLY' undeclared (first use in this function)
extensions/libipt_conntrack.c:372: `IPS_ASSURED' undeclared (first use in this function)
extensions/libipt_conntrack.c: In function `matchinfo_print':
extensions/libipt_conntrack.c:420: `IP_CT_DIR_ORIGINAL' undeclared (first use in this function)
extensions/libipt_conntrack.c:440: `IP_CT_DIR_REPLY' undeclared (first use in this function)
make: *** [extensions/libipt_conntrack_sh.o] Error 1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.