* Re: [PATCH] ipt_REJECT shouldn't send replies for wrong udp csum
From: David S. Miller @ 2003-01-10 8:52 UTC (permalink / raw)
To: laforge; +Cc: netfilter-devel
In-Reply-To: <20030109144641.GI9467@sunbeam.de.gnumonks.org>
From: Harald Welte <laforge@gnumonks.org>
Date: Thu, 9 Jan 2003 15:46:41 +0100
Author: Patrick McHardy <kaber@trash.net>
ipt_REJECT sends unreachables in response to UDP packets with invalid
checksums, thereby exposing the existance of a firewall (as described
in phrack #60, "broken crc firewall spotting" (or something like this),
www.phrack.com). The patch makes ipt_REJECT verify UDP checksums if
set.
Applied, thanks.
^ permalink raw reply
* Re: 2.5.x inspiron touchpad breakage
From: Niels den Otter @ 2003-01-10 8:59 UTC (permalink / raw)
To: Andrew McGregor; +Cc: Andres Salomon, linux-kernel
In-Reply-To: <39260000.1042119837@localhost.localdomain>
On Friday, 10 January 2003, Andrew McGregor wrote:
> Works for me on an Inspiron 8000. The trackpoint does not, which is a
> known bug. Of course, the 3800 might be different...
My Dell Latitude C400 has both a touchpad and a trackpoint as well.
After a cold boot of 2.5.55 (and previous kernels) only the touchpad
appears to work. To get the trackpoint working I need to hibernate my
laptop and wake it up again. Didn't have this problem with 2.4 kernels.
-- Niels
^ permalink raw reply
* Re: Some ALSA documents on line
From: Takashi Iwai @ 2003-01-10 8:50 UTC (permalink / raw)
To: Patrick Shirkey; +Cc: alsa-devel
In-Reply-To: <3E1DA93E.2070602@boosthardware.com>
At Fri, 10 Jan 2003 01:54:22 +0900,
Patrick Shirkey wrote:
>
> Takashi Iwai wrote:
> > Hi Patrick,
>
> > - ALSA Driver API Reference
> >
> > http://www.alsa-project.org/~iwai/alsa-driver-api/index.html
> > http://www.alsa-project.org/~iwai/alsa-driver-api.pdf
> > http://www.alsa-project.org/~iwai/alsa-driver-api.sgml
> >
>
> Is this generated daily in cvs or are you doing it manually?
manually by myself.
the changes wouldn't be so frequent, i guess.
Takashi
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: [PATCH] udp nat helper support
From: David S. Miller @ 2003-01-10 8:50 UTC (permalink / raw)
To: laforge; +Cc: netfilter-devel
In-Reply-To: <20030109144512.GH9467@sunbeam.de.gnumonks.org>
From: Harald Welte <laforge@gnumonks.org>
Date: Thu, 9 Jan 2003 15:45:12 +0100
Author: Brian J. Murrell <netfilter@interlinx.bc.ca>
This patch is necessarry for UDP nat helpers (like Amanda protocol)
- make ip_nat_resize_packet() more generic (TCP and UDP)
- add ip_nat_mangle_udp_packet() function similar to
ip_nat_mangle_tcp_packet()
Applied, thanks.
^ permalink raw reply
* Re: ISO-9660 Rock Ridge gives different links different inums
From: Peter Chubb @ 2003-01-10 8:56 UTC (permalink / raw)
To: vda; +Cc: Peter Chubb, Andrew McGregor, eric, linux-kernel
In-Reply-To: <200301100634.h0A6Yps14454@Port.imtp.ilyichevsk.odessa.ua>
>>>>> "Denis" == Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> writes:
Denis> On 10 January 2003 05:34, Peter Chubb wrote:
>> Preferably, all the inumbers for the same file would point to the
>> same directory entry; but I can see no easy way to do that.
>> Keeping an in-memory table for files with multiple links might be
>> the best way, as there aren't that many on a typical filesystem.
Denis> And what will happen on a non-typical filesystem with 1 million
Denis> hardlinks?
Denis> The root of the problem is a fundamental layering violation in
Denis> traditional Unix filesystems: inode numbers should NOT be
Denis> visible to userspace. Userspace just needs a way to tell
Denis> hardlinks from separate files, that's all. Exposing inumbers
Denis> does that, but creates tons of problems for filesystems which
Denis> do NOT have such a concept.
The problem is that in Unix the fundamental identity of a file is
the tuple (blkdev, inum); names are merely indices (links) that resolve to
that tuple. Personally, I'd swap to a pair of system calls to map
name to (blkdev, inum), and open(blkdev, inum). Think of the inode
number as a unique within-filesystem index.
--
Dr Peter Chubb peterc@gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories, all almost the same.
^ permalink raw reply
* [PATCH] Re: 2.4.21-pre3-ac1/2 and CONFIG_CPU_FREQ failure
From: Dominik Brodowski @ 2003-01-10 8:54 UTC (permalink / raw)
To: Richard A Nelson, alan; +Cc: linux-kernel
In-Reply-To: <16534.1042162736@www24.gmx.net>
Sorry for that, the attached patch should fix it. It updates the timer
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
^ permalink raw reply
* Re: [PATCH] locking fix for TCP conntrack
From: David S. Miller @ 2003-01-10 8:42 UTC (permalink / raw)
To: laforge; +Cc: netfilter-devel
In-Reply-To: <20030109144206.GF9467@sunbeam.de.gnumonks.org>
From: Harald Welte <laforge@gnumonks.org>
Date: Thu, 9 Jan 2003 15:42:06 +0100
Please apply to 2.4.x and 2.5.x, thanks.
Author: Martin Josefsson <gandalf@wlug.westbo.se>
Fix a locking bug in ip_conntrack_proto_tcp.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ipt_multiport invert fix
From: David S. Miller @ 2003-01-10 8:39 UTC (permalink / raw)
To: laforge; +Cc: netfilter-devel
In-Reply-To: <20030109143412.GD9467@sunbeam.de.gnumonks.org>
From: Harald Welte <laforge@gnumonks.org>
Date: Thu, 9 Jan 2003 15:34:12 +0100
This is the first of a series of patches you will receive from me today.
Please apply to 2.4.x and 2.5.x, thanks.
Applied, thanks.
^ permalink raw reply
* Re: VIA8233/8235 testers wanted
From: Takashi Iwai @ 2003-01-10 8:37 UTC (permalink / raw)
To: Joachim Blaabjerg; +Cc: alsa-devel
In-Reply-To: <200301100917.28794.styx@gentoo.org>
At Fri, 10 Jan 2003 09:17:28 +0100,
Joachim Blaabjerg wrote:
>
> On Thursday 09 January 2003 18:01, Takashi Iwai wrote:
> > Hi,
> >
> > if someone has VIA8233, VIA8233A, VIA8233C or VIA8235 chipset, could
> > you help the testing of the new driver?
> > the new driver code is found at
> >
> > http://www.alsa-project.org/~iwai/via82xx.c
> > [...]
>
> I'm getting an unresolved symbol: snd_pcm_substream_sgbuf, and a recursive
> grep in the alsa-driver sources show only one match in, you guessed it,
> snd-via82xx.c.
please try the very latest cvs version.
(the best is to get the source via cvs, not cvs-snapshot).
there are many changes recently.
thanks,
Takashi
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* RE: detecting hyperthreading in linux 2.4.19
From: Mikael Pettersson @ 2003-01-10 8:43 UTC (permalink / raw)
To: Pallipadi, Venkatesh
Cc: Mikael Pettersson, jamesclv, Jason Lunz, linux-kernel
In-Reply-To: <C8C38546F90ABF408A5961FC01FDBF1912E20B@fmsmsx405.fm.intel.com>
Pallipadi, Venkatesh writes:
>
> > -----Original Message-----
> > From: Mikael Pettersson [mailto:mikpe@csd.uu.se]
> >
> > My performance monitoring counters driver uses this approach
> > in kernel-space
> > using smp_call_function(). I don't use the siblings tables
> > because they suck :-)
> > [I don't think they distinguish between logical CPUs #0 and
> > #1, and they aren't
> > exported to modules. The CPUID check is simple and portable
> > across kernel versions.]
>
> I believe it is better to use a OS interface to find out HT, rather than
> using CPUID. The reason being, it is possible to have HT disabled, in OS,
> even after processor and the BIOS supports it.
> 1) Consider the case when processor and BIOS supports HT, but linux
> was booted with "noht" boot option (now I am not sure whether that option is
> there in 2.4.19. But is is certainly there in some other kernels).
> 2) What about some other kernel which is totally ignorant about HT, and
> doesn't initialize logical processor (kernel which looks at MPS in place
> of ACPI)
> I think, in both these cases cpuid can still say HT is present.
With smp_call_function() I execute code on exactly those CPUs the kernel
knows about. If the physical processors support HT but the kernel can't
run on the non-#0 logical CPUs (UP kernel or "noht"), then smp_call_function()
won't reach those logical CPUs #1 and everything's fine: my test will say
"not HT" which is exactly what I want in this case.
The point about checking the "local APIC physical ID" in CPUID 1, EBX,
instead of the field in the local APIC is _exactly_ because the CPUID
data is assigned by HW and read-only, while the local APIC field can be
changed. I don't want to depend on possibly-broken MP or ACPI tables or
have to know about the kernel's physical <--> virtual CPU # mapping de jour.
> I know that sibling table is not exported. But I couldn't get your other
> comment about sibling table "they distinguish between logical CPUs #0 and #1:"
> Can you elaborate..
The sibling table tells you whether two linux-numbered CPUs are siblings,
but it doesn't tell which one is logical CPU #0 and which one is #1.
That distinction is important in some cases.
^ permalink raw reply
* Iptables -m limit problem
From: ITM CS Ruslan O. Nesterov @ 2003-01-10 8:32 UTC (permalink / raw)
To: netfilter
Hello netfilter list,
I want to limit connectionss to http port to maximum 2 persecond from
one host. I wrote the following line but it's not working :(
/usr/local/sbin/iptables -A ip_limit -p tcp --dport 80 -m limit --limit 2/second -j ACCEPT
/usr/local/sbin/iptables -A INPUT -j ip_limit
--
Best regards,
ITM mailto:ruslan@complexsystem.ru
^ permalink raw reply
* Kernel Oops with HIMEM+VM in 2.4.19,20
From: Anthony Lau @ 2003-01-10 8:37 UTC (permalink / raw)
To: linux-kernel
Hello,
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
^ permalink raw reply
* [PATCH] RPC match and conntrack modules v2.1
From: Ian Latter @ 2003-01-10 8:26 UTC (permalink / raw)
To: netfilter-devel; +Cc: marcelo.lima
Hello all,
I too had too much Xmas idle time and for some reason I couldn't get
enough coding done ... too long between programming sessions, me
thinks.
I have uploaded, to the ftp.netfilter.org site, a copy of the new patch-
o-matic ready code. Let me know what you think of it ... I don't have a
lot of need for RPC traffic filtering, but when I realised that the Linux
kernel filtering for RPCs was limited to the old "record-rpc" modules, I
had to upgrade them ... I wanted some of that CheckPoint functionality
in my favourite filtering API :oP
The new modules will allow filtering on RPC procedures (by name or
number). The intended usage of these modules would be with a ruleset
like;
# New session from client to server (rpc portmapper get)
-A PREROUTING -t nat -i eth0 -p udp -m rpc --rpcs 100002
-s ${client} --sport 0:1023 -d ${server} --dport 111
-j ACCEPT
# Continued session from client to client (port mapper answer)
-A PREROUTING -t nat -i eth1 -m state -p udp
-s ${server} --sport 111 -d ${client} --dport 0:1023
--state ESTABLISHED -j ACCEPT
# New session from client to server (procedure call)
-A PREROUTING -t nat -i eth0 -m state -p udp
-s ${client} --sport 0:65535
-d ${server} --dport 32000:34000
--state ESTABLISHED,RELATED -j ACCEPT
# Continued session from client to server (procedure response)
-A PREROUTING -t nat -i eth1 -m state -p udp
-s ${server} --sport 32000:34000
-d ${client} --dport 0:65535
--state ESTABLISHED -j ACCEPT
Which would allow rusers to execute from client to server;
user@client# rusers $server
Note that if that first rule was without the --rpcs option;
-A PREROUTING -t nat -i eth0 -p udp -m rpc
-s ${client} --sport 0:1023 -d ${server} --dport 111
-j ACCEPT
... then it would behave like the existing oldnat module; simply
"recording" RPC get commands via the portmapper, and letting
them through from the same host when they're a complete
procedure call.
Also note that I've updated the module for newnat, and it compiles
cleanly against 2.4.20. I was half tempted to author the NAT module
to go with the conntrack and match, but this code has taken too
much time already.
0f759135c2b2aae5bc39b3ed0f633749 pom-rpc-030110-01.tgz
11371 bytes size
Comments welcome and appreciated.
Regards,
--
Ian Latter
Internet and Networking Security Officer
Macquarie University
^ permalink raw reply
* Re: UnitedLinux violating GPL?
From: Hubert Mantel @ 2003-01-10 8:34 UTC (permalink / raw)
To: Jeff Garzik, linux-kernel
In-Reply-To: <20030109222748.GA3993@gtf.org>
Hi,
On Thu, Jan 09, Jeff Garzik wrote:
> Anybody know where the source rpm for UnitedLinux kernel is?
> [to be distinguished from kernel-source rpm]
Sure, it's here:
ftp.suse.com:/pub/unitedlinux/1.0/src/kernel-source-2.4.19.SuSE-82.nosrc.rpm
This RPM contains the individual patches as well as the specfile to create
the kernel-source.rpm. It's only missing the vanilla kernel source tarball
in order to save space (this tarball is available on every other ftp
server in the internet anyway).
For creation of the individual binary kernel RPMs you need the following
source RPMs which are of course also available:
-rw-r--r-- 1 root root 18972 Oct 21 21:45 k_athlon-2.4.19-111.src.rpm
-rw-r--r-- 1 root root 168055 Oct 21 22:28 k_debug-2.4.19-79.src.rpm
-rw-r--r-- 1 root root 186467 Oct 21 22:04 k_deflt-2.4.19-120.src.rpm
-rw-r--r-- 1 root root 178477 Oct 21 22:04 k_psmp-2.4.19-115.src.rpm
-rw-r--r-- 1 root root 185329 Oct 21 22:21 k_smp-2.4.19-113.src.rpm
> AFAICS they are not distributing source code to their published kernel
> binaries... which is a very obvious GPL violation.
Any chance you could check the facts before accusing people publically?
> I'm also surprised the even-more-pro-GPL-than-me people have not jumped
> on UnitedLinux for not distributing source code.
Because they are probably not too lazy to check the facts before offending
people.
> Jeff, looking for useful [rumored] drivers/net patches
-o)
Hubert Mantel Goodbye, dots... /\\
_\_v
^ permalink raw reply
* Re: [parisc-linux] unaligned accesses
From: jsoe0708 @ 2003-01-10 8:24 UTC (permalink / raw)
To: Randolph Chung; +Cc: parisc-linux
In-Reply-To: <20030110073659.GC31470@tausq.org>
>-- Original Message --
>Date: Thu, 9 Jan 2003 23:36:59 -0800
>From: Randolph Chung <randolph@tausq.org>
>To: jsoe0708@tiscali.be
>Cc: parisc-linux@lists.parisc-linux.org
>Subject: Re: [parisc-linux] unaligned accesses
>Reply-To: Randolph Chung <randolph@tausq.org>
>
>
...
>> hmmm buggy: not always, the triky case is when you have to access to
those
>> kind of data encapsulated into a structure. I do not yet find any work=
around
>> or how to fix this kind of pb. Any idea (gcc-3.3?)?
>
>eh? what do you mean?
>
well I will try to find back the example I encounter (somewhere in jfs-1.=
0.23
IIRC)
Cheers,
Joel
********************************************
Promo Tiscali ADSL: 35 Euros/mois, 1er mois et activation =3D 0 Euro http=
://adsl.tiscali.be
^ permalink raw reply
* AW: access memory mapped registers
From: Georg Klug @ 2003-01-10 8:19 UTC (permalink / raw)
To: Muaddi, Cecilia; +Cc: linuxppc-embedded
In-Reply-To: <885489B3B89FB6449F93E525DF78777F064541@srvnt506.ALLOPTIC.COM>
Hi Cecilia,
> Given that, do you know what is the convention if I need to address the GPIO
> pins in
> the 860? I have some FPGA which require me to download the FPGA code
> and they are controlled via JTAG from my GPIO pins out of 860. I can use
> mmap to map the ppc 860 internal memory (the quick dirty way just to see if
> works), or is there a driver already provided which will allow me to control
> the GPIO pins from user application?
we had a similar problem with our custom 405 board and we solved it this way:
- making a device driver which does the basic stuff like accessing the GPIOs
in the proper way.
- defining an ioctl interface that allows any application to download the
FPGA code.
- creating an user space application which takes a filename as a parameter and
sends it via the ioctls to the device driver. (we called it loadfpga)
The ioctl interface is pretty simple. It only needs just one action code
(FpgaProg) with a block of at most 4k bytes as data and an additional option
field showing the driver whether this block of data is the first one and/or the
last one.
The driver now does just some simple actions like this:
- if this is the first block do the proper initilization of the downloading
(in our case we needed to initialize the GPIOs, puls the PROG and check the
INIT signal)
- for all blocks do the signaling via the GPIO bitwise (in our case set DIN
for all bits and puls the CLK signal)
- if this was the last block do the concluding actions (in our case do some
CLK pulses and wait for the DONE signal and then take the chip out of reset)
The user space application is even simplier:
- Read the binary file in 4k blocks
- Issue an ioctl and set the bits signaling whether this block is the first
and/or the last properly.
This concept may also work for your case.
Kind regards,
Georg
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [linux-lvm] Volume Group with 4 HDs- one crashed
From: Alasdair G Kergon @ 2003-01-10 8:18 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <20030110141257.A2963@uk.sistina.com>
On Fri, Jan 10, 2003 at 02:12:57PM +0000, Alasdair Kergon wrote:
> > I also remove the devnodes left by LVM 1 (/dev/mpeg/mp3 /dev/mpeg/mpvie),
> > but still I cant access the VG's.
> Recent LVM2 tarballs deal OK with any nodes left behind like that.
> What version are you using?
Ah you said: .12
That change went into .13
vgdisplay wouldn't show them because you didn't add -P
Do a 'vgchange -an -P' and then try activating them again.
Try 'lvdisplay -P' to check if they're active, or check the attr.
columns (see man page) in the new 'lvs -P' command.
Alasdair
--
agk@uk.sistina.com
^ permalink raw reply
* Re: VIA8233/8235 testers wanted
From: Joachim Blaabjerg @ 2003-01-10 8:17 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5h7kde8dfm.wl@alsa2.suse.de>
On Thursday 09 January 2003 18:01, Takashi Iwai wrote:
> Hi,
>
> if someone has VIA8233, VIA8233A, VIA8233C or VIA8235 chipset, could
> you help the testing of the new driver?
> the new driver code is found at
>
> http://www.alsa-project.org/~iwai/via82xx.c
> [...]
I'm getting an unresolved symbol: snd_pcm_substream_sgbuf, and a recursive
grep in the alsa-driver sources show only one match in, you guessed it,
snd-via82xx.c.
Regards,
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Problem: kernel BUG at page_alloc.c:217!
From: t.widjaja1 @ 2003-01-10 8:25 UTC (permalink / raw)
To: linux-kernel
Hi,
Here is the message in /var/log/syslog
---------------------- start /var/log/syslog -----------------------------------
Jan 10 18:15:49 Widjaja kernel: kernel BUG at page_alloc.c:217!
Jan 10 18:15:49 Widjaja kernel: invalid operand: 0000
Jan 10 18:15:49 Widjaja kernel: CPU: 0
Jan 10 18:15:49 Widjaja kernel: EIP: 0010:[<c012be40>] Tainted: P
Jan 10 18:15:49 Widjaja kernel: EFLAGS: 00010092
Jan 10 18:15:49 Widjaja kernel: eax: 0001fffc ebx: c12903a4 ecx: 00001000 edx: f45e05e6
Jan 10 18:15:49 Widjaja kernel: esi: c12903a4 edi: 00000000 ebp: c0272a14 esp: da1f1eb8
Jan 10 18:15:49 Widjaja kernel: ds: 0018 es: 0018 ss: 0018
Jan 10 18:15:49 Widjaja kernel: Process wvdial (pid: 353, stackpage=da1f1000)
Jan 10 18:15:49 Widjaja kernel: Stack: c0272b80 000001ff da1889c0 00000000 00001000 0000f5e6 00000292 c0272a2c
Jan 10 18:15:49 Widjaja kernel: 00000000 c0272a14 c012c220 000001f0 da1f1f6c da1889c0 da596f00 c0272a14
Jan 10 18:15:49 Widjaja kernel: c0272b7c 000001f0 00000000 c012c016 00000000 c012c34a c013ebb3 da3ff540
Jan 10 18:15:49 Widjaja kernel: Call Trace: [<c012c220>] [<c012c016>] [<c012c34a>] [<c013ebb3>] [<c0139bd6>]
Jan 10 18:15:49 Widjaja kernel: [<c013eda6>] [<c013f1fa>] [<c0106d03>]
Jan 10 18:15:49 Widjaja kernel:
Jan 10 18:15:49 Widjaja kernel: Code: 0f 0b d9 00 13 3a 23 c0 8b 53 04 8b 03 89 50 04 89 02 c7 03
Jan 10 18:15:49 Widjaja kernel: kernel BUG at page_alloc.c:217!
Jan 10 18:15:49 Widjaja kernel: invalid operand: 0000
Jan 10 18:15:49 Widjaja kernel: CPU: 0
Jan 10 18:15:49 Widjaja kernel: EIP: 0010:[<c012be40>] Tainted: P
Jan 10 18:15:49 Widjaja kernel: EFLAGS: 00010096
Jan 10 18:15:49 Widjaja kernel: eax: 0001fffc ebx: c1527d38 ecx: 00001000 edx: f45ef735
Jan 10 18:15:49 Widjaja kernel: esi: c1527d38 edi: 00000000 ebp: c0272a14 esp: dc9d5ea8
Jan 10 18:15:49 Widjaja kernel: ds: 0018 es: 0018 ss: 0018
Jan 10 18:15:49 Widjaja kernel: Process kdeinit (pid: 314, stackpage=dc9d5000)
Jan 10 18:15:49 Widjaja kernel: Stack: c0272b80 000001ff dc819640 00000000 c012302f df6d5840 00000296 c0272a2c
Jan 10 18:15:49 Widjaja kernel: 00000000 c0272a14 c012c220 000001f0 dc9d5f6c dc819640 dca603fc c0272a14
Jan 10 18:15:49 Widjaja kernel: c0272b7c 000001f0 00000001 c012c016 00000000 c012c34a c013ebb3 dc806e80
Jan 10 18:15:49 Widjaja kernel: Call Trace: [<c012302f>] [<c012c220>] [<c012c016>] [<c012c34a>] [<c013ebb3>]
Jan 10 18:15:49 Widjaja kernel: [<c021b783>] [<c01e1ef3>] [<c013eda6>] [<c013f1fa>] [<c0106d03>]
Jan 10 18:15:49 Widjaja kernel:
Jan 10 18:15:49 Widjaja kernel: Code: 0f 0b d9 00 13 3a 23 c0 8b 53 04 8b 03 89 50 04 89 02 c7 03
Jan 10 18:16:05 Widjaja kernel: kernel BUG at page_alloc.c:217!
Jan 10 18:16:05 Widjaja kernel: invalid operand: 0000
Jan 10 18:16:05 Widjaja kernel: CPU: 0
Jan 10 18:16:05 Widjaja kernel: EIP: 0010:[<c012be40>] Tainted: P
Jan 10 18:16:05 Widjaja kernel: EFLAGS: 00013096
Jan 10 18:16:05 Widjaja kernel: eax: 0001fffc ebx: c1527d38 ecx: 00001000 edx: f45ef735
Jan 10 18:16:05 Widjaja kernel: esi: c1527d38 edi: 00000000 ebp: c0272a14 esp: dec8de50
Jan 10 18:16:05 Widjaja kernel: ds: 0018 es: 0018 ss: 0018
Jan 10 18:16:05 Widjaja kernel: Process XFree86 (pid: 254, stackpage=dec8d000)
Jan 10 18:16:05 Widjaja kernel: Stack: c0272ba0 000001ff dfe44740 00000000 e1a716ec 0001ba89 00003286 c0272a2c
Jan 10 18:16:05 Widjaja kernel: 00000000 c0272a14 c012c220 000001d2 dfe44740 dfe44740 da165ec0 c0272a14
Jan 10 18:16:05 Widjaja kdm[242]: Server for display :0 terminated unexpectedly
Jan 10 18:16:05 Widjaja kernel: c0272b9c 000001d2 c0227ac6 c012c016 00104025 c0122f54 498d3000 dfe44740
Jan 10 18:16:05 Widjaja kernel: Call Trace: [<c012c220>] [<c0227ac6>] [<c012c016>] [<c0122f54>] [<c012302f>]
Jan 10 18:16:05 Widjaja kernel: [<c01231c2>] [<c0111d83>] [<c0111c20>] [<e19814a4>] [<e1b633bb>] [<e1b610f5>]
Jan 10 18:16:05 Widjaja kernel: [<c010b6dd>] [<e1b610e0>] [<e1b610e0>] [<c010816f>] [<c010a6a8>] [<c010830c>]
Jan 10 18:16:05 Widjaja kernel: [<c0106df4>]
Jan 10 18:16:05 Widjaja kernel:
Jan 10 18:16:05 Widjaja kernel: Code: 0f 0b d9 00 13 3a 23 c0 8b 53 04 8b 03 89 50 04 89 02 c7 03
Jan 10 18:16:05 Widjaja kernel: kernel BUG at page_alloc.c:217!
Jan 10 18:16:05 Widjaja kernel: invalid operand: 0000
Jan 10 18:16:05 Widjaja kernel: CPU: 0
Jan 10 18:16:05 Widjaja kernel: EIP: 0010:[<c012be40>] Tainted: P
Jan 10 18:16:05 Widjaja kernel: EFLAGS: 00013082
Jan 10 18:16:05 Widjaja kernel: eax: 0001fffc ebx: c0232a2c ecx: 00001000 edx: ee869e0c
Jan 10 18:16:05 Widjaja kernel: esi: c0232a2c edi: 00000000 ebp: c0272a14 esp: dead5e50
Jan 10 18:16:05 Widjaja kernel: ds: 0018 es: 0018 ss: 0018
Jan 10 18:16:05 Widjaja kernel: Process XFree86 (pid: 1140, stackpage=dead5000)
Jan 10 18:16:05 Widjaja kernel: Stack: c0272ba0 000001ff dfe44c80 00000000 e1a716ec 0001baae 00003286 c0272a2c
Jan 10 18:16:05 Widjaja kernel: 00000000 c0272a14 c012c220 000001d2 dfe44c80 dfe44c80 df219540 c0272a14
Jan 10 18:16:05 Widjaja kernel: c0272b9c 000001d2 c0227ac6 c012c016 00104025 c0122f54 082ba044 dfe44c80
Jan 10 18:16:05 Widjaja kernel: Call Trace: [<c012c220>] [<c0227ac6>] [<c012c016>] [<c0122f54>] [<c012302f>]
Jan 10 18:16:05 Widjaja kernel: [<c01231c2>] [<c0111d83>] [<c0111c20>] [<c0125ce3>] [<c012601f>] [<c0125f10>]
Jan 10 18:16:05 Widjaja kernel: [<c0131b07>] [<c0106df4>]
Jan 10 18:16:05 Widjaja kernel: Code: 0f 0b d9 00 13 3a 23 c0 8b 53 04 8b 03 89 50 04 89 02 c7 03
------------------------ end /var/log/syslog -----------------------------------
This problem often arose when I was running konqueror and wvdial.
Similar things happened when I was running ssh (on X) and wvdial.
But, I have to say that this happens intermittently.
Here is the output of scripts/ver_linux for my system:
Linux Widjaja 2.4.20 #4 Mon Jan 6 00:22:22 EST 2003 i686 unknown
Gnu C 2.95.4
Gnu make 3.79.1
util-linux 2.11n
mount 2.11n
modutils 2.4.15
e2fsprogs 1.27
jfsutils 1.0.14
reiserfsprogs 3.x.1b
Linux C Library 2.2.5
Dynamic linker (ldd) 2.2.5
Procps 2.0.7
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 2.0.11
Modules Loaded ppp_deflate zlib_inflate zlib_deflate ppp_async hsfbasic2 hsfserial hsfengine hsfosspec NVdriver mousedev usbmouse hid input slip dummy bsd_comp rtc
Now, /proc/cpuinfo:
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 6
model name : AMD Athlon(TM) XP 2000+
stepping : 2
cpu MHz : 1687.552
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips : 3368.55
Now, /proc/iomem:
00000000-0009ffff : System RAM
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-1fffbfff : System RAM
00100000-0022c50a : Kernel code
0022c50b-002a9dd7 : Kernel data
1fffc000-1fffefff : ACPI Tables
1ffff000-1fffffff : ACPI Non-volatile Storage
d8000000-d800ffff : Rockwell International HCF 56k Data/Fax/Voice/Spkp (w/Handset) Modem
d8800000-d88000ff : VIA Technologies, Inc. USB 2.0
d9000000-d9003fff : Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link)
d9800000-d98007ff : Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link)
da000000-db6fffff : PCI Bus #01
da000000-daffffff : nVidia Corporation NV17 [GeForce4 MX420]
db700000-dfffffff : PCI Bus #01
db800000-db87ffff : nVidia Corporation NV17 [GeForce4 MX420]
dc000000-dfffffff : nVidia Corporation NV17 [GeForce4 MX420]
e0000000-e7ffffff : VIA Technologies, Inc. VT8367 [KT266]
fec00000-fec00fff : reserved
fee00000-fee00fff : reserved
ffff0000-ffffffff : reserved
Now, the result of 'lspci -vvv':
-------------------- start 'lspci -vvv' ----------------------------------------
00:00.0 Host bridge: VIA Technologies, Inc. VT8367 [KT266]
Subsystem: Asustek Computer, Inc.: Unknown device 807f
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 0
Region 0: Memory at e0000000 (32-bit, prefetchable) [size=128M]
Capabilities: [a0] AGP version 2.0
Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2
Command: RQ=0 SBA- AGP+ 64bit- FW- Rate=<none>
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:01.0 PCI bridge: VIA Technologies, Inc. VT8367 [KT266 AGP] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000e000-0000dfff
Memory behind bridge: da000000-db6fffff
Prefetchable memory behind bridge: db700000-dfffffff
BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.0 FireWire (IEEE 1394): Texas Instruments: Unknown device 8023 (prog-if 10 [OHCI])
Subsystem: Asustek Computer, Inc.: Unknown device 808d
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 35 (500ns min, 1000ns max), cache line size 08
Interrupt: pin A routed to IRQ 5
Region 0: Memory at d9800000 (32-bit, non-prefetchable) [disabled] [size=2K]
Region 1: Memory at d9000000 (32-bit, non-prefetchable) [disabled] [size=16K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:09.0 USB Controller: VIA Technologies, Inc. UHCI USB (rev 50) (prog-if 00 [UHCI])
Subsystem: Asustek Computer, Inc.: Unknown device 8080
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 08
Interrupt: pin A routed to IRQ 10
Region 4: I/O ports at d800 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:09.1 USB Controller: VIA Technologies, Inc. UHCI USB (rev 50) (prog-if 00 [UHCI])
Subsystem: Asustek Computer, Inc.: Unknown device 8080
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 08
Interrupt: pin B routed to IRQ 11
Region 4: I/O ports at d400 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:09.2 USB Controller: VIA Technologies, Inc.: Unknown device 3104 (rev 51) (prog-if 20)
Subsystem: Asustek Computer, Inc.: Unknown device 8080
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 08
Interrupt: pin C routed to IRQ 5
Region 0: Memory at d8800000 (32-bit, non-prefetchable) [disabled] [siCapabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0e.0 Communication controller: Rockwell International HCF 56k Data/Fax/Voice/Spkp (w/Handset) Modem (rev 01)
Subsystem: Rockwell International HCF 56k Data/Fax/Voice/Spkp (w/Handset) Modem
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Interrupt: pin A routed to IRQ 5
Region 0: Memory at d8000000 (32-bit, non-prefetchable) [size=64K]
Region 1: I/O ports at d000 [size=8]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME+
00:0f.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)ze=256]
Subsystem: Creative Labs: Unknown device 8064
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (500ns min, 5000ns max)
Interrupt: pin A routed to IRQ 5
Region 0: I/O ports at b800 [size=32]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0f.1 Input device controller: Creative Labs SB Live! (rev 07)
Subsystem: Creative Labs Gameport Joystick
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Region 0: I/O ports at b400 [disabled] [size=8]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot
-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:11.0 ISA bridge: VIA Technologies, Inc.: Unknown device 3147
Subsystem: Asustek Computer, Inc.: Unknown device 808c
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:11.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
Subsystem: Asustek Computer, Inc.: Unknown device 808c
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Interrupt: pin A routed to IRQ 0
Region 4: I/O ports at b000 [size=16]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:11.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 23) (prog-if 00 [UHCI])
Subsystem: Asustek Computer, Inc.: Unknown device 808c
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 08
Interrupt: pin D routed to IRQ 9
Region 4: I/O ports at a800 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:11.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 23) (prog-if 00 [UH
CI])
Subsystem: Asustek Computer, Inc.: Unknown device 808c
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 08
Interrupt: pin D routed to IRQ 9
Region 4: I/O ports at a400 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 0172 (rev
a3) (prog-if 00 [VGA])
Subsystem: Asustek Computer, Inc.: Unknown device 805b
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 248 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at da000000 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at dc000000 (32-bit, prefetchable) [size=64M]
Region 2: Memory at db800000 (32-bit, prefetchable) [size=512K]
Expansion ROM at db7e0000 [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 2.0
Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x2
Command: RQ=31 SBA- AGP+ 64bit- FW- Rate=<none>
------------------ end 'lspci -vvv' --------------------------------------------
In addition, I'm running no SCSi device.
One additional information that may be useful:
1. This bug occured in 2.4.18 very often (almost always). It seems that
this problem arises less often in 2.4.20.
2. It seems that the problem does not show up when X is not running.
3. The problem occurs when I'm connected to the internet (then again,
this happens sporadically).
4. This may be due to NVidia driver because I often get:
"no MTRR found in e000... e000..." when X is killed (and NVidia driver
being loaded then).
Hope this can be fixed soon :-)
Thanks in advance,
Anthony
--
t.widjaja1@ugrad.unimelb.edu.au
^ permalink raw reply
* Re: [linux-lvm] Volume Group with 4 HDs- one crashed
From: Alasdair G Kergon @ 2003-01-10 8:12 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <3051931894.20030110143835@gmx.net>
On Fri, Jan 10, 2003 at 02:38:35PM +0100, nik-da-3'9'' wrote:
> > 2 logical volume(s) in volume group "mpeg" now active
So did that not activate 2 of the logical volumes?
You have to add '-P' to *every* tool that you want to attempt
to use volume groups that are Partially missing.
(But tools only support the flag where it makes sense to.)
> Found volume group "data" using metadata type lvm1
So it found that OK.
> I also remove the devnodes left by LVM 1 (/dev/mpeg/mp3 /dev/mpeg/mpvie),
> but still I cant access the VG's.
Recent LVM2 tarballs deal OK with any nodes left behind like that.
What version are you using?
> What to do next? Any help is really appreciated, as there is still lots of
> important data on the VGs.
Read the -P section of 'man lvm' for extra hints on recovery: depends
if you're able to replace the disk with another, or if you want to
remove the disk from the VG completely.
See also the thread a few days back:
Re: [linux-lvm] problem
Alasdair
--
agk@uk.sistina.com
^ permalink raw reply
* Re: NFS client stall within __lock_page()
From: miyoshi @ 2003-01-10 8:12 UTC (permalink / raw)
To: nfs; +Cc: tanaka-h
In-Reply-To: <20030110151929Z.miyoshi@hpc.bs1.fc.nec.co.jp>
Hi, all.
> I am using kernel 2.4.17 as an NFS client (server is HP-UX)
> and one of client processes hangs and never wakes up.
>
> From kdb backtrace (attached), I found that the client process
> stalls within nfs write and never returns (kill -9 is not accepted.)
> It sleeps on __lock_page.
I want to add one thing.
I saw the following message after the program started,
but I am not sure the accurate time and date of the stall.
In addition, it appears frequently (a few times in a day?) and
it seems to have no relation with the problem.
Dec 26 17:41:19 client kernel: nfs_notify_change: revalidate failed, error=-116
Regards,
--
MIYOSHI Kazuto <miyoshi@hpc.bs1.fc.nec.co.jp>
HPC Operating System Group, 1st Computers Software Division,
Computers Software Operations Unit, NEC Solutions.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: Beginner questions about soundmodem and others
From: Tomi Manninen OH2BNS @ 2003-01-10 8:11 UTC (permalink / raw)
To: James Washer; +Cc: linux-hams
In-Reply-To: <20030109175607.0c94ab8f.washer@trlp.com>
On Thu, 9 Jan 2003, James Washer wrote:
> 1)I'm confused by this whole AX.25 kernel thing... I had assumed that
> (most) TNCs handled the AX.25 protocol themselves. I understand that
> with a soundmodem, the linux system would have to do the AX.25, but
> what about if I use an off-the-shelf TNC ( kpc3 for example ). Does
> linux arrange to turn the AX.25 handling OFF in the TNC and do it in
> software?
Yes, typically the TNC is put to a so called KISS mode (6PACK is another
alternative). In KISS mode the TNC only handles modulation and
demodulation, HDLC en/decoding (bit stuffing and framing that is) and
AX.25 CRC checking. Everything else is left to the PC.
This is basically the only sane way to be able to support higher level
protocols on top of AX.25. Also it makes the simple text mode support much
more flexible.
> 2) Can I put more than one sound card in my linux box.. One for music,
> the other, perhaps multiple soundcards, for packet?
Yes.
--
Tomi Manninen Internet: oh2bns@sral.fi
OH2BNS AX.25: oh2bns@oh2rbi.fin.eu
KP20ME04 Amprnet: oh2bns@oh2rbi.ampr.org
^ permalink raw reply
* [PATCH] USB MIDI: fix endpoint detection
From: Clemens Ladisch @ 2003-01-10 8:08 UTC (permalink / raw)
To: alsa-devel
This patch removes the implicit assumption that devices with
QUIRK_MIDI_FIXED_ENDPOINT use the same endpoint number for input and
output pipes. (This broke with the Edirol PCR-30/50.)
Index: alsa-kernel/usb/usbaudio.h
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/usb/usbaudio.h,v
retrieving revision 1.11
diff -u -r1.11 usbaudio.h
--- alsa-kernel/usb/usbaudio.h 19 Dec 2002 12:15:23 -0000 1.11
+++ alsa-kernel/usb/usbaudio.h 10 Jan 2003 07:54:56 -0000
@@ -165,7 +165,7 @@
/* data for QUIRK_MIDI_FIXED_ENDPOINT */
struct snd_usb_midi_endpoint_info {
- int16_t epnum; /* ep number, -1 autodetect */
+ int8_t out_ep, in_ep; /* ep number, 0 autodetect */
uint16_t out_cables; /* bitmask */
uint16_t in_cables; /* bitmask */
};
Index: alsa-kernel/usb/usbaudio.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/usb/usbaudio.c,v
retrieving revision 1.33
diff -u -r1.33 usbaudio.c
--- alsa-kernel/usb/usbaudio.c 7 Jan 2003 10:36:32 -0000 1.33
+++ alsa-kernel/usb/usbaudio.c 10 Jan 2003 07:54:56 -0000
@@ -1953,7 +1953,6 @@
static int snd_usb_roland_ua100_hack(snd_usb_audio_t *chip)
{
static const snd_usb_midi_endpoint_info_t ep_quirk = {
- .epnum = -1,
.out_cables = 0x0007,
.in_cables = 0x0007
};
Index: alsa-kernel/usb/usbquirks.h
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/usb/usbquirks.h,v
retrieving revision 1.10
diff -u -r1.10 usbquirks.h
--- alsa-kernel/usb/usbquirks.h 5 Dec 2002 19:54:44 -0000 1.10
+++ alsa-kernel/usb/usbquirks.h 10 Jan 2003 07:54:57 -0000
@@ -245,7 +245,6 @@
.ifnum = 2,
.type = QUIRK_MIDI_FIXED_ENDPOINT,
.data = & (const snd_usb_midi_endpoint_info_t) {
- .epnum = -1,
.out_cables = 0x000f,
.in_cables = 0x000f
}
@@ -259,7 +258,6 @@
.ifnum = 2,
.type = QUIRK_MIDI_FIXED_ENDPOINT,
.data = & (const snd_usb_midi_endpoint_info_t) {
- .epnum = -1,
.out_cables = 0x003f,
.in_cables = 0x003f
}
@@ -273,7 +271,6 @@
.ifnum = 2,
.type = QUIRK_MIDI_FIXED_ENDPOINT,
.data = & (const snd_usb_midi_endpoint_info_t) {
- .epnum = -1,
.out_cables = 0x0003,
.in_cables = 0x0003
}
@@ -287,7 +284,6 @@
.ifnum = 2,
.type = QUIRK_MIDI_FIXED_ENDPOINT,
.data = & (const snd_usb_midi_endpoint_info_t) {
- .epnum = -1,
.out_cables = 0x0003,
.in_cables = 0x0003
}
@@ -301,7 +297,6 @@
.ifnum = 2,
.type = QUIRK_MIDI_FIXED_ENDPOINT,
.data = & (const snd_usb_midi_endpoint_info_t) {
- .epnum = -1,
.out_cables = 0x0013,
.in_cables = 0x0013
}
@@ -315,7 +310,6 @@
.ifnum = 2,
.type = QUIRK_MIDI_FIXED_ENDPOINT,
.data = & (const snd_usb_midi_endpoint_info_t) {
- .epnum = -1,
.out_cables = 0x0001,
.in_cables = 0x0001
}
@@ -329,7 +323,6 @@
.ifnum = 2,
.type = QUIRK_MIDI_FIXED_ENDPOINT,
.data = & (const snd_usb_midi_endpoint_info_t) {
- .epnum = -1,
.out_cables = 0x0001,
.in_cables = 0x0001
}
@@ -343,7 +336,6 @@
.ifnum = 2,
.type = QUIRK_MIDI_FIXED_ENDPOINT,
.data = & (const snd_usb_midi_endpoint_info_t) {
- .epnum = -1,
.out_cables = 0x0013,
.in_cables = 0x0013
}
@@ -357,7 +349,6 @@
.ifnum = 2,
.type = QUIRK_MIDI_FIXED_ENDPOINT,
.data = & (const snd_usb_midi_endpoint_info_t) {
- .epnum = -1,
.out_cables = 0x0007,
.in_cables = 0x0007
}
@@ -371,7 +362,6 @@
.ifnum = 0,
.type = QUIRK_MIDI_FIXED_ENDPOINT,
.data = & (const snd_usb_midi_endpoint_info_t) {
- .epnum = -1,
.out_cables = 0x0001,
.in_cables = 0x0001
}
@@ -385,7 +375,6 @@
.ifnum = 0,
.type = QUIRK_MIDI_FIXED_ENDPOINT,
.data = & (const snd_usb_midi_endpoint_info_t) {
- .epnum = -1,
.out_cables = 0x01ff,
.in_cables = 0x01ff
}
@@ -399,7 +388,6 @@
.ifnum = 2,
.type = QUIRK_MIDI_FIXED_ENDPOINT,
.data = & (const snd_usb_midi_endpoint_info_t) {
- .epnum = -1,
.out_cables = 0x000f,
.in_cables = 0x000f
}
@@ -413,7 +401,6 @@
.ifnum = 0,
.type = QUIRK_MIDI_FIXED_ENDPOINT,
.data = & (const snd_usb_midi_endpoint_info_t) {
- .epnum = -1,
.out_cables = 0x003f,
.in_cables = 0x003f
}
@@ -427,7 +414,6 @@
.ifnum = 3,
.type = QUIRK_MIDI_FIXED_ENDPOINT,
.data = & (const snd_usb_midi_endpoint_info_t) {
- .epnum = -1,
.out_cables = 0x0001,
.in_cables = 0x0001
}
@@ -441,7 +427,6 @@
.ifnum = 0,
.type = QUIRK_MIDI_FIXED_ENDPOINT,
.data = & (const snd_usb_midi_endpoint_info_t) {
- .epnum = -1,
.out_cables = 0x0003,
.in_cables = 0x0007
}
@@ -455,7 +440,6 @@
.ifnum = 0,
.type = QUIRK_MIDI_FIXED_ENDPOINT,
.data = & (const snd_usb_midi_endpoint_info_t) {
- .epnum = -1,
.out_cables = 0x000f,
.in_cables = 0x000f
}
@@ -469,7 +453,6 @@
.ifnum = 3,
.type = QUIRK_MIDI_FIXED_ENDPOINT,
.data = & (const snd_usb_midi_endpoint_info_t) {
- .epnum = -1,
.out_cables = 0x0003,
.in_cables = 0x0003
}
@@ -483,7 +466,6 @@
.ifnum = 0,
.type = QUIRK_MIDI_FIXED_ENDPOINT,
.data = & (const snd_usb_midi_endpoint_info_t) {
- .epnum = -1,
.out_cables = 0x0003,
.in_cables = 0x0007
}
Index: alsa-kernel/usb/usbmidi.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/usb/usbmidi.c,v
retrieving revision 1.16
diff -u -r1.16 usbmidi.c
--- alsa-kernel/usb/usbmidi.c 19 Dec 2002 12:15:23 -0000 1.16
+++ alsa-kernel/usb/usbmidi.c 10 Jan 2003 07:54:57 -0000
@@ -579,9 +579,9 @@
return -ENOMEM;
}
if (int_epd)
- pipe = usb_rcvintpipe(umidi->chip->dev, ep_info->epnum);
+ pipe = usb_rcvintpipe(umidi->chip->dev, ep_info->in_ep);
else
- pipe = usb_rcvbulkpipe(umidi->chip->dev, ep_info->epnum);
+ pipe = usb_rcvbulkpipe(umidi->chip->dev, ep_info->in_ep);
length = usb_maxpacket(umidi->chip->dev, pipe, 0);
buffer = kmalloc(length, GFP_KERNEL);
if (!buffer) {
@@ -652,7 +652,7 @@
snd_usbmidi_out_endpoint_delete(ep);
return -ENOMEM;
}
- pipe = usb_sndbulkpipe(umidi->chip->dev, ep_info->epnum);
+ pipe = usb_sndbulkpipe(umidi->chip->dev, ep_info->out_ep);
ep->max_transfer = usb_maxpacket(umidi->chip->dev, pipe, 1) & ~3;
buffer = kmalloc(ep->max_transfer, GFP_KERNEL);
if (!buffer) {
@@ -737,8 +737,6 @@
int out_ports = 0, in_ports = 0;
for (i = 0; i < MIDI_MAX_ENDPOINTS; ++i) {
- if (!endpoints[i].epnum)
- continue;
if (endpoints[i].out_cables) {
err = snd_usbmidi_out_endpoint_create(umidi, &endpoints[i],
&umidi->endpoints[i]);
@@ -812,50 +810,64 @@
ms_ep->bDescriptorType != USB_DT_CS_ENDPOINT ||
ms_ep->bDescriptorSubtype != MS_GENERAL)
continue;
- if (endpoints[epidx].epnum != 0 &&
- endpoints[epidx].epnum != (ep->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK)) {
- ++epidx;
- if (epidx >= MIDI_MAX_ENDPOINTS) {
- printk(KERN_WARNING "snd-usb-midi: too many endpoints\n");
- break;
+ if ((ep->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK) == USB_DIR_OUT) {
+ if (endpoints[epidx].out_ep) {
+ if (++epidx >= MIDI_MAX_ENDPOINTS) {
+ printk(KERN_WARNING "snd-usb-midi: too many endpoints\n");
+ break;
+ }
}
- }
- endpoints[epidx].epnum = ep->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK;
- if (ep->bEndpointAddress & USB_DIR_IN) {
- endpoints[epidx].in_cables = (1 << ms_ep->bNumEmbMIDIJack) - 1;
- } else {
+ endpoints[epidx].out_ep = ep->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK;
endpoints[epidx].out_cables = (1 << ms_ep->bNumEmbMIDIJack) - 1;
+ printk(KERN_INFO "snd-usb-midi: EP %02X: %d jack(s)\n",
+ ep->bEndpointAddress, ms_ep->bNumEmbMIDIJack);
+ } else {
+ if (endpoints[epidx].in_ep) {
+ if (++epidx >= MIDI_MAX_ENDPOINTS) {
+ printk(KERN_WARNING "snd-usb-midi: too many endpoints\n");
+ break;
+ }
+ }
+ endpoints[epidx].in_ep = ep->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK;
+ endpoints[epidx].in_cables = (1 << ms_ep->bNumEmbMIDIJack) - 1;
+ printk(KERN_INFO "snd-usb-midi: EP %02X: %d jack(s)\n",
+ ep->bEndpointAddress, ms_ep->bNumEmbMIDIJack);
}
- printk(KERN_INFO "snd-usb-midi: detected %d %s jack(s) on endpoint %d\n",
- ms_ep->bNumEmbMIDIJack,
- ep->bEndpointAddress & USB_DIR_IN ? "input" : "output",
- endpoints[epidx].epnum);
}
return 0;
}
/*
- * If the first endpoint isn't specified, use the first endpoint in the
+ * If the endpoints aren't specified, use the first bulk endpoints in the
* first alternate setting of the interface.
*/
static int snd_usbmidi_detect_endpoint(snd_usb_midi_t* umidi,
- snd_usb_midi_endpoint_info_t* endpoint)
+ snd_usb_midi_endpoint_info_t* endpoint)
{
struct usb_interface* intf;
struct usb_host_interface *hostif;
struct usb_interface_descriptor* intfd;
struct usb_endpoint_descriptor* epd;
+ int i;
- if (endpoint->epnum == -1) {
- intf = umidi->iface;
- if (!intf || intf->num_altsetting < 1)
- return -ENOENT;
- hostif = intf->altsetting;
- intfd = get_iface_desc(hostif);
- if (intfd->bNumEndpoints < 1)
- return -ENOENT;
- epd = get_endpoint(hostif, 0);
- endpoint->epnum = epd->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK;
+ intf = umidi->iface;
+ if (!intf || intf->num_altsetting < 1)
+ return -ENOENT;
+ hostif = intf->altsetting;
+ intfd = get_iface_desc(hostif);
+ if (intfd->bNumEndpoints < 1)
+ return -ENOENT;
+
+ for (i = 0; i < intfd->bNumEndpoints; ++i) {
+ epd = get_endpoint(hostif, i);
+ if ((epd->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) != USB_ENDPOINT_XFER_BULK)
+ continue;
+ if (!endpoint->out_ep && endpoint->out_cables &&
+ (epd->bEndpointAddress & USB_ENDPOINT_DIR_MASK) == USB_DIR_OUT)
+ endpoint->out_ep = epd->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK;
+ if (!endpoint->in_ep && endpoint->in_cables &&
+ (epd->bEndpointAddress & USB_ENDPOINT_DIR_MASK) == USB_DIR_IN)
+ endpoint->in_ep = epd->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK;
}
return 0;
}
@@ -892,7 +904,6 @@
if (!endpoint->in_cables && !endpoint->out_cables)
return -ENOENT;
- endpoint->epnum = -1;
return snd_usbmidi_detect_endpoint(umidi, endpoint);
}
@@ -940,13 +951,13 @@
}
}
- ep_info.epnum = get_endpoint(hostif, 2)->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK;
+ ep_info.out_ep = get_endpoint(hostif, 2)->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK;
ep_info.out_cables = endpoint->out_cables & 0x5555;
err = snd_usbmidi_out_endpoint_create(umidi, &ep_info, &umidi->endpoints[0]);
if (err < 0)
return err;
- ep_info.epnum = get_endpoint(hostif, 0)->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK;
+ ep_info.in_ep = get_endpoint(hostif, 0)->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK;
ep_info.in_cables = endpoint->in_cables;
err = snd_usbmidi_in_endpoint_create(umidi, &ep_info, &umidi->endpoints[0]);
if (err < 0)
@@ -954,7 +965,7 @@
umidi->endpoints[0].in->urb->complete = snd_usb_complete_callback(snd_usbmidi_in_midiman_complete);
if (endpoint->out_cables > 0x0001) {
- ep_info.epnum = get_endpoint(hostif, 4)->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK;
+ ep_info.out_ep = get_endpoint(hostif, 4)->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK;
ep_info.out_cables = endpoint->out_cables & 0xaaaa;
err = snd_usbmidi_out_endpoint_create(umidi, &ep_info, &umidi->endpoints[1]);
if (err < 0)
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* RE: detecting hyperthreading in linux 2.4.19
From: Pallipadi, Venkatesh @ 2003-01-10 8:16 UTC (permalink / raw)
To: Mikael Pettersson, jamesclv; +Cc: Jason Lunz, linux-kernel
> -----Original Message-----
> From: Mikael Pettersson [mailto:mikpe@csd.uu.se]
>
> My performance monitoring counters driver uses this approach
> in kernel-space
> using smp_call_function(). I don't use the siblings tables
> because they suck :-)
> [I don't think they distinguish between logical CPUs #0 and
> #1, and they aren't
> exported to modules. The CPUID check is simple and portable
> across kernel versions.]
I believe it is better to use a OS interface to find out HT, rather than
using CPUID. The reason being, it is possible to have HT disabled, in OS,
even after processor and the BIOS supports it.
1) Consider the case when processor and BIOS supports HT, but linux
was booted with "noht" boot option (now I am not sure whether that option is
there in 2.4.19. But is is certainly there in some other kernels).
2) What about some other kernel which is totally ignorant about HT, and
doesn't initialize logical processor (kernel which looks at MPS in place
of ACPI)
I think, in both these cases cpuid can still say HT is present.
I know that sibling table is not exported. But I couldn't get your other
comment about sibling table "they distinguish between logical CPUs #0 and #1:"
Can you elaborate..
Thanks,
-Venkatesh
^ permalink raw reply
* Re: [2.5.54][PATCH] SB16 convertation to new PnP layer.
From: Ruslan U. Zakirov @ 2003-01-10 8:17 UTC (permalink / raw)
To: Shawn Starr; +Cc: linux-kernel
In-Reply-To: <200301092356.14182.spstarr@sh0n.net>
SS> Is this for ALSA or OSS? Right now I have this card on my P233MMX an AWE32
SS> EMU8000 w/ 2MB installed.
SS> It's using OSS under 2.4 right now and I'd like to try this. Does it work for
SS> OSS? I don't want to build the ALSA userland tools right now ;-)
SS> Shawn.
SS> -
SS> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
SS> the body of a message to majordomo@vger.kernel.org
SS> More majordomo info at http://vger.kernel.org/majordomo-info.html
SS> Please read the FAQ at http://www.tux.org/lkml/
It's only for 2.5.5x and ALSA.
And it does not bring any advantages and features in driver.
Ruslan.
^ 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.