* [PATCH] Re: 2.4.21-pre3-ac1/2 and CONFIG_CPU_FREQ failure [rescued]
From: Dominik Brodowski @ 2003-01-10 18:36 UTC (permalink / raw)
To: 16534.1042162736; +Cc: linux-kernel
notifier code to the version which got into 2.5.55.
Dominik
On Fri, Jan 10, 2003 at 02:38:56AM +0100, Richard A Nelson wrote:
> If CONFIG_CPU_FREQ is set, and CONFIG_SMP isn't,
> ./arch/i386/kernel/time.c will fail to compile at line 946:
>
> #if defined(CONFIG_CPU_FREQ) && !defined(CONFIG_SMP)
> cpufreq_register_notifier(&time_cpufreq_notifier_block,
> CPUFREQ_TRANSITION_NOTIFIER);
> #endif
>
> There is no definition of time_cpufreq_notifier_block
diff -ruN linux-original/arch/i386/kernel/elanfreq.c linux/arch/i386/kernel/elanfreq.c
--- linux-original/arch/i386/kernel/elanfreq.c 2003-01-10 09:40:32.000000000 +0100
+++ linux/arch/i386/kernel/elanfreq.c 2003-01-10 09:47:07.000000000 +0100
@@ -31,8 +31,6 @@
#define REG_CSCIR 0x22 /* Chip Setup and Control Index Register */
#define REG_CSCDR 0x23 /* Chip Setup and Control Data Register */
-#define SAFE_FREQ 33000 /* every Elan CPU can run at 33 MHz */
-
static struct cpufreq_driver *elanfreq_driver;
/* Module parameter */
diff -ruN linux-original/arch/i386/kernel/longhaul.c linux/arch/i386/kernel/longhaul.c
--- linux-original/arch/i386/kernel/longhaul.c 2003-01-10 09:40:32.000000000 +0100
+++ linux/arch/i386/kernel/longhaul.c 2003-01-10 09:46:56.000000000 +0100
@@ -1,5 +1,5 @@
/*
- * $Id: longhaul.c,v 1.77 2002/10/31 21:17:40 db Exp $
+ * $Id: longhaul.c,v 1.83 2003/01/02 22:16:26 db Exp $
*
* (C) 2001 Dave Jones. <davej@suse.de>
* (C) 2002 Padraig Brady. <padraig@antefacto.com>
diff -ruN linux-original/arch/i386/kernel/longrun.c linux/arch/i386/kernel/longrun.c
--- linux-original/arch/i386/kernel/longrun.c 2003-01-10 09:40:32.000000000 +0100
+++ linux/arch/i386/kernel/longrun.c 2003-01-10 09:46:50.000000000 +0100
@@ -1,5 +1,5 @@
/*
- * $Id: longrun.c,v 1.14 2002/10/31 21:17:40 db Exp $
+ * $Id: longrun.c,v 1.18 2003/01/02 22:16:26 db Exp $
*
* (C) 2002 Dominik Brodowski <linux@brodo.de>
*
diff -ruN linux-original/arch/i386/kernel/p4-clockmod.c linux/arch/i386/kernel/p4-clockmod.c
--- linux-original/arch/i386/kernel/p4-clockmod.c 2003-01-10 09:40:32.000000000 +0100
+++ linux/arch/i386/kernel/p4-clockmod.c 2003-01-10 09:46:17.000000000 +0100
@@ -213,7 +213,7 @@
}
-int __init cpufreq_p4_init(void)
+static int __init cpufreq_p4_init(void)
{
struct cpuinfo_x86 *c = cpu_data;
int cpuid;
@@ -245,6 +245,16 @@
}
printk(KERN_INFO PFX "P4/Xeon(TM) CPU On-Demand Clock Modulation available\n");
+
+ if (!stock_freq) {
+ if (cpu_khz)
+ stock_freq = cpu_khz;
+ else {
+ printk(KERN_INFO PFX "unknown core frequency - please use module parameter 'stock_freq'\n");
+ return -EINVAL;
+ }
+ }
+
driver = kmalloc(sizeof(struct cpufreq_driver) +
NR_CPUS * sizeof(struct cpufreq_policy), GFP_KERNEL);
if (!driver)
@@ -252,9 +262,6 @@
driver->policy = (struct cpufreq_policy *) (driver + 1);
- if (!stock_freq)
- stock_freq = cpu_khz;
-
#ifdef CONFIG_CPU_FREQ_24_API
for (i=0;i<NR_CPUS;i++) {
driver->cpu_cur_freq[i] = stock_freq;
@@ -290,7 +297,7 @@
}
-void __exit cpufreq_p4_exit(void)
+static void __exit cpufreq_p4_exit(void)
{
unsigned int i;
diff -ruN linux-original/arch/i386/kernel/powernow-k6.c linux/arch/i386/kernel/powernow-k6.c
--- linux-original/arch/i386/kernel/powernow-k6.c 2003-01-10 09:40:32.000000000 +0100
+++ linux/arch/i386/kernel/powernow-k6.c 2003-01-10 09:46:29.000000000 +0100
@@ -1,5 +1,5 @@
/*
- * $Id: powernow-k6.c,v 1.36 2002/10/31 21:17:40 db Exp $
+ * $Id: powernow-k6.c,v 1.42 2003/01/02 22:41:08 db Exp $
* This file was part of Powertweak Linux (http://powertweak.sf.net)
* and is shared with the Linux Kernel module.
*
diff -ruN linux-original/arch/i386/kernel/setup.c linux/arch/i386/kernel/setup.c
--- linux-original/arch/i386/kernel/setup.c 2003-01-10 09:40:32.000000000 +0100
+++ linux/arch/i386/kernel/setup.c 2003-01-10 09:42:38.000000000 +0100
@@ -104,8 +104,6 @@
#include <linux/pci.h>
#include <linux/pci_ids.h>
#include <linux/seq_file.h>
-#include <linux/notifier.h>
-#include <linux/cpufreq.h>
#include <asm/processor.h>
#include <linux/console.h>
#include <asm/mtrr.h>
@@ -209,40 +207,6 @@
#define RAMDISK_LOAD_FLAG 0x4000
-#ifdef CONFIG_CPU_FREQ
-static unsigned long loops_per_jiffy_ref = 0;
-static unsigned int ref_freq = 0;
-
-static int
-loops_per_jiffy_cpufreq_notifier(struct notifier_block *nb, unsigned long val,
- void *data)
-{
- struct cpufreq_freqs *freq = data;
-
- if (!loops_per_jiffy_ref) {
- loops_per_jiffy_ref = cpu_data[freq->cpu].loops_per_jiffy;
- ref_freq = freq->old;
- }
-
- switch (val) {
- case CPUFREQ_PRECHANGE:
- if (freq->old < freq->new)
- cpu_data[freq->cpu].loops_per_jiffy = cpufreq_scale(loops_per_jiffy_ref, ref_freq, freq->new);
- break;
- case CPUFREQ_POSTCHANGE:
- if (freq->new < freq->old)
- cpu_data[freq->cpu].loops_per_jiffy = cpufreq_scale(loops_per_jiffy_ref, ref_freq, freq->new);
- break;
- }
-
- return 0;
-}
-
-static struct notifier_block loops_per_jiffy_cpufreq_notifier_block = {
- .notifier_call = loops_per_jiffy_cpufreq_notifier
-};
-#endif
-
#ifdef CONFIG_VISWS
char visws_board_type = -1;
char visws_board_rev = -1;
@@ -2912,11 +2876,6 @@
for ( i = 0 ; i < NCAPINTS ; i++ )
boot_cpu_data.x86_capability[i] &= c->x86_capability[i];
}
-#ifdef CONFIG_CPU_FREQ
- if (c == &boot_cpu_data) {
- cpufreq_register_notifier(&loops_per_jiffy_cpufreq_notifier_block, CPUFREQ_TRANSITION_NOTIFIER);
- }
-#endif
printk(KERN_DEBUG "CPU: Common caps: %08x %08x %08x %08x\n",
boot_cpu_data.x86_capability[0],
diff -ruN linux-original/arch/i386/kernel/speedstep.c linux/arch/i386/kernel/speedstep.c
--- linux-original/arch/i386/kernel/speedstep.c 2003-01-10 09:40:32.000000000 +0100
+++ linux/arch/i386/kernel/speedstep.c 2003-01-10 09:46:41.000000000 +0100
@@ -1,5 +1,5 @@
/*
- * $Id: speedstep.c,v 1.58 2002/11/11 15:35:46 db Exp $
+ * $Id: speedstep.c,v 1.64 2003/01/02 22:16:26 db Exp $
*
* (C) 2001 Dave Jones, Arjan van de ven.
* (C) 2002 Dominik Brodowski <linux@brodo.de>
@@ -659,7 +659,7 @@
return -ENODEV;
}
- dprintk(KERN_INFO "cpufreq: Intel(R) SpeedStep(TM) support $Revision: 1.58 $\n");
+ dprintk(KERN_INFO "cpufreq: Intel(R) SpeedStep(TM) support $Revision: 1.64 $\n");
dprintk(KERN_DEBUG "cpufreq: chipset 0x%x - processor 0x%x\n",
speedstep_chipset, speedstep_processor);
diff -ruN linux-original/arch/i386/kernel/time.c linux/arch/i386/kernel/time.c
--- linux-original/arch/i386/kernel/time.c 2003-01-10 09:40:32.000000000 +0100
+++ linux/arch/i386/kernel/time.c 2003-01-10 09:45:34.000000000 +0100
@@ -42,6 +42,7 @@
#include <linux/delay.h>
#include <linux/init.h>
#include <linux/smp.h>
+#include <linux/notifier.h>
#include <linux/cpufreq.h>
#include <asm/io.h>
@@ -827,46 +828,45 @@
}
#ifdef CONFIG_CPU_FREQ
+static unsigned int ref_freq = 0;
+static unsigned long loops_per_jiffy_ref = 0;
+#ifndef CONFIG_SMP
static unsigned long fast_gettimeoffset_ref = 0;
static unsigned long cpu_khz_ref = 0;
-static unsigned int ref_freq = 0;
+#endif
static int
-tsc_cpufreq_notifier(struct notifier_block *nb, unsigned long val,
+time_cpufreq_notifier(struct notifier_block *nb, unsigned long val,
void *data)
{
struct cpufreq_freqs *freq = data;
- if (!use_tsc)
- return 0;
-
- if (!fast_gettimeoffset_ref) {
+ if (!ref_freq) {
+ ref_freq = freq->old;
+ loops_per_jiffy_ref = cpu_data[freq->cpu].loops_per_jiffy;
+#ifndef CONFIG_SMP
fast_gettimeoffset_ref = fast_gettimeoffset_quotient;
cpu_khz_ref = cpu_khz;
- ref_freq = freq->old;
+#endif
}
- switch (val) {
- case CPUFREQ_PRECHANGE:
- if (freq->old < freq->new) {
- fast_gettimeoffset_quotient = cpufreq_scale(fast_gettimeoffset_ref, freq->new, ref_freq);
- cpu_khz = cpufreq_scale(cpu_khz_ref, ref_freq, freq->new);
- }
- break;
- case CPUFREQ_POSTCHANGE:
- if (freq->new < freq->old) {
- fast_gettimeoffset_quotient = cpufreq_scale(fast_gettimeoffset_ref, freq->new, ref_freq);
- cpu_khz = cpufreq_scale(cpu_khz_ref, ref_freq, freq->new);
+ if ((val == CPUFREQ_PRECHANGE && freq->old < freq->new) ||
+ (val == CPUFREQ_POSTCHANGE && freq->old > freq->new)) {
+ cpu_data[freq->cpu].loops_per_jiffy = cpufreq_scale(loops_per_jiffy_ref, ref_freq, freq->new);
+#ifndef CONFIG_SMP
+ if (use_tsc) {
+ fast_gettimeoffset_quotient = cpufreq_scale(fast_gettimeoffset_ref, freq->new, ref_freq);
+ cpu_khz = cpufreq_scale(cpu_khz_ref, ref_freq, freq->new);
}
- break;
+#endif
}
return 0;
}
-static struct notifier_block tsc_cpufreq_notifier_block = {
- .notifier_call = tsc_cpufreq_notifier
+static struct notifier_block time_cpufreq_notifier_block = {
+ .notifier_call = time_cpufreq_notifier
};
#endif
@@ -942,7 +942,7 @@
}
}
-#if defined(CONFIG_CPU_FREQ) && !defined(CONFIG_SMP)
+#ifdef CONFIG_CPU_FREQ
cpufreq_register_notifier(&time_cpufreq_notifier_block, CPUFREQ_TRANSITION_NOTIFIER);
#endif
diff -ruN linux-original/include/linux/cpufreq.h linux/include/linux/cpufreq.h
--- linux-original/include/linux/cpufreq.h 2003-01-10 09:40:46.000000000 +0100
+++ linux/include/linux/cpufreq.h 2003-01-10 09:48:35.000000000 +0100
@@ -5,7 +5,7 @@
* (C) 2002 Dominik Brodowski <linux@brodo.de>
*
*
- * $Id: cpufreq.h,v 1.29 2002/11/11 15:35:47 db Exp $
+ * $Id: cpufreq.h,v 1.32 2003/01/02 22:16:27 db Exp $
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
diff -ruN linux-original/kernel/cpufreq.c linux/kernel/cpufreq.c
--- linux-original/kernel/cpufreq.c 2003-01-10 09:40:52.000000000 +0100
+++ linux/kernel/cpufreq.c 2003-01-10 09:47:48.000000000 +0100
@@ -4,7 +4,7 @@
* Copyright (C) 2001 Russell King
* (C) 2002 Dominik Brodowski <linux@brodo.de>
*
- * $Id: cpufreq.c,v 1.50 2002/11/11 15:35:48 db Exp $
+ * $Id: cpufreq.c,v 1.55 2003/01/10 08:39:18 db Exp $
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: Kernel hooks just to get rid of copy_[to/from]_user() and [rescued]
From: Gianni Tedesco @ 2003-01-10 18:35 UTC (permalink / raw)
To: 200301101645.39535.dark_lkml; +Cc: linux-kernel
--=-BV3ZPaNC+ZVYC1KynZll
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Fri, 2003-01-10 at 14:45, Mihnea Balta wrote:
> Hi,
>=20
> I have to implement a system which grabs udp packets off a gigabit connec=
tion,=20
> take some basic action based on what they contain, repack their data with=
a=20
> custom protocol header and send them through a gigabit ethernet interface=
on=20
> broadcast.
>=20
> I know how to do this in userspace, but I need to know if doing everyting=
in=20
> the kernel would show a considerable speed improvement due to removing=20
> syscall and memory copy overhead. The system will be quite stressed, havi=
ng=20
> to deal with around 15-20000 packets/second.
mmap() packet socket interface eliminates the need for system calls when
traffic is coming in at a high rate. The kernel -> user copy is also
eliminated, but its just replaced with a kernel -> kernel copy :P
You could perhaps also use linux socket filters to minimize the number
of packets you need to evaluate...
Check out this sample code: http://www.scaramanga.co.uk/code-fu/lincap.c
HTH
--=20
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
--=-BV3ZPaNC+ZVYC1KynZll
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQA+Huc6kbV2aYZGvn0RAgMyAJ9k8b5dBs0pDKKxGcYcpRF4q38eTwCeMwSA
JK7JWpSaYKsenks8H4jXzQk=
=pfqa
-----END PGP SIGNATURE-----
--=-BV3ZPaNC+ZVYC1KynZll--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH] Add __gpl_ksymtab section to v850 linker script [rescued]
From: Miles Bader @ 2003-01-10 18:34 UTC (permalink / raw)
To: Miles Bader; +Cc: linux-kernel
--- linux-2.5.55-moo.orig/arch/v850/vmlinux.lds.S 2002-12-24 15:01:07.000000000 +0900
+++ linux-2.5.55-moo/arch/v850/vmlinux.lds.S 2003-01-09 15:27:41.000000000 +0900
@@ -1,8 +1,8 @@
/*
* arch/v850/vmlinux.lds.S -- kernel linker script for v850 platforms
*
- * Copyright (C) 2002 NEC Electronics Corporation
- * Copyright (C) 2002 Miles Bader <miles@gnu.org>
+ * Copyright (C) 2002,03 NEC Electronics Corporation
+ * Copyright (C) 2002,03 Miles Bader <miles@gnu.org>
*
* This file is subject to the terms and conditions of the GNU General
* Public License. See the file COPYING in the main directory of this
@@ -51,6 +51,9 @@
___start___ksymtab = . ;/* Kernel symbol table. */ \
*(__ksymtab) \
___stop___ksymtab = . ; \
+ ___start___gpl_ksymtab = . ; /* Same for GPL symbols. */ \
+ *(__gpl_ksymtab) \
+ ___stop___gpl_ksymtab = . ; \
. = ALIGN (4) ; \
__etext = . ;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: exception tables in 2.5.55 [rescued]
From: Rusty Russell @ 2003-01-10 18:37 UTC (permalink / raw)
To: Your.message.of; +Cc: linux-kernel, Greg Ungerer
> I'm building for the v850, which has no MMU.
>
> Starting with 2.5.55, I'm getting link errors like:
>
> kernel/extable.c:29: undefined reference to `search_extable'
>
> I didn't have to worry about this with earlier kernels, and it looks
> like what happened is that previously arch-specific code was
> consolidated into the generic kernel.
Yes. This patch (like most of the module stuff) was written long
before the mmuless archs were merged. It didn't occur to me to look
through all the archs again.
> As far as I can see, the purpose of exception tables is to deal with
> unexpected memory access traps and on the v850, this basically can't
> happen (there's no MMU, and no way I know of to detect non-existant
> memory). So I'd like to make the generic exception handling stuff
> optional.
You can now make kernel/extable.o depend on this configuration option
(whatever you decide it should be).
And surround kernel/module.c's search_module_extables with the same
option.
It's trivial, just CC: me when you send to Linus, and I'll re-xmit if
he drops it.
> However, I'm not sure the best way to do this -- I could try to make it
> dependent on CONFIG_MMU, but are there non-MMU processors that _can_
> usefully use exception tables (in which case perhaps there should just
> be a separate CONFIG_EXTABLES or something)?
>
> [Oh, and also, please tell me if I'm mistaken about the purpose of
> these tables and really _should_ just implement them.]
No, they're for copy_to/from_user and friends. If your arch doesn't
rely on exception handling to trap wierd accesses, you can turn this
off.
Hope that helps,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440) [rescued]
From: Brian Tinsley @ 2003-01-10 18:38 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: linux-kernel
>
>Okay, can you try with either 2.4.x-aa or 2.5.x-CURRENT?
>
Yes, I *just* booted a machine with 2.4.20-aa1 in our lab. I was having
problems compiling the Linux Virtual Server code, but it's fixed now.
>I'm suspecting either bh problems or lowpte problems.
>
>Also, could you monitor your load with the scripts I posted?
>
>
Yes, they are already uploaded to a customer site and ready to go. I
need to flex the -aa1 kernel a bit before I load it there as well.
Thanks!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [parisc-linux] Re: floating point exception error
From: Randolph Chung @ 2003-01-10 18:35 UTC (permalink / raw)
To: Jim Hull; +Cc: 'John David Anglin', parisc-linux
In-Reply-To: <003101c2b8d3$477c8bb0$6763f40f@cup.hp.com>
> What it does not explain is why the original message reported a
> difference between a PA-8600 and a PA-8700. According to every internal
> HP processor document and PA-RISC FP designer I've been able to track
> down, this area of the design hasn't been changed since the original
> PA-8000, so there shouldn't be any differences in behavior.
actually it happens there too. i can reproduce the trap on pa8500,
pa8600 and pa8700 A500s.
so i guess this again points to a fp emulation bug in the kernel....
this is a bit surprising because aiui the code was lifted from hpux...
will look at this some more this weekend.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
^ permalink raw reply
* RE: Power button doesn't give events (Asus TUSL2-C)
From: Grover, Andrew @ 2003-01-10 18:32 UTC (permalink / raw)
To: Jurgen Kramer, acpi-devel
> From: Jurgen Kramer [mailto:gtm.kramer-c1aixF9oqgPk1uMJSBkQmQ@public.gmane.org]
> I am running the recent versions of ACPI on all my Linux systems and
> all but one behave. On my primary desktop, running ACPI version
> 20021212, pressing the power button doesn't result in an proper
> power/button event. Nothing happens at all. It does work under W*XP.
>
> What can be the problem here? I you need more info I am happy
> to supply.
>
> According to dmesg output my system, a Asus TUSL2-C, does pass the
> blacklist test.
Does the output from /proc/interrupts list ACPI anywhere?
Does the interrupt count increase by 1 every time you press a power
button?
What does your dmesg say about discovered buttons?
Regards -- Andy
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* RE: What's in a name?
From: Richard B. Johnson @ 2003-01-10 18:42 UTC (permalink / raw)
To: Hell.Surfers; +Cc: vlad, jalvo, linux-kernel, rms
In-Reply-To: <0d1395823170a13DTVMAIL8@smtp.cwctv.net>
On Fri, 10 Jan 2003 Hell.Surfers@cwctv.net wrote:
> what was it compiled with ;-)))
>
> -- DM.
>
No doubt a gcc compiler. I built my house with a Stanley hammer
and a Skill saw. Neither Stanley nor Skill own the house (the
bank does).
There is no tradition of attributing ownership of any works
of any kind to tool makers.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
^ permalink raw reply
* Kernel Oops with HIMEM+VM in 2.4.19,20 [rescued]
From: Anthony Lau @ 2003-01-10 18:41 UTC (permalink / raw)
To: linux-kernel
I am getting reproducible kernel oops and random segmentation
faults whenever the kernel starts using VM. Without any VM pages
being used, the system is stable.
I have tested kernels compiled with and without HIMEM support
(all other kernel config options identical). Without HIMEM 4GB
support, the system is stable for weeks. With HIMEM 4GB support,
the system starts oops'ing and seg. faulting when VM starts
being used.
My system info:
1.5GB physical RAM (MemTest86 run for 2 times, no errors)
2.0GB VM on a partition
Aopen AX34u with Via Apollo Pro 133T chipset
Sample Oops from logs:
Jan 8 08:53:59 kimagure kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000317
Jan 8 08:53:59 kimagure kernel: printing eip:
Jan 8 08:53:59 kimagure kernel: c0146053
Jan 8 08:53:59 kimagure kernel: *pde = 00000000
Jan 8 08:53:59 kimagure kernel: Oops: 0000
Jan 8 08:53:59 kimagure kernel: CPU: 0
Jan 8 08:53:59 kimagure kernel: EIP: 0010:[free_kiovec+83/108] Not tainted
Jan 8 08:53:59 kimagure kernel: EFLAGS: 00010202
Jan 8 08:53:59 kimagure kernel: eax: 00000000 ebx: df7dcc34 ecx: df7dcc44 edx: df7dcc44
Jan 8 08:53:59 kimagure kernel: esi: f6784800 edi: 00000307 ebp: 00000c59 esp: c222df4c
Jan 8 08:53:59 kimagure kernel: ds: 0018 es: 0018 ss: 0018
Jan 8 08:53:59 kimagure kernel: Process kswapd (pid: 5, stackpage=c222d000)
Jan 8 08:53:59 kimagure kernel: Stack: de765b48 de765b30 df7dcc34 c0144226 df7dcc34 00000011 000001d0 00000020
Jan 8 08:53:59 kimagure kernel: 00000006 c01444eb 000056a6 c012d760 00000006 000001d0 00000006 000001d0
Jan 8 08:53:59 kimagure kernel: c03180c8 00000000 c03180c8 c012d7af 00000020 c03180c8 00000002 c222c000
Jan 8 08:53:59 kimagure kernel: Call Trace: [destroy_inode+22/44] [sync_inodes_sb+159/468] [rw_swap_page_base+32/296]
[rw_swap_p
age_base+111/296] [rw_swap_page_base+259/296]
Jan 8 08:53:59 kimagure kernel: [rw_swap_page+54/72] [__free_pages_ok+109/612] [kernel_thread+40/56]
Jan 8 08:53:59 kimagure kernel:
Jan 8 08:53:59 kimagure kernel: Code: 8b 47 10 85 c0 74 06 53 ff d0 83 c4 04 ff 4b 2c 0f 94 c0 84
Because of the symptoms, I think that there could be some
incompatibility between Himem and the VM subsystem. Of course
I may have just configured my kernel incorrectly.
Any help is appreciated and I will gladly supply more logs
if I knew which ones would be useful.
Thanks,
Anthony Lau
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: Nvidia and its choice to read the GPL "differently"
From: Rogier Wolff @ 2003-01-10 18:41 UTC (permalink / raw)
To: Richard Stallman; +Cc: jalvo, linux-kernel
In-Reply-To: <E18WvqM-0000U7-00@fencepost.gnu.org>
On Fri, Jan 10, 2003 at 04:52:50AM -0500, Richard Stallman wrote:
> If there was an ATT/Linux and an Intel/Linux,
> having a GNU/Linux would make some sense... but that is not the way it
> is. GNU/Linux is singular, so Linux makes a reasonable contraction.
>
> It would be reasonable, if not for the fact that it gives the wrong
> idea of who developed the system and--above all--why.
Then -==YOU==- are completely mistaken about why -==I==- contributed
to Linux (the kernel & the system).
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an *
* excursion: The stable situation does not include humans. ***************
^ permalink raw reply
* Re: PATCH: [2.4.21-pre3] Fix for SMP race condition in IDE code
From: Alan Cox @ 2003-01-10 19:29 UTC (permalink / raw)
To: Ross Biro; +Cc: Andre Hedrick, Marcelo Tosatti, Linux Kernel Mailing List
In-Reply-To: <3E1F0CF5.4000304@google.com>
On Fri, 2003-01-10 at 18:12, Ross Biro wrote:
> There is a race condition in all versions of the IDE code that I've
> looked at including 2.4.18 and 2.4.21-pre3. Basically on an SMP system
> if mutiple IDE channels are on the same interrupt and 1 channel sends
> has an interrupt pending on 1 processor while the other processor is
> calling ide_set_handler, then the interrupt can be mistaken for command
> completion on both channels, and a command can be completed before it is
> even issued.
Thanks Ross. I'll go over this in some detail.
^ permalink raw reply
* Re: fb_imageblit()
From: James Simmons @ 2003-01-10 18:37 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Antonino Daplas, Linux Frame Buffer Device Development
In-Reply-To: <Pine.GSO.4.21.0301081746450.21171-100000@vervain.sonytel.be>
> Bummer, /me should read the code more thoroughfully...
>
> Perhaps renaming `{saved_,}palette' to `{saved_,}pseudo_palette' would make
> this clearer...
I renamed it.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* ACPI patches updated (20030109)
From: Grover, Andrew @ 2003-01-10 18:38 UTC (permalink / raw)
To: acpi-devel-pyega4qmqnRoyOMFzWx49A; +Cc: kernel list
Hi all,
ACPI patches based upon the 20030109 label have been released.
http://sourceforge.net/projects/acpi . The non-Linux releases will be
available at
http://developer.intel.com/technology/iapc/acpi/downloads.htm , by
tomorrow.
Regards -- Andy
----------------------------------------
09 January 2003. Summary of changes for version 20030109.
1) Linux-specific
Fixed an oops on module insertion/removal (Matthew Tippett)
(2.4) Fix to handle dynamic size of mp_irqs (Joerg Prante)
(2.5) Replace pr_debug (Randy Dunlap)
(2.5) Remove usage of CPUFREQ_ALL_CPUS (Dominik Brodowski)
(Both) Eliminate spawning of thread from timer callback, in
favor of schedule_work()
(Both) Show Lid status in /proc (Zdenek OGAR Skalak)
(Both) Added define for Fixed Function HW region (Matthew
Wilcox)
(Both) Add missing statics to button.c (Pavel Machek)
Several changes have been made to the source code translation
utility that generates the Linux Code in order to make the
code more "Linux-like":
All typedefs on structs and unions have been removed in
keeping with the Linux coding style.
Removed the non-Linux SourceSafe module revision number from
each module header.
Completed major overhaul of symbols to be lowercased for
linux. Doubled the number of symbols that are lowercased.
Fixed a problem where identifiers within procedure headers and
within quotes were not fully lower cased (they were left with
a starting capital.)
Some C macros whose only purpose is to allow the generation of
16-bit code are now completely removed in the Linux code,
increasing readability and maintainability.
2) ACPI CA Core Subsystem:
Changed the behavior of the internal Buffer-to-String
conversion function. The current ACPI specification states
that the contents of the buffer are "converted to a string of
two-character hexadecimal numbers, each separated by a space".
Unfortunately, this definition is not backwards compatible
with existing ACPI 1.0 implementations (although the behavior
was not defined in the ACPI 1.0 specification). The new
behavior simply copies data from the buffer to the string
until a null character is found or the end of the buffer is
reached. The new String object is always null terminated.
This problem was seen during the generation of _BIF battery
data where incorrect strings were returned for battery type,
etc. This will also require an errata to the ACPI
specification.
Renamed all instances of NATIVE_UINT and NATIVE_INT to
ACPI_NATIVE_UINT and ACPI_NATIVE_INT, respectively.
Copyright in all module headers (both Linux and non-Linux) has
be updated to 2003.
-----------------------------
Andrew Grover
Intel Labs / Mobile Architecture
andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: Another idea for simplifying locking in kernel/module.c [rescued]
From: Adam J. Richter @ 2003-01-10 18:37 UTC (permalink / raw)
To: rusty; +Cc: linux-kernel
>In message <200301070219.SAA12905@adam.yggdrasil.com> you write:
>> Here is a way to replace all of the specialized "stop CPU"
>> locking code in kernel/module.c with an rw_semaphore by using
>> down_read_trylock in try_module_get() and down_write when beginning to
>> unload the module.
>And now you can't modularize netfilter modules.
Why not? Last time you went looking in the networking code
for an example of something that had to increment a module reference
in a context where blocking was not allowed you ended up conceding
that you example was incorrect. If you've now found an example,
please let me know.
I just booted my gateway machine to a kernel using my
aforemetioned patch and various netfilter modules. I've surfed the
web, FTP'ed file and run irc through it. It seems to be okay.
Here is the lsmod listing from it.
Module Size Used by
iptable_nat 28324 1 [unsafe],
ip_conntrack 39788 2 iptable_nat,[unsafe],
ext2 60712 0 -
pcmcia_core 55744 0 -
i810 65816 0 -
atkbd 6820 0 -
i8042 8864 0 -
serio 4564 2 atkbd,i8042,
autofs 14992 1 -
ipt_TCPMSS 3568 1 [unsafe],
iptable_filter 2272 1 [unsafe],
ip_tables 17296 8 iptable_nat,ipt_TCPMSS,iptable_filter,[unsafe],
nfsd 111824 1 [unsafe],
exportfs 6160 1 nfsd,
nfs 132092 0 -
lockd 58736 3 nfsd,nfs,[unsafe],
sunrpc 114136 4 nfsd,nfs,lockd,[unsafe],
pppoe 14336 1 [unsafe],
pppox 3480 1 pppoe,
af_packet 20760 2 [unsafe],
ppp_async 11296 0 -
ppp_generic 30264 5 pppoe,pppox,ppp_async,
slhc 6576 1 ppp_generic,
ipv4 392804 88 iptable_nat,ip_conntrack,sunrpc,af_packet,[unsafe],
unix 23884 11 [unsafe],
sis_agp 4224 0 -
agpgart 23248 2 sis_agp,
ohci_hcd 28400 0 -
usbcore 101108 3 ohci_hcd,
ac97_codec 12432 0 -
sis900 16548 0 -
tulip 52960 2 [unsafe],
crc32 4272 2 sis900,tulip,
ext3 112232 3 -
jbd 65840 1 ext3,
mbcache 7764 2 ext2,ext3,
ide_disk 17332 5 -
ide_mod 143684 1 ide_disk,[unsafe],
Adam J. Richter __ ______________ 575 Oroville Road
adam@yggdrasil.com \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH 2.5] speedup kallsyms_lookup [rescued]
From: Hugh Dickins @ 2003-01-10 18:38 UTC (permalink / raw)
To: 1042192419.1415.49.camel; +Cc: linux-kernel, Andi Kleen
> [please cc...you know why]
>
> a patch to speed up the kallsyms_lookup() function while still doing
> compression.
> - make 4 sections: addresses, lens, stem, strings
> - only strncpy() when needed
> - no strlen() at all (only in the script)
> - save space we lose for len table by not making strings zero terminated
First impression is that it has good ideas, but seems inelegant
(always easy to make that judgment on others' code! ignore me)
and misses the main point.
In earlier mail, Andi highlighted the performance criticality of top
reading /proc/<pid>/wchan. I think we have to decide which way to
jump on that: either withdraw that functionality as too expensive,
and minimize the table size and code stupidity (all those strncpy's of
nearly 127! include/asm-i386/string.h strncpy seems in the wrong there);
or speed kallsyms_lookup as much as possible (binary chop or whatever
algorithm to locate symbol from address). The current linear search
through 6000(?) addresses is not nice, but of course the strncpy is
making it much worse.
I didn't reply to that part of Andi's mail, not because I thought it
irrelevant, quite the reverse; but because I didn't have an opinion
which way to go, and hoped someone else would chime in. I don't
see how to proceed without deciding that. CC'd rml since I believe
he fathered /proc/<pid>/wchan. Now, I'm inclined to say that anyone
worried about memory occupancy just shouldn't switch CONFIG_KALLSYMS
on, so it's speed we should aim for here.
If maximizing speed, then obviously the values should be sorted by
value (as now, unlike in my patch), and maybe we forget all about
stem compression? If minimizing memory, then a combination of your
patch and mine?
I hope I can leave this discussion to others: I just wanted to get
my symbols printing out right, and noticed the current stem compression
unnecessarily weak there; but I'm no expert on suitable algorithms.
Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440) [rescued]
From: Martin J. Bligh @ 2003-01-10 18:38 UTC (permalink / raw)
To: 3E1E50FB.4000301; +Cc: linux-kernel
> Pentium 4 Xeon MP processors
>
> 2 processor system has 4GB RAM
> 4 processor system has 8GB RAM
>
> 1 IBM ServeRAID controller
> 2 Intel PRO/1000MT NICs
> 2 QLogic 2340 Fibre Channel HBAs
>
>> Or perhaps the kernel version is not up-to-date. Please also provide
>> the precise kernel version (and included patches). And workload too.
>>
> The kernel version is stock 2.4.20 with Chris Mason's data logging and journal relocation patches for ReiserFS (neither of which are actually in use for any mounted filesystems). It is compiled for 64GB highmem support. And just to refresh, I have seen this exact behavior on stock 2.4.19 and stock 2.4.17 (no patches on either of these) also compiled with 64GB highmem support.
>
> Workload:
> When the live-lock occurs, the system is performing intensive network I/O and intensive disk reads from the fibre channel storage (i.e., the backup program is reading files from disk and transferring them to the backup server). I posted a snapshot of sar data collection earlier today showing selected stats leading up to and just after the live-lock occurs (which is noted by a ~2 minute gap in sar logging). After the live-lock is released, the only thing that stands out is an unusual increase in runtime for kswapd (as reported by ps).
>
> The various Java programs mentioned in prior postings are *mostly* idle at this point in time as it is after hours for our clients.
If you don't have any individual processes that need to be particularly
large (eg > 1Gb of data), I suggest you just cheat^Wfinesse the problem
and move PAGE_OFFSET from C0000000 to 80000000 - will give you more than
twice as much lowmem to play with. I think this might even be a config
option in RedHat kernels.
Martin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [2.4.20] e1000 as module gives unresolved symbol _mmx_memcpy [rescued]
From: Alan Cox @ 2003-01-10 18:38 UTC (permalink / raw)
To: 1042211459.2706.9.camel; +Cc: Linux Kernel Mailing List
> a) a kernel build for a VIA C3 doesn't use MMX, userspace programs can
> still use it
Basically true. It might be instructive to do more benching on this with
the C3 and MMX especially if the new cores add full prefetch stuff
> b) Both kernel and userspace can't use MMX any more
MMX is designed to need no OS support. SSE/SSE2 do need OS helpers but
not MMX.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* ACPI patches updated (20030109)
From: Grover, Andrew @ 2003-01-10 18:38 UTC (permalink / raw)
To: acpi-devel; +Cc: kernel list
Hi all,
ACPI patches based upon the 20030109 label have been released.
http://sourceforge.net/projects/acpi . The non-Linux releases will be
available at
http://developer.intel.com/technology/iapc/acpi/downloads.htm , by
tomorrow.
Regards -- Andy
----------------------------------------
09 January 2003. Summary of changes for version 20030109.
1) Linux-specific
Fixed an oops on module insertion/removal (Matthew Tippett)
(2.4) Fix to handle dynamic size of mp_irqs (Joerg Prante)
(2.5) Replace pr_debug (Randy Dunlap)
(2.5) Remove usage of CPUFREQ_ALL_CPUS (Dominik Brodowski)
(Both) Eliminate spawning of thread from timer callback, in
favor of schedule_work()
(Both) Show Lid status in /proc (Zdenek OGAR Skalak)
(Both) Added define for Fixed Function HW region (Matthew
Wilcox)
(Both) Add missing statics to button.c (Pavel Machek)
Several changes have been made to the source code translation
utility that generates the Linux Code in order to make the
code more "Linux-like":
All typedefs on structs and unions have been removed in
keeping with the Linux coding style.
Removed the non-Linux SourceSafe module revision number from
each module header.
Completed major overhaul of symbols to be lowercased for
linux. Doubled the number of symbols that are lowercased.
Fixed a problem where identifiers within procedure headers and
within quotes were not fully lower cased (they were left with
a starting capital.)
Some C macros whose only purpose is to allow the generation of
16-bit code are now completely removed in the Linux code,
increasing readability and maintainability.
2) ACPI CA Core Subsystem:
Changed the behavior of the internal Buffer-to-String
conversion function. The current ACPI specification states
that the contents of the buffer are "converted to a string of
two-character hexadecimal numbers, each separated by a space".
Unfortunately, this definition is not backwards compatible
with existing ACPI 1.0 implementations (although the behavior
was not defined in the ACPI 1.0 specification). The new
behavior simply copies data from the buffer to the string
until a null character is found or the end of the buffer is
reached. The new String object is always null terminated.
This problem was seen during the generation of _BIF battery
data where incorrect strings were returned for battery type,
etc. This will also require an errata to the ACPI
specification.
Renamed all instances of NATIVE_UINT and NATIVE_INT to
ACPI_NATIVE_UINT and ACPI_NATIVE_INT, respectively.
Copyright in all module headers (both Linux and non-Linux) has
be updated to 2003.
-----------------------------
Andrew Grover
Intel Labs / Mobile Architecture
andrew.grover@intel.com
^ permalink raw reply
* Re: any chance of 2.6.0-test*?
From: J.A. Magallon @ 2003-01-10 18:47 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0301100921460.12833-100000@home.transmeta.com>
On 2003.01.10 Linus Torvalds wrote:
>
> On Fri, 10 Jan 2003, Dave Jones wrote:
> >
> > What's happening with the OSS drivers ?
> > I'm still carrying a few hundred KB of changes from 2.4 for those.
> > I'm not going to spent a day splitting them up, commenting them and pushing
> > to Linus if we're going to be dropping various drivers.
>
> I consider them to be old drivers, the same way "hd.c" was. Not
> necessarily useful for most people, but neither was hd.c. And it was
> around for a _long_ time (heh. I needed to check. The config option is
> still there ;)
>
> So I don't see a huge reason to remove them from the sources, but we might
> well make them harder to select by mistake, for example. Right now the
> config help files aren't exactly helpful, and the OSS choice is before the
> ALSA one, which looks wrong.
>
> They should probably be marked deprecated, and if they don't get a lot of
> maintenance, that's fine.
>
> Linus
As there is a CONFIG_EXPERIMENTAL, how about a CONFIG_DEPRECATED for the
opposite edge ?
--
J.A. Magallon <jamagallon@able.es> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.1 (Cooker) for i586
Linux 2.4.21-pre2-jam2 (gcc 3.2.1 (Mandrake Linux 9.1 3.2.1-2mdk))
^ permalink raw reply
* Some 2.5.55 compile problems [rescued]
From: Joshua M. Kwan @ 2003-01-10 18:38 UTC (permalink / raw)
To: davem; +Cc: linux-kernel
--uAKRQypu60I7Lcqm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi Dave: (hope i'm addressing this issue to the right person!)
When making bzImage with the current BK I receive the following during=20
the final link process:
net/built-in.o(.text+0x4ba22): In function `xfrm_probe_algs':
: undefined reference to `crypto_alg_available'
net/built-in.o(.text+0x4ba68): In function `xfrm_probe_algs':
: undefined reference to `crypto_alg_available'
this is because ipv4 seems to depend on some Cryptographic API stuff...=20
that doesn't sound right though! Anyway, I added base Cryptographic API
support to shut it up, and the link went fine.
But this was definitely not added until recently - I was able to =20
compile all 2.5.54 BK cleanly. What's the deal now?
Regards
Josh
--uAKRQypu60I7Lcqm
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+HovZ6TRUxq22Mx4RAgy7AJ9562vM9zS09EFq5b3r6xM/DHZ1bgCgvf0N
0awrVgvTCn1st7U20vlKm1c=
=XugU
-----END PGP SIGNATURE-----
--uAKRQypu60I7Lcqm--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Fastest possible UDMA - how?
From: Michael Knigge @ 2003-01-10 18:48 UTC (permalink / raw)
To: linux-kernel
Hi all,
is it somehow possible to determine what is the fastest UDMA-Mode my
IDE-Controller supports - independant of the chipset?
Thanks,
Michael
^ permalink raw reply
* game server rules
From: Dominic Irrcher @ 2003-01-10 18:46 UTC (permalink / raw)
To: 'netfilter@lists.netfilter.org'
hi,
was wondering if anyone has successfully setup a ruleset for a quake3 server
with iptables ?
this is the ruleset i have in place so far, but i keep getting the following
error:
NET_SendPacket ERROR: Operation not permitted to <connecting ip>:27960
is there something that i am missing for the ruleset ?
iptables -A INPUT -i $IFACE1 -d $IPADDR3 -p udp --dport 27960 -m state
--state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i $IFACE1 -d $IPADDR3 -p tcp --dport 27960 -m state
--state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o $IFACE1 -s $IPADDR3 -p udp --sport 27960 -m state
--state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $IFACE1 -s $IPADDR3 -p tcp --sport 27960 -m state
--state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i $IFACE1 -d $IPADDR3 -p udp --dport 27960 -m state
--state ESTABLISHED -j ACCEPT
iptables -A INPUT -i $IFACE1 -d $IPADDR3 -p tcp --dport 27960 -m state
--state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o $IFACE1 -s $IPADDR3 -p udp --dport 27960 -m state
--state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $IFACE1 -s $IPADDR3 -p tcp --dport 27960 -m state
--state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i $IFACE1 -d $IPADDR3 -p udp --sport 27960 -m state
--state ESTABLISHED -j ACCEPT
iptables -A INPUT -i $IFACE1 -d $IPADDR3 -p tcp --sport 27960 -m state
--state ESTABLISHED -j ACCEPT
thanks in advance for any suggestions
Dom
^ permalink raw reply
* Re: [parisc-linux] unaligned accesses
From: jsoe0708 @ 2003-01-10 18:47 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: Randolph Chung, parisc-linux
In-Reply-To: <20030110170813.X26554@parcelfarce.linux.theplanet.co.uk>
>-- Original Message --
>Date: Fri, 10 Jan 2003 17:08:13 +0000
>From: Matthew Wilcox <willy@debian.org>
>To: jsoe0708@tiscali.be
>Cc: Randolph Chung <randolph@tausq.org>,
> parisc-linux@lists.parisc-linux.org
>Subject: Re: [parisc-linux] unaligned accesses
>
>
>On Fri, Jan 10, 2003 at 11:51:41AM +0100, jsoe0708@tiscali.be wrote:
>> PS: with ext3 (which I use) problem I hesitate to install 2.4.20 and
waiting
>> for 2.4.21 and evms, jfs, xfs support for this system)
>
>um, you use the data=3Dordered mount option (or whatever it was)?
>
Good question? I will investigate and let you inform.
Joel
*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be
^ permalink raw reply
* Re: fb_imageblit()
From: James Simmons @ 2003-01-10 18:47 UTC (permalink / raw)
To: Antonino Daplas; +Cc: Geert Uytterhoeven, Linux Frame Buffer Device Development
In-Reply-To: <1042112591.1037.30.camel@localhost.localdomain>
> Hopefully, exotics such as this will not export their visuals as
> truecolor or static pseudocolor because fb_set_cmap() will not be
> called. Otherwise, we'll just make it mandatory to call fb_set_cmap()
> for all visual modes requiring linux_logo.
Personally I think the best solution is to always call fb_set_cmap. Also
the other issue is the 256 versus 16 length of pseudo_palette. We might
have to have pseudo_palette either at the highest value, usually 256, or
make pseudo_palette dynamic and change its size if the color depth
changes.
> I believe the cursor inversion value is unused anymore(?), since
> fbcon_revc is gone. It has been replaced by the new cursor API which
> allows the driver more intimate handling of the cursor.
Correct. We don't need the 17th value now :-)
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: [parisc-linux] Re: floating point exception error
From: John David Anglin @ 2003-01-10 18:48 UTC (permalink / raw)
To: jim.hull; +Cc: randolph, parisc-linux
In-Reply-To: <003101c2b8d3$477c8bb0$6763f40f@cup.hp.com>
> What it does not explain is why the original message reported a
> difference between a PA-8600 and a PA-8700. According to every internal
> HP processor document and PA-RISC FP designer I've been able to track
> down, this area of the design hasn't been changed since the original
> PA-8000, so there shouldn't be any differences in behavior.
I looked at the assembly code. The original test was done under hpux.
I see that the call to ull2dbl has been optimized out of the loop. It
is just called once. So, the code probably is trapping there as well.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ 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.