* 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] 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: 2.4.20, .text.lock.swap cpu usage? (ibm x440) [rescued]
From: Brian Tinsley @ 2003-01-10 18:34 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: linux-kernel
>
>We're straying from the subject here.
>
Sorry
>Please describe your machine,
>in terms of how many cpus it has and how much highmem it has, and
>your workload, so I can better determine the issue. Perhaps we can
>cooperatively devise something that works well for you.
>
IBM x360
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.
-
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] 2.5.55 fix etherleak in 8390.c [rescued]
From: Rudmer van Dijk @ 2003-01-10 18:35 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linux-kernel
this is the fix which went in 2.4.21-pre3-ac2, rediffed against 2.5.55
Rudmer
--- linux-2.5.55/drivers/net/8390.c.orig 2003-01-10 16:23:44.000000000 +0100
+++ linux-2.5.55/drivers/net/8390.c 2003-01-10 16:23:00.000000000 +0100
@@ -270,6 +270,7 @@
struct ei_device *ei_local = (struct ei_device *) dev->priv;
int length, send_length, output_page;
unsigned long flags;
+ char scratch[ETH_ZLEN];
length = skb->len;
@@ -341,7 +342,15 @@
* trigger the send later, upon receiving a Tx done interrupt.
*/
- ei_block_output(dev, length, skb->data, output_page);
+ if (length == send_length)
+ ei_block_output(dev, length, skb->data, output_page);
+ else
+ {
+ memset(scratch, 0, ETH_ZLEN);
+ memcpy(scratch, skb->data, skb->len);
+ ei_block_output(dev, ETH_ZLEN, scratch, output_page);
+ }
+
if (! ei_local->txing)
{
ei_local->txing = 1;
@@ -373,7 +382,14 @@
* reasonable hardware if you only use one Tx buffer.
*/
- ei_block_output(dev, length, skb->data, ei_local->tx_start_page);
+ if(length == send_length)
+ ei_block_output(dev, length, skb->data, ei_local->tx_start_page);
+ else
+ {
+ memset(scratch, 0, ETH_ZLEN);
+ memcpy(scratch, skb->data, skb->len);
+ ei_block_output(dev, ETH_ZLEN, scratch, ei_local->tx_start_page);
+ }
ei_local->txing = 1;
NS8390_trigger_send(dev, send_length, ei_local->tx_start_page);
dev->trans_start = jiffies;
-
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] Prevent .gnu.linkonce.this_module section from being merged with other sections [rescued]
From: Rusty Russell @ 2003-01-10 18:35 UTC (permalink / raw)
To: Your.message.of; +Cc: linux-kernel
> --- linux-2.5.55-moo.orig/Makefile 2003-01-09 14:03:45.000000000 +0900
> +++ linux-2.5.55-moo/Makefile 2003-01-09 14:07:36.000000000 +0900
> @@ -163,7 +164,7 @@
> MODFLAGS = -DMODULE
> CFLAGS_MODULE = $(MODFLAGS)
> AFLAGS_MODULE = $(MODFLAGS)
> -LDFLAGS_MODULE = -r
> +LDFLAGS_MODULE = -r --unique=.gnu.linkonce.this_module
No! Does this not work?
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.55/arch/v850/Makefile working-2.5.55-strlen/arch/v850/Makefile
--- linux-2.5.55/arch/v850/Makefile 2003-01-02 12:46:15.000000000 +1100
+++ working-2.5.55-strlen/arch/v850/Makefile 2003-01-10 19:32:09.000000000 +1100
@@ -24,7 +24,7 @@ CFLAGS += -D__linux__ -DUTS_SYSNAME=\"uC
LDFLAGS_BLOB := -b binary --oformat elf32-little
OBJCOPY_FLAGS_BLOB := -I binary -O elf32-little -B v850e
-
+LDFLAGS_MODULE += --unique=.gnu.linkonce.this_module
HEAD := $(arch_dir)/kernel/head.o $(arch_dir)/kernel/init_task.o
core-y += $(arch_dir)/kernel/
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: What's in a name?
From: Richard B. Johnson @ 2003-01-10 18:36 UTC (permalink / raw)
To: Hell.Surfers; +Cc: vlad, jalvo, linux-kernel, rms
In-Reply-To: <0b9ad5923170a13DTVMAIL1@smtp.cwctv.net>
On Fri, 10 Jan 2003 Hell.Surfers@cwctv.net wrote:
> what early distribution? grep gpl and lgpl...
>
> -- DM.
>
Yggdrasl (or however you spell it). Most binary files have
the date of Feb 26, 1996. Many text files have the date of
July 11, 1995. I have sources, many with the dates of
Aug 31, 1992:
-rw-r--r-- 1 root bin 4502 Aug 31 1992 CHANGES
-rw-r--r-- 1 root bin 1658 Aug 31 1992 README
-rw-r--r-- 1 root bin 2029 Aug 31 1992 brac.c
-rw-r--r-- 1 root bin 11258 Aug 31 1992 ch.c
-rw-r--r-- 1 root bin 3534 Aug 31 1992 charset.c
[SNIPPED...]
In those days very few persons even heard of GPL.
These are the only gpl or GPL strings found in any binaries.
sub showGPL {
last if (/^{END OF GPL COPYRIGHT}$/) ;
last if (/^{END OF GPL CONDITIONS}$/) ;
&showGPL unless $QUIET ;
{END OF GPL COPYRIGHT}
{END OF GPL CONDITIONS}
To appear in SIGPLAN Conference on Programming Language Design
label .about.gpl3 -text "Pulic License (GPL)"
Note that "Public" is even spelled incorrectly!
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
* Re: [2.5.54][PATCH] SB16 convertation to new PnP layer. [rescued]
From: Shawn Starr @ 2003-01-10 18:34 UTC (permalink / raw)
To: Ruslan U. Zakirov; +Cc: Linux Kernel
EMU8000 w/ 2MB installed.
It's using OSS under 2.4 right now and I'd like to try this. Does it work for
OSS? I don't want to build the ALSA userland tools right now ;-)
Shawn.
-
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" [rescued]
From: Oliver Xymoron @ 2003-01-10 18:34 UTC (permalink / raw)
To: E18Wlsj-0000Zr-00; +Cc: lm, linux-kernel
[GNU/Linux stuff deleted]
Can we all agree that this is indeed the kernel list and that the
kernel is indeed known as simply 'Linux' and that therefore the
GNU/Linux debate is off-topic here?
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
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
* BLKBSZSET still not working on 2.4.18 ? [rescued]
From: Ludovic Drolez @ 2003-01-10 18:33 UTC (permalink / raw)
To: linux-kernel
I'm trying to backup a partition on an IDE drive which has an odd number
of sectors (204939). With a stock open/read you cannot access the last
sector, and that why I tried the BLKBSZSET ioctl to set the basic read
block size to 512 bytes. I verified the writen value with BLKBSZGET
ioctl, but I still cannot read this last sector !
I've tried also this:
- FreeBSD : works but it don't want to port all my software to it
- raw devices: can't read the last sector:
# raw /dev/raw1 /dev/hda2
# dd if=/dev/raw1 of=C bs=512
dd: reading `/dev/raw1': No such device or address
204938+0 records in
204938+0 records out
What can it do ? Wait for a patch in 2.5.xxx ?
TIA,
Ludovic Drolez.
-
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: XFree86 vs. 2.5.54 - reboot [rescued]
From: Bob_Tracy(0000) @ 2003-01-10 18:33 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
> > > "Bob_Tracy(0000)" wrote:
> > > > AMD K6-III 450 running a 2.4.19 kernel with vesafb, XFree86 4.1.0, and
> > > > a USB mouse works fine. Same setup with a 2.5.54 kernel does a cold
> > > > reboot when I type "startx".
>
> Yup. It must be something else then. Perhaps you should try disabling
> various DRM/AGP type things in config, see if that helps.
I wrote:
> 2.5.55 appears to work fine with CONFIG_AGP and CONFIG_DRM undefined.
> I'll retry with CONFIG_AGP_MODULE next...
CONFIG_AGP_MODULE enabled works fine with CONFIG_AGP_VIA_MODULE. I'll try
turning everything back on (AGP 3.0 compliance, DRM) and see what happens.
--
-----------------------------------------------------------------------
Bob Tracy WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------
-
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: William Lee Irwin III @ 2003-01-10 18:33 UTC (permalink / raw)
To: 3E1E410E.5050905; +Cc: linux-kernel
>> IMHO multiprogramming is as valid a use for memory as any other. Or
>> even otherwise, it's not something I care to get in design debates
>> about, it's just how the things are used.
On Thu, Jan 09, 2003 at 09:42:06PM -0600, Brian Tinsley wrote:
> I agree with the philosophy in general, but if I sit down to write a
> threaded application for Linux on IA-32 and wind up with a design that
> uses 800+ threads in any instance (other than a bug, which was our
> case), it's time to give up the day job and start riding on the back of
> the garbage truck ;)
I could care less what userspace does: mechanism, not policy. Userspace
wants, and I give if I can, just as the kernel does with system calls.
800 threads isn't even a high thread count anyway, the 2.5.x testing
was with a peak thread count of 100,000. 800 threads, even with an 8KB
stack, is no more than 6.4MB of lowmem for stacks and so shouldn't
stress the system unless many instances of it are run. I suspect your
issue is elsewhere. I'll submit accounting patches for Marcelo's and/or
Andrea's trees so you can find out what's actually going on.
William Lee Irwin III wrote:
>> Only you, if anyone. My intentions and patchwriting efforts on the 64GB
>> and highmem multiprogramming fronts are long since public, and publicly
>> stated to be targeted at 2.7. Since there isn't a 2.7 yet, 2.5-CURRENT
>> must suffice until there is.
On Thu, Jan 09, 2003 at 09:42:06PM -0600, Brian Tinsley wrote:
> In all honesty, I would enjoy nothing more than contributing to kernel
> development. Unfortunately it's a bit out of my scope right now (but not
> forever). If I only believed aliens seeded our gene pool with clones, I
> could hook up with those folks that claim to have cloned a human and get
> one of me made! ;)
I don't know what to tell you here. I'm lucky that this is my day job
and that I can contribute so much. However, there are plenty who
contribute major changes (many even more important than my own) without
any such sponsorship. Perhaps emulating them would satisfy your wish.
Bill
-
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
* [LARTC] Question on TC filter
From: Cheng Kwok Wing, William @ 2003-01-10 18:24 UTC (permalink / raw)
To: lartc
Hi,
I want work out a GUI interface for htb and now here
comes to the part about adding and removing classes
and filters.
Here is an example script.
TC="tc"
DEV="dev eth1"
echo "Add root qdisc, default traffic go to 1:30"
$TC qdisc add $DEV root handle 1: htb default 30
echo "Divide the traffic into different classes and
levels"
# -------- level 1 --------
$TC class add $DEV parent 1: classid 1:1 htb rate
100mbit burst 15k
# -------- level 2 --------
$TC class add $DEV parent 1:1 classid 1:10 htb rate
400kbit ceil 600kbit burst 10m
$TC class add $DEV parent 1:1 classid 1:20 htb rate
1mbit ceil 1.5mbit burst 1m
echo "SFQ for beneath these classes:"
$TC qdisc add $DEV parent 1:10 handle 10: sfq perturb
10
$TC qdisc add $DEV parent 1:20 handle 20: sfq perturb
10
echo "Add the filters which direct traffic to the
right classes:"
tc filter add $DEV parent 1: protocol ip u32 match ip
dst 192.168.0.2/32 flowid 1:10
tc filter add $DEV parent 1: protocol ip u32 match ip
dst 192.168.0.3/32 flowid 1:20
Suppose I want to remove the class 1:20. What should I
do? I need to first remove the filters with flowid
1:20, but how can I remove it independently???
If I run "tc filter del $DEV parent 1:0......", then
all filters will be removed. Any suggestion on how to
solve this problem or a better way to organise the
classes or filters??
Thanks in advance,
William
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440) [rescued]
From: William Lee Irwin III @ 2003-01-10 18:32 UTC (permalink / raw)
To: 3E1E50FB.4000301; +Cc: linux-kernel
>> Or perhaps the kernel version is not up-to-date. Please also provide
>> the precise kernel version (and included patches). And workload too.
On Thu, Jan 09, 2003 at 10:50:03PM -0600, Brian Tinsley wrote:
> 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.
Okay, can you try with either 2.4.x-aa or 2.5.x-CURRENT?
I'm suspecting either bh problems or lowpte problems.
Also, could you monitor your load with the scripts I posted?
Thanks,
Bill
-
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
* Names as origin component paths...
From: Mark Mielke @ 2003-01-10 18:38 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.
There is a reason why I am not named Mark Mielke-Newman, and our newborn
son is not named Ethan Mielke-Herighty-Newman-Marr.
Some people like to maintain origin when deriving new names. Other
people realize that the practice is impractical, and the consequence,
if followed to the natural extreme, would allow for an exponentially
increasing length in name as each generation passes.
If you properly attributed the origins of GNU projects, I think you
would find an extremely impractical naming convention. GNU, and GNU
software, is not 100% derivative free.
Linux itself does not require any GNU software at all, except in the
sense that it happens to use GNU software, and it may therefore rely
on extensions that only exist in GNU software, however, that does not
stop anybody else from enhancing their own products to include the
GNU extensions. Freedom is as freedom does.
If you want to bug RedHat to call their distribution RedHat GNU/Linux,
go right ahead.
As for "Linux", its only real attachment to GNU is that it happens to
use a qualified reference to the GPL as its licensing restrictions. Not
all GPL software is "GNU" software.
So please... stop... You are not helping the free software movement by
(badly) arguing minor technicalities. Your previous efforts have been
very well received and respected. Don't ruin this.
mark
--
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
^ permalink raw reply
* Re: [RFC][PATCH][FBDEV]: Setting fbcon's windows size
From: James Simmons @ 2003-01-10 18:18 UTC (permalink / raw)
To: Antonino Daplas; +Cc: Linux Fbdev development list, Linux Kernel List
In-Reply-To: <1042000922.1049.101.camel@localhost.localdomain>
> Here's an improved GTF implementation. I was a bit delayed because I
> was trying to find a way to do square roots without using floating
> point. The diff is against linux-2.5.54 + your latest fbdev.diff.
Applied.
> but is more or less usable. Tested with i810fb and rivafb. (For rivafb,
> I have to use a hacked version. The latest one does not work for the
> riva128).
What hack did you do? That is based on the latest riva driver from 2.4.2X.
> BTW, I downloaded the source code of read-edid, and it seems that the
> following monitor limits are parsable from the EDID block: HorizSync,
> VertRefresh, DotClock, and GTF capability. We may change info->monspecs
> to match that. Also, the EDID contains a list of supported modes, but
> there's only 4 of them(?).
I figured monspec would have to be improved. I'm looking into the EDID
info right now. I'm also looking at read-edid. Next I need to figure out
how to use i2c to get this info.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* [U-Boot-Users] PPCBoot vxworks question
From: Chris Hallinan @ 2003-01-10 18:18 UTC (permalink / raw)
To: u-boot
In-Reply-To: <3E1F0580.3050801@jpl.nasa.gov>
Well, I don't know what the VxWorks bootloader does, but I know
PPCBoot/U-Boot. In order to get any of the boot[x] commands to
work, it assumes you have the kernel image loaded into memory
already. For example, to load and execute the Linux kernel, here is
one method assuming you have a properly functioning Ethernet i/f and
a tftpserver.
tftpboot 400000 linux-ppcboot-image
bootm 400000
The first line loads the kernel image into memory at my chosen
address of 0x40_0000 and the second line transfers control to it.
The other thing you must do for this to work is to put the PPCBoot /
U-Boot header on your kernel image using the mkimage utility that
comes with U-Boot. The README file in U-Boot distribution contains
this info and much more!
-Chris Hallinan
DS4.COM, Inc
> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net]On
> Behalf Of Timothy
> Canham
> Sent: Friday, January 10, 2003 12:40 PM
> To: u-boot-users at lists.sourceforge.net
> Subject: [U-Boot-Users] PPCBoot vxworks question
>
>
> I am new to the list and new to PPCBoot/UBoot, so
> apologies in advance
> if this is old territory. I am trying to load a vxworks
> kernel located
> on an external server, using the typical vxworks boot
> loader. i.e., the
> vxworks boot loader loads a kernel from a remote server
> using rsh and
> jumps to it. From what I can see, PPCBoot has the bootvx
> command, but it
> appears to require that the vxworks kernel already be
> loaded to work.
>
> Can someone post the equivalent procedure to duplicate in
> PPCBoot what
> the vxworks boot loader does?
>
> --
> -------
> Timothy K. Canham
> Isaiah 26:3
> tim at timcanham.com
> http://www.timcanham.com
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =
> Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
^ permalink raw reply
* Re: [parisc-linux] new gcc-default for hppa
From: jsoe0708 @ 2003-01-10 18:18 UTC (permalink / raw)
To: Randolph Chung; +Cc: parisc-linux, debian-hppa
In-Reply-To: <20030110170905.GG26261@tausq.org>
>> I do notice that unstable debian for i386 switch (or will very soon)
gcc-default
>> to gcc-3.2. Is it also true for hppa? (am I anxious about compiling ne=
w
>> kernel with this because of pb encounter with network connection)
>
>yes:
>
>tausq@auric:~$ madison gcc|grep unstable
> gcc | 2:3.1-1 | unstable | hurd-i386
> gcc | 3:3.2.2-0 | unstable | alpha, arm, hppa, i386, ia64,
m68k,
>mips, mipsel, powerpc, s390, sparc
>
Thanks I will so wait before updating all my 2 test server (a b180 & a b2=
k)
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: [parisc-linux] new gcc-default for hppa
From: jsoe0708 @ 2003-01-10 18:18 UTC (permalink / raw)
To: Randolph Chung; +Cc: parisc-linux, debian-hppa
In-Reply-To: <20030110170905.GG26261@tausq.org>
>> I do notice that unstable debian for i386 switch (or will very soon)
gcc-default
>> to gcc-3.2. Is it also true for hppa? (am I anxious about compiling ne=
w
>> kernel with this because of pb encounter with network connection)
>
>yes:
>
>tausq@auric:~$ madison gcc|grep unstable
> gcc | 2:3.1-1 | unstable | hurd-i386
> gcc | 3:3.2.2-0 | unstable | alpha, arm, hppa, i386, ia64,
m68k,
>mips, mipsel, powerpc, s390, sparc
>
Thanks I will so wait before updating all my 2 test server (a b180 & a b2=
k)
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
* [PATCH] oprofile backport to 2.4.20
From: graydon hoare @ 2003-01-10 18:25 UTC (permalink / raw)
To: marcelo tosatti; +Cc: lkml, oprofile-list
hi,
oprofile entered the 2.5 series after some discussion and design changes
from its initial form. will cohen and myself have backported the 2.5
driver to 2.4.20, and intend to maintain it in a nearly-synchronized
state with the 2.5 driver, for future 2.4 releases. this driver shipped
with our recent phoebe beta. the patch is located at:
http://people.redhat.com/graydon/linux-2.4.20-oprofile-public-1.patch
future updates will appear in my directory there. we are interested in
any feedback, and also curious as to the possibility of integrating some
or all of this patch into marcelo's 2.4 tree.
direct followups appreciated; I am not subscribed to lkml.
-graydon
^ permalink raw reply
* Re: Problem in IDE Disks cache handling in kernel 2.4.XX
From: Jens Axboe @ 2003-01-10 18:25 UTC (permalink / raw)
To: Alan Cox
Cc: Andre Hedrick, fverscheure, Linux Kernel Mailing List,
Marcelo Tosatti
In-Reply-To: <1042222339.32175.3.camel@irongate.swansea.linux.org.uk>
On Fri, Jan 10 2003, Alan Cox wrote:
> On Fri, 2003-01-10 at 16:48, Jens Axboe wrote:
> > In the barrier patches, I just used drive->quiet to supress ide_error()
> > complaining too much (on cache flushes, too). Whether that's per-drive
> > of per-hwif entity, dunno...
>
> Commands are queued per hwif so it doesn't actually matter I suspect.
True
> BTW do you plan to fix up the oopses in the tcq code or should I just mark
> it disabled for anyone who has the time to finish the job ? There are a
> whole pile of drivers that fail with tcq - mostly because they have custom
> dma end functions
Yes I will get around to it, probably next week.
--
Jens Axboe
^ permalink raw reply
* Re: [Linux-fbdev-devel] [RFC][PATCH][FBDEV]: Setting fbcon's windows size
From: James Simmons @ 2003-01-10 18:18 UTC (permalink / raw)
To: Antonino Daplas; +Cc: Linux Fbdev development list, Linux Kernel List
In-Reply-To: <1042000922.1049.101.camel@localhost.localdomain>
> Here's an improved GTF implementation. I was a bit delayed because I
> was trying to find a way to do square roots without using floating
> point. The diff is against linux-2.5.54 + your latest fbdev.diff.
Applied.
> but is more or less usable. Tested with i810fb and rivafb. (For rivafb,
> I have to use a hacked version. The latest one does not work for the
> riva128).
What hack did you do? That is based on the latest riva driver from 2.4.2X.
> BTW, I downloaded the source code of read-edid, and it seems that the
> following monitor limits are parsable from the EDID block: HorizSync,
> VertRefresh, DotClock, and GTF capability. We may change info->monspecs
> to match that. Also, the EDID contains a list of supported modes, but
> there's only 4 of them(?).
I figured monspec would have to be improved. I'm looking into the EDID
info right now. I'm also looking at read-edid. Next I need to figure out
how to use i2c to get this info.
^ permalink raw reply
* RE: [parisc-linux] Re: floating point exception error
From: Jim Hull @ 2003-01-10 18:08 UTC (permalink / raw)
To: 'Randolph Chung', 'John David Anglin'; +Cc: parisc-linux
In-Reply-To: <20030110075441.GD31470@tausq.org>
Randolph wrote:
> i looked at this some more.. it's not that the fcnv instruction is not
> implemented by the processor, but we seem to be falling into
> one of the overflow/underflow cases... if you adjust the value being
> converted (say remove one of the zeros), the program works without
trapping.
>
> page 10-9 of the pa20 arch manual gives the conditions under which a
> floating point conversion op will cause an unimplemented exception.
> however my reading of the text is that an exception is only generated
if
> the overflow/underflow exceptions are enabled. i've tried explicitly
> calling feclearexcept(FE_ALL_EXCEPT) before doing the fp op but it
still
> causes the unimplemented exception trap.
> The kernel debugs seem to indicate the O/U exceptions are not set as
> well....
Actually, the important architectural statement is this one, on p. 10-8:
If an implementation chooses not to execute an instruction, the
instruction signals an unimplemented exception. An unimplemented
exception always causes a delayed trap on a later floating-point
instruction. It does not change the Status Register Flag bits and
cannot be disabled.
What p. 10-9 is describing are the conditions under which the processor
is *required* to "go unimplemented" (i.e., to take an unimplemented
exception). But what p. 10-8 says is that the processor is *allowed* to
"go unimplemented" on any FP instruction at any time for any reason.
A totally unrealistic, but still allowed, implementation would be for
all multiply-add instructions to "go unimplemented" on Tuesdays, and all
multiply-subtract instructions to do so on Thursdays. A more realistic
example would be for a processor to "go unimplemented" for certain hard
corner-case combinations of operands and/or rounding modes.
In the particular case of the fcnv-unsigned-to-float instruction being
discussed in this thread, all PA-8xxx processors "go unimplemented" if
the MSB is 1 in the source operand. This explains why the trap
disappears when you "remove one of the zeros" from the operand.
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.
Can someone repeat the experiment on PA-8600 and a PA-8700 machine that
are configured identically (kernel, glibc, test program, etc.)?
-- Jim
HP PA-RISC/IPF Processor Architect
^ permalink raw reply
* PATCH: [2.4.21-pre3] Fix for SMP race condition in IDE code
From: Ross Biro @ 2003-01-10 18:12 UTC (permalink / raw)
To: Alan Cox, Andre Hedrick, Marcelo Tosatti; +Cc: Linux Kernel Mailing List
In-Reply-To: <1042222339.32175.3.camel@irongate.swansea.linux.org.uk>
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.
This problem can be triggered with the following code
cd /proc/ide
(while true; do for i in hd[a-z]; do for j in 1 2 3 ; do cat
$i/smart_values >/dev/null; done; done; done) &
(while true; do for i in hd[a-z]; do dd if=/dev/$i of=/dev/null bs=4096k
skip=0 & done; wait; done) &
And can be seen by properly instrumenting drive_cmd_intr to check for
errors.
On a dual proc machine with 4 channels on a single interrupt and 2.4.18
I expec to see an error about once every twenty minutes with the above
code. I believe it should occur much less often on 2.4.20 and above.
Drives react to this problem in different ways. Often they simply lock
up and refuse to talk to the host until they have been properly reset.
Some drives require a power cycle before they will work properly again.
This problem required the use of over 200 machines, approximately 2000
drives, a bus analyzer, and a lot of cooperation from a couple of drive
manufacturers to go from "something goes wrong once in a while" to
something we could easily reproduce.
This patch has only been minimally tested and then only with 1 brand of
ide hard drive.
----- snip ------
diff -durbB linux-2.4.20/drivers/ide/ide-cd.c
linux-2.4.20-p1/drivers/ide/ide-cd.c
--- linux-2.4.20/drivers/ide/ide-cd.c Thu Jan 9 11:14:01 2003
+++ linux-2.4.20-p1/drivers/ide/ide-cd.c Wed Jan 8 16:25:04 2003
@@ -863,11 +864,15 @@
HWIF(drive)->OUTB(drive->ctl, IDE_CONTROL_REG);
if (CDROM_CONFIG_FLAGS (drive)->drq_interrupt) {
+ unsigned long flags;
if (HWGROUP(drive)->handler != NULL)
BUG();
- ide_set_handler (drive, handler, WAIT_CMD, cdrom_timer_expiry);
+ spin_lock_irqsave(&io_request_lock, flags);
/* packet command */
HWIF(drive)->OUTB(WIN_PACKETCMD, IDE_COMMAND_REG);
+ ide_set_handler_nolock (drive, handler, WAIT_CMD,
cdrom_timer_expiry);
+ ide_delay_400ns();
+ spin_unlock_irqrestore(&io_request_lock, flags);
return ide_started;
} else {
/* packet command */
diff -durbB linux-2.4.20/drivers/ide/ide-disk.c
linux-2.4.20-p1/drivers/ide/ide-disk.c
--- linux-2.4.20/drivers/ide/ide-disk.c Thu Jan 9 11:14:01 2003
+++ linux-2.4.20-p1/drivers/ide/ide-disk.c Wed Jan 8 16:25:17 2003
@@ -467,12 +467,15 @@
#endif /* CONFIG_BLK_DEV_IDEDMA */
if (HWGROUP(drive)->handler != NULL)
BUG();
- ide_set_handler(drive, &read_intr, WAIT_CMD, NULL);
command = ((drive->mult_count) ?
((lba48) ? WIN_MULTREAD_EXT : WIN_MULTREAD) :
((lba48) ? WIN_READ_EXT : WIN_READ));
+ spin_lock_irqsave(&io_request_lock, flags);
hwif->OUTB(command, IDE_COMMAND_REG);
+ ide_set_handler_nolock(drive, &read_intr, WAIT_CMD, NULL);
+ ide_delay_400ns();
+ spin_unlock_irqrestore(&io_request_lock, flags);
return ide_started;
} else if (rq_data_dir(rq) == WRITE) {
ide_startstop_t startstop;
diff -durbB linux-2.4.20/drivers/ide/ide-dma.c
linux-2.4.20-p1/drivers/ide/ide-dma.c
--- linux-2.4.20/drivers/ide/ide-dma.c Thu Jan 9 11:14:01 2003
+++ linux-2.4.20-p1/drivers/ide/ide-dma.c Thu Jan 9 15:32:09 2003
@@ -655,6 +655,7 @@
unsigned int count = 0;
u8 dma_stat = 0, lba48 = (drive->addressing == 1) ? 1 : 0;
task_ioreg_t command = WIN_NOP;
+ unsigned long flags;
if (!(count = ide_build_dmatable(drive, rq, PCI_DMA_FROMDEVICE)))
/* try PIO instead of DMA */
@@ -673,7 +674,6 @@
/* paranoia check */
if (HWGROUP(drive)->handler != NULL)
BUG();
- ide_set_handler(drive, &ide_dma_intr, 2*WAIT_CMD, dma_timer_expiry);
/*
* FIX ME to use only ACB ide_task_t args Struct
@@ -691,7 +691,11 @@
}
#endif
/* issue cmd to drive */
+ spin_lock_irqsave(&io_request_lock, flags);
hwif->OUTB(command, IDE_COMMAND_REG);
+ ide_set_handler_nolock(drive, &ide_dma_intr, 2*WAIT_CMD,
dma_timer_expiry);
+ ide_delay_400ns();
+ spin_unlock_irqrestore(&io_request_lock, flags);
return HWIF(drive)->ide_dma_count(drive);
}
@@ -707,6 +711,7 @@
unsigned int count = 0;
u8 dma_stat = 0, lba48 = (drive->addressing == 1) ? 1 : 0;
task_ioreg_t command = WIN_NOP;
+ unsigned long flags;
if (!(count = ide_build_dmatable(drive, rq, PCI_DMA_TODEVICE)))
/* try PIO instead of DMA */
@@ -725,7 +730,6 @@
/* paranoia check */
if (HWGROUP(drive)->handler != NULL)
BUG();
- ide_set_handler(drive, &ide_dma_intr, 2*WAIT_CMD, dma_timer_expiry);
/*
* FIX ME to use only ACB ide_task_t args Struct
*/
@@ -742,7 +746,13 @@
}
#endif
/* issue cmd to drive */
+ spin_lock_irqsave(&io_request_lock, flags);
hwif->OUTB(command, IDE_COMMAND_REG);
+ ide_set_handler_nolock(drive, &ide_dma_intr,
+ 2*WAIT_CMD, dma_timer_expiry);
+ ide_delay_400ns();
+ spin_unlock_irqrestore(&io_request_lock, flags);
+
return HWIF(drive)->ide_dma_count(drive);
}
diff -durbB linux-2.4.20/drivers/ide/ide-floppy.c
linux-2.4.20-p1/drivers/ide/ide-floppy.c
--- linux-2.4.20/drivers/ide/ide-floppy.c Thu Jan 9 11:14:01 2003
+++ linux-2.4.20-p1/drivers/ide/ide-floppy.c Wed Jan 8 16:15:17 2003
@@ -1123,14 +1123,17 @@
}
if (test_bit(IDEFLOPPY_DRQ_INTERRUPT, &floppy->flags)) {
+ unsigned long flags;
if (HWGROUP(drive)->handler != NULL)
BUG();
+ /* Issue the packet command */
+ spin_lock_irqsave(&io_request_lock, flags);
+ HWIF(drive)->OUTB(WIN_PACKETCMD, IDE_COMMAND_REG);
ide_set_handler(drive,
pkt_xfer_routine,
IDEFLOPPY_WAIT_CMD,
NULL);
- /* Issue the packet command */
- HWIF(drive)->OUTB(WIN_PACKETCMD, IDE_COMMAND_REG);
+ spin_unlock_irqrestore(&io_request_lock, flags);
return ide_started;
} else {
/* Issue the packet command */
diff -durbB linux-2.4.20/drivers/ide/ide-io.c
linux-2.4.20-p1/drivers/ide/ide-io.c
--- linux-2.4.20/drivers/ide/ide-io.c Thu Jan 9 11:14:01 2003
+++ linux-2.4.20-p1/drivers/ide/ide-io.c Wed Jan 8 16:25:37 2003
@@ -363,14 +363,21 @@
void ide_cmd (ide_drive_t *drive, u8 cmd, u8 nsect, ide_handler_t *handler)
{
ide_hwif_t *hwif = HWIF(drive);
+ unsigned long flags;
+
if (HWGROUP(drive)->handler != NULL)
BUG();
- ide_set_handler(drive, handler, WAIT_CMD, NULL);
if (IDE_CONTROL_REG)
hwif->OUTB(drive->ctl,IDE_CONTROL_REG); /* clear nIEN */
SELECT_MASK(drive,0);
hwif->OUTB(nsect,IDE_NSECTOR_REG);
+
+ spin_lock_irqsave(&io_request_lock, flags);
hwif->OUTB(cmd,IDE_COMMAND_REG);
+ ide_set_handler_nolock(drive, handler, WAIT_CMD, NULL);
+ ide_delay_400ns();
+ spin_unlock_irqrestore(&io_request_lock, flags);
+
}
EXPORT_SYMBOL(ide_cmd);
diff -durbB linux-2.4.20/drivers/ide/ide-iops.c
linux-2.4.20-p1/drivers/ide/ide-iops.c
--- linux-2.4.20/drivers/ide/ide-iops.c Thu Jan 9 11:14:01 2003
+++ linux-2.4.20-p1/drivers/ide/ide-iops.c Wed Jan 8 15:54:18 2003
@@ -908,13 +908,14 @@
* timer is started to prevent us from waiting forever in case
* something goes wrong (see the ide_timer_expiry() handler later on).
*/
-void ide_set_handler (ide_drive_t *drive, ide_handler_t *handler,
+
+/* This version doesn't get the spinlock, so you must call it with a
spinlock
+ on io_request_lock. */
+void ide_set_handler_nolock (ide_drive_t *drive, ide_handler_t *handler,
unsigned int timeout, ide_expiry_t *expiry)
{
- unsigned long flags;
ide_hwgroup_t *hwgroup = HWGROUP(drive);
- spin_lock_irqsave(&io_request_lock, flags);
if (hwgroup->handler != NULL) {
printk("%s: ide_set_handler: handler not null; "
"old=%p, new=%p\n",
@@ -924,6 +925,15 @@
hwgroup->expiry = expiry;
hwgroup->timer.expires = jiffies + timeout;
add_timer(&hwgroup->timer);
+}
+
+/* This version grabs and releases the io_request_lock, so must be called
+ with out the spinlock grabbed. */
+void ide_set_handler (ide_drive_t *drive, ide_handler_t *handler,
+ unsigned int timeout, ide_expiry_t *expiry) {
+ unsigned long flags;
+ spin_lock_irqsave(&io_request_lock, flags);
+ ide_set_handler_nolock(drive, handler, timeout, expiry);
spin_unlock_irqrestore(&io_request_lock, flags);
}
diff -durbB linux-2.4.20/drivers/ide/ide-tape.c
linux-2.4.20-p1/drivers/ide/ide-tape.c
--- linux-2.4.20/drivers/ide/ide-tape.c Thu Jan 9 11:14:01 2003
+++ linux-2.4.20-p1/drivers/ide/ide-tape.c Wed Jan 8 16:20:09 2003
@@ -2457,13 +2457,17 @@
set_bit(PC_DMA_IN_PROGRESS, &pc->flags);
#endif /* CONFIG_BLK_DEV_IDEDMA */
if (test_bit(IDETAPE_DRQ_INTERRUPT, &tape->flags)) {
+ unsigned long flags;
if (HWGROUP(drive)->handler != NULL)
BUG();
- ide_set_handler(drive,
+
+ spin_lock_irqsave(&io_request_lock, flags);
+ HWIF(drive)->OUTB(WIN_PACKETCMD, IDE_COMMAND_REG);
+ ide_set_handler_nolock(drive,
&idetape_transfer_pc,
IDETAPE_WAIT_CMD,
NULL);
- HWIF(drive)->OUTB(WIN_PACKETCMD, IDE_COMMAND_REG);
+ spin_unlock_irqrestore(&io_request_lock, flags);
return ide_started;
} else {
HWIF(drive)->OUTB(WIN_PACKETCMD, IDE_COMMAND_REG);
diff -durbB linux-2.4.20/drivers/ide/ide-taskfile.c
linux-2.4.20-p1/drivers/ide/ide-taskfile.c
--- linux-2.4.20/drivers/ide/ide-taskfile.c Thu Jan 9 11:14:01 2003
+++ linux-2.4.20-p1/drivers/ide/ide-taskfile.c Wed Jan 8 16:25:43 2003
@@ -173,6 +173,7 @@
task_struct_t *taskfile = (task_struct_t *) task->tfRegister;
hob_struct_t *hobfile = (hob_struct_t *) task->hobRegister;
u8 HIHI = (drive->addressing == 1) ? 0xE0 : 0xEF;
+ unsigned long flags;
#ifdef CONFIG_IDE_TASK_IOCTL_DEBUG
void debug_taskfile(drive, task);
@@ -201,8 +202,14 @@
hwif->OUTB((taskfile->device_head & HIHI) | drive->select.all,
IDE_SELECT_REG);
if (task->handler != NULL) {
- ide_set_handler(drive, task->handler, WAIT_WORSTCASE, NULL);
+ spin_lock_irqsave(&io_request_lock, flags);
hwif->OUTB(taskfile->command, IDE_COMMAND_REG);
+ /* We need to give the drive time to set the busy
+ flag, or we may mistake an interrupt from another drive
+ for the command completion on this drive. */
+ ide_set_handler_nolock(drive, task->handler, WAIT_WORSTCASE, NULL);
+ ide_delay_400ns();
+ spin_unlock_irqrestore(&io_request_lock, flags);
if (task->prehandler != NULL)
return task->prehandler(drive, task->rq);
return ide_started;
@@ -1832,6 +1839,7 @@
ide_hwif_t *hwif = HWIF(drive);
task_struct_t *taskfile = (task_struct_t *) task->tfRegister;
hob_struct_t *hobfile = (hob_struct_t *) task->hobRegister;
+ unsigned long flags;
#if DEBUG_TASKFILE
u8 status;
#endif
@@ -1929,9 +1937,13 @@
if (task->handler == NULL)
return ide_stopped;
- ide_set_handler(drive, task->handler, WAIT_WORSTCASE, NULL);
+
/* Issue the command */
+ spin_lock_irqsave(&io_request_lock, flags);
hwif->OUTB(taskfile->command, IDE_COMMAND_REG);
+ ide_set_handler_nolock(drive, task->handler,
+ WAIT_WORSTCASE, NULL);
+ spin_unlock_irqrestore(&io_request_lock, flags);
if (task->prehandler != NULL)
return task->prehandler(drive, HWGROUP(drive)->rq);
}
diff -durbB linux-2.4.20/include/asm-i386/ide.h
linux-2.4.20-p1/include/asm-i386/ide.h
--- linux-2.4.20/include/asm-i386/ide.h Thu Jan 9 11:17:05 2003
+++ linux-2.4.20-p1/include/asm-i386/ide.h Fri Jan 10 09:54:07 2003
@@ -14,6 +14,7 @@
#ifdef __KERNEL__
#include <linux/config.h>
+#include <linux/delay.h>
#ifndef MAX_HWIFS
# ifdef CONFIG_BLK_DEV_IDEPCI
@@ -22,6 +23,16 @@
#define MAX_HWIFS 6
# endif
#endif
+
+
+
+/* The ATA spec requires 400ns delays all over the place. */
+/* Do the same fixed point trick the udelay does to get our delay. */
+#define IDE_DELAY_400NS
+static __inline__ void ide_delay_400ns(void)
+{
+ __const_udelay (400 * 4);
+}
static __inline__ int ide_default_irq(ide_ioreg_t base)
{
diff -durbB linux-2.4.20/include/linux/ide.h
linux-2.4.20-p1/include/linux/ide.h
--- linux-2.4.20/include/linux/ide.h Thu Jan 9 11:17:05 2003
+++ linux-2.4.20-p1/include/linux/ide.h Thu Jan 9 15:37:22 2003
@@ -18,6 +18,7 @@
#include <linux/bitops.h>
#include <linux/highmem.h>
#include <linux/pci.h>
+#include <linux/delay.h>
#include <asm/byteorder.h>
#include <asm/system.h>
#include <asm/hdreg.h>
@@ -354,6 +355,11 @@
#include <asm/ide.h>
+#ifndef IDE_DELAY_400NS
+#define IDE_DELAY_400NS
+static inline void ide_delay_400ns(void) { udelay(1); }
+#endif
+
/* Currently only m68k, apus and m8xx need it */
#ifdef IDE_ARCH_ACK_INTR
extern int ide_irq_lock;
@@ -1282,6 +1288,7 @@
* and also to start the safety timer.
*/
extern void ide_set_handler(ide_drive_t *, ide_handler_t *, unsigned
int, ide_expiry_t *);
+extern void ide_set_handler_nolock(ide_drive_t *, ide_handler_t *,
unsigned int, ide_expiry_t *);
/*
* Error reporting, in human readable form (luxurious, but a memory hog).
^ permalink raw reply
* Re: Undelete files on ext3 ??
From: Pavel Machek @ 2003-01-08 11:57 UTC (permalink / raw)
To: Max Valdez; +Cc: kernel
In-Reply-To: <1041911922.29225.1.camel@garaged.fis.unam.mx>
Hi!
> Is there any way to revert the stupid mistyping of "rm file *" on ext3??
Yes: power it down within 5 seconds.
Or use mc undelfs feature.
Pavel
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
^ permalink raw reply
* Re: include order for i2c-amd8111
From: Pavel Machek @ 2003-01-08 12:06 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: Rusty Russell, Pavel Machek, kernel list
In-Reply-To: <20030107114403.A5029@ucw.cz>
Hi!
> > > It seems all linux then all asm is prefered order...
> > > > > Yes, but not for any great reason, AFAICT. I think this comes under
> > the "too trivial" rule (ie. I'll accept it from the author, but not
> > someone else).
>
> The author (me ;) definitely doesn't mind you applying the patch, but
> would prefer if the one who pushed the 8111 driver into the kernel
> (Pavel) would update it to the version found in lm_sensors 2.7.0 at the
> same time.
Do you think you can mail me that file?
Pavel
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
^ 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.