* Re: detecting hyperthreading in linux 2.4.19
From: Mikael Pettersson @ 2003-01-10 7:05 UTC (permalink / raw)
To: jamesclv; +Cc: Jason Lunz, linux-kernel
In-Reply-To: <200301091337.04957.jamesclv@us.ibm.com>
James Cleverdon writes:
> On Thursday 09 January 2003 12:02 pm, Jason Lunz wrote:
> > Is there a way for a userspace program running on linux 2.4.19 to tell
> > the difference between a single hyperthreaded xeon P4 with HT enabled
> > and a dual hyperthreaded xeon P4 with HT disabled? The /proc/cpuinfos
> > for the two cases are indistinguishable.
> >
> > Jason
> >
> > -
>
> In the kernel that's no problem:
>
> A) If the BIOS writers followed Intel's guidelines, just look at the physical
> APIC IDs. HT siblings have odd IDs, the real ones have even.
>
> B) Check the siblings table built up at boot time and used by the scheduler.
>
> I don't know of any way to do this in userland. The whole point is that the
> sibling processors are supposed to look like real ones.
If the kernel has sched_setaffinity() or some other way of binding a process
to a given CPU (as numbered by the kernel, which may or may not be related
to any physical CPU numbers), then this will do it: execute CPUID on each
CPU and check the initial APIC ID field. If you find one that's non-zero,
then HT is enabled.
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.]
^ permalink raw reply
* Re: gcc version conflict
From: pa3gcu @ 2003-01-10 7:00 UTC (permalink / raw)
To: Jonathan Kallay, linux-newbie
In-Reply-To: <00f901c2b858$a725cb60$6400a8c0@00arc>
On Friday 10 January 2003 03:30, Jonathan Kallay wrote:
> Hi all,
> I'm trying to compile the kernel module for some NVidia drivers. I'm
> getting an error message saying that I'm compiling a module with a
> different version of the compiler than the one used to compile the kernel
> (gcc 2.95.4 is what's installed; the kernel version is 2.2.20 and at one
> point I was able to check the compiler version that compiled it but I can't
> remember how I did it). What's the best way to work around this problem?
This is a FAQ and is in the README you received with the driver/source.
Here is an excrpt;
Q: Compiling the NVdriver kernel module gives this error:
You appear to be compiling the NVdriver kernel module with
a compiler different from the one that was used to compile
the running kernel. This may be perfectly fine, but there
are cases where this can lead to unexpected behaviour and
system crashes.
If you know what you are doing and want to override this
check, you can do so by setting IGNORE_CC_MISMATCH.
In any other case, set the CC environment variable to the
name of the compiler that was used to compile the kernel.
A: You should compile the NVdriver kernel module with the same compiler
version that was used to compile your kernel. Some Linux kernel data
structures are dependent on the version of gcc used to compile it;
for example, in include/linux/spinlock.h:
...
* Most gcc versions have a nasty bug with empty initializers.
*/
#if (__GNUC__ > 2)
typedef struct { } rwlock_t;
#define RW_LOCK_UNLOCKED (rwlock_t) { }
#else
typedef struct { int gcc_is_buggy; } rwlock_t;
#define RW_LOCK_UNLOCKED (rwlock_t) { 0 }
#endif
If the kernel is compiled with gcc 2.x, but gcc 3.x is used when the
open files in NVdriver are built (or vice versa), the size of rwlock_t
will vary, and things like ioremap will fail.
To check what version of gcc was used to compile your kernel, you
can examine the output of:
cat /proc/version
To check what version of gcc is currently in your $PATH, you can
examine the output of:
gcc -v
--
Regards Richard
pa3gcu@zeelandnet.nl
http://people.zeelandnet.nl/pa3gcu/
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* RE: killing a stuborn process
From: Andrew B. Cramer @ 2003-01-10 7:05 UTC (permalink / raw)
To: linux-admin, thomas.steinbrecher
In-Reply-To: <C65F89D1AC0BB54B865127151A24DA780E4902FD@nbexchm2.aliant.icn>
Thomas,
If you think it may be a hardware problem, compile the kernel
without SMP support, and remove the second processor. After a
restart, check /proc/cpuinfo to see that one processor is shown.
Test. If it still fails or not, swap the processors. Test again. That
will eliminate the CPU's as an issue. DO NOT use your working system
for parts! Just check configuration files and module versions.
Best - Andrew
> From: Thomas Steinbrecher [mailto:thomas.steinbrecher@physchem.uni-freiburg.de]
> Sent: Tuesday, January 07, 2003 3:34 PM
> To: linux-admin@vger.kernel.org
> Subject: killing a stuborn process
>
>
> Greetings,
>
> please excuse if this is a newbie question, I'm no computer expert.
>
> I have several dual ATHLON PC's with Suse 8.0 in a Beowulf cluster on which I run molecular dynamics calculations.
>
> On one of my machines the calculations stop sometimes
> without apparent reason and I can't end the processes
> anymore (kill -9 has no effect). The processes are shown as running by ps, but they produce no cpu load with top.
>
> Is there another way to kill such a process?
>
> I suppose one of the CPUs might be damaged, but how do I
> test if that is true and what causes the processes to
> hangup?
> (The same calculation runs fine on another PC with
> identical software and hardware setup)
>
> Regards,
>
> Thomas
^ permalink raw reply
* 2.5.55-mjb1 (scalability / NUMA patchset)
From: Martin J. Bligh @ 2003-01-10 7:21 UTC (permalink / raw)
To: linux-kernel; +Cc: lse-tech
In-Reply-To: <676880000.1042101078@titus>
The patchset contains mainly scalability and NUMA stuff, and anything
else that stops things from irritating me. It's meant to be pretty stable,
not so much a testing ground for new stuff.
I'd be very interested in feedback from anyone willing to test on any
platform, however large or small.
http://www.aracnet.com/~fletch/linux/2.5.55/patch-2.5.55-mjb1.bz2
Since 2.5.54-mjb3
merged with Linus:
- kallsyms Andi Kleen / Daniel Ritz
- apicid_to_node Martin Bligh
- i386_topo Matt Dobson
- do_boot_error James Cleverdon
- more_numaq1 James Cleverdon / Martin Bligh
- cleanup_cpu_apicid Martin J. Bligh
- smpboot_cam Martin J. Bligh
- nuke_clustered_apic Martin J. Bligh
- fix_starfire_warning Martin J. Bligh
Other:
~ summit2 James Cleverdon / John Stultz
- shpte Dave McCracken
(dropped temporarily until Dave merges up with 2.5.55)
~ interrupt_stacks Dave Hansen / Ben LaHaise
~ stack_usage_check Dave Hansen / Ben LaHaise
+ ksymsoff Hugh Dickins
Pending:
Speed up page init on boot (Bill Irwin)
Notsc automatic enablement
scheduler callers profiling (Anton)
PPC64 NUMA patches (Anton)
Scheduler tunables (rml)
Lockless xtime structures (Andi)
P4 oprofile support (movement)
summit1 James Cleverdon / John Stultz
Summit support part 1
summit2 James Cleverdon / John Stultz
Summit support part 2
summit3 James Cleverdon / John Stultz
Summit support part 3
summit4 James Cleverdon / John Stultz
Summit support part 4
dcache_rcu Dipankar / Maneesh
Use RCU type locking for the dentry cache.
early_printk Dave Hansen et al.
Allow printk before console_init
confighz Andrew Morton / Dave Hansen
Make HZ a config option of 100 Hz or 1000 Hz
config_page_offset Dave Hansen / Andrea
Make PAGE_OFFSET a config option
vmalloc_stats Dave Hansen
Expose useful vmalloc statistics
numasched1 Erich Focht
Numa scheduler general foundation work + pooling
numasched2 Michael Hohnbaum
Numa scheduler lightweight initial load balancing.
local_pgdat Bill Irwin
Move the pgdat structure into the remapped space with lmem_map
thread_info_cleanup (4K stacks pt 1) Dave Hansen / Ben LaHaise
Prep work to reduce kernel stacks to 4K
interrupt_stacks (4K stacks pt 2) Dave Hansen / Ben LaHaise
Create a per-cpu interrupt stack.
stack_usage_check (4K stacks pt 3) Dave Hansen / Ben LaHaise
Check for kernel stack overflows.
4k_stack (4K stacks pt 4) Dave Hansen
Config option to reduce kernel stacks to 4K
notsc Martin Bligh
Enable notsc option for NUMA-Q (new version for new config system)
numameminfo Martin Bligh / Keith Mannthey
Expose NUMA meminfo information under /proc/meminfo.numa
kgdb Andrew Morton / Various People
The older version of kgdb, synched with 2.5.54-mm1
noframeptr Martin Bligh
Disable -fomit_frame_pointer
ksymoff Hugh Dickins
Fix off by one error in kksymoops
-mjb Martin Bligh
Add a tag to the makefile
^ permalink raw reply
* Re: aal_assert()
From: Yury Umanets @ 2003-01-10 7:22 UTC (permalink / raw)
To: Andrew Clausen; +Cc: reiserfs-list
In-Reply-To: <20021231005440.GA1573@gnu.org>
Andrew Clausen wrote:
>Hi all,
>
>In reiser4progs, aal_assert() has an argument for an assertian
>identifier, so calls look like this:
>
> aal_assert("umka-889", name != NULL, return NULL);
>
>(Where umka == Yura Umanets :)
>
>Isn't file + line number + version number sufficient to identify
>the spot in the code? If all of these are printed out in error
>messages, then users' bug reports should give sufficient information
>to trace the problem.
>
>So, I think debug.[ch] should be changed like this:
>
>--- debug.h~ 2002-12-29 08:18:42.000000000 +1100
>+++ debug.h 2002-12-29 08:17:38.000000000 +1100
>@@ -20,9 +20,9 @@
> */
> #ifdef __GNUC__
>
>-#define aal_assert(hint, cond, action) \
>+#define aal_assert(cond, action) \
> do { \
>- if (!__assert(hint, cond, \
>+ if (!__assert(cond, \
> #cond, \
> __FILE__, \
> __LINE__, \
>@@ -30,13 +30,13 @@
> { \
> action; \
> } \
>- } while (0);
>+ } while (0)
>
> #else
>
>-#define aal_assert(hint, cond, action) \
>+#define aal_assert(cond, action) \
> do { \
>- if (!__assert(hint, cond, \
>+ if (!__assert(cond, \
> #cond, \
> "unknown", \
> 0, \
>@@ -44,17 +44,17 @@
> { \
> action; \
> } \
>- } while (0);
>+ } while (0)
>
> #endif
>
> #else
>
>-#define aal_assert(hint, cond, action) while (0) {}
>+#define aal_assert(cond, action) while (0) {}
>
> #endif
>
>-extern int __assert(char *hint, int cond, char *text, char *file,
>+extern int __assert(int cond, char *text, char *file,
> int line, char *function);
>
> #endif
>
>--- debug.c~ 2002-12-29 08:15:27.000000000 +1100
>+++ debug.c 2002-12-29 08:16:41.000000000 +1100
>@@ -18,7 +18,6 @@
> aal_assert().
> */
> int __assert(
>- char *hint, /* person owner of assert */
> int cond, /* condition of assertion */
> char *text, /* text of the assertion */
> char *file, /* source file assertion was failed in */
>@@ -34,8 +33,8 @@
> file, line and function assertion was failed in.
> */
> return (aal_exception_throw(EXCEPTION_BUG, EXCEPTION_IGNORE | EXCEPTION_CANCEL,
>- "%s: Assertion (%s) at %s:%d in function %s() failed.",
>- hint, text, file, line, function) == EXCEPTION_IGNORE);
>+ "Assertion (%s) at %s:%d of version %s in function %s() failed.",
>+ text, file, line, VERSION, function) == EXCEPTION_IGNORE);
> }
>
> #endif
>
>Cheers,
>Andrew
>
>
>
>
Actually there was the code earlier like you have proposed. And it was
changed to the current state due to the following reasons:
* there are two developers working on reiser4progs currentry (Vitaly
Fertman and Yury Umanets). And our parts is much different. So, each of
us should work on own code.
* there is not neccessary an assertion is corect and only the author can
decide is it correct.
* NAMESYS has some development policies. And hints is the one of them.
--
Yury Umanets
^ permalink raw reply
* Re: Userspace Test Framework for module loader porting
From: Rusty Russell @ 2003-01-08 11:44 UTC (permalink / raw)
To: davidm
Cc: Mike Stephens, linux-kernel, bjornw, geert, ralf, mkp, willy,
anton, gniibe, kkojima, Jeff Dike
In-Reply-To: <15898.8498.519625.200668@napali.hpl.hp.com>
In message <15898.8498.519625.200668@napali.hpl.hp.com> you write:
> >>>>> On Mon, 6 Jan 2003 14:41:04 -0800, Richard Henderson <rth@twiddle.net>
said:
>
> Rich> On Mon, Jan 06, 2003 at 11:38:20AM -0800, David Mosberger
> Rich> wrote:
>
> >> What about all the problems that Richard Henderson pointed out
> >> with the original in-kernel module loader? Were those solved?
>
> Rich> Yes.
>
> OK, that's good.
>
> Rusty, have you maintained the ia64 support of your in-kernel loader?
No, but I can update it next week when I'm back in the office. Should
be trivial to do; I'll pass it by Mike Stephens if he's willing,
though, since he wrote the original code I cribbed off.
> I'd rather prefer the old (user-level loader)
Really? Because it already exists (and is maintained by someone else)
or for some other reason?
> or the new shared-object loader.
I thought about letting archs choose which one they wanted to use, but
it would really mess up the core code. Of course, the transition
won't break userspace (kind of the whole point of the in-kernel module
loader).
Cheers!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply
* Re: Another idea for simplifying locking in kernel/module.c
From: Rusty Russell @ 2003-01-08 11:46 UTC (permalink / raw)
To: Adam J. Richter; +Cc: linux-kernel
In-Reply-To: <200301070219.SAA12905@adam.yggdrasil.com>
In message <200301070219.SAA12905@adam.yggdrasil.com> you write:
> Here is a way to replace all of the specialized "stop CPU"
> locking code in kernel/module.c with an rw_semaphore by using
> down_read_trylock in try_module_get() and down_write when beginning to
> unload the module.
And now you can't modularize netfilter modules.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply
* Re: [2.5 patch] MODULE_FORCE_UNLOAD must depend on MODULE_UNLOAD
From: Rusty Russell @ 2003-01-08 12:05 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Robert P. J. Day, Linus Torvalds, Linux kernel mailing list
In-Reply-To: <20030107230742.GO6626@fs.tum.de>
In message <20030107230742.GO6626@fs.tum.de> you write:
> Thanks for spotting this, after reading kernel/module.c it seems obvious
> to me that you are right. The following simple patch fixes it:
Yep. Linus, please apply.
From: Adrian Bunk <bunk@fs.tum.de>
--- linux-2.5.54/init/Kconfig.old 2003-01-08 00:05:12.000000000 +0100
+++ linux-2.5.54/init/Kconfig 2003-01-08 00:05:38.000000000 +0100
@@ -127,7 +127,7 @@
config MODULE_FORCE_UNLOAD
bool "Forced module unloading"
- depends on MODULES && EXPERIMENTAL
+ depends on MODULE_UNLOAD && EXPERIMENTAL
help
This option allows you to force a module to unload, even if the
kernel believes it is unsafe: the kernel will remove the module
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply
* Re: [PATCH] Make `obsolete params' work correctly if MODULE_SYMBOL_PREFIX is non-empty
From: Rusty Russell @ 2003-01-08 11:56 UTC (permalink / raw)
To: Miles Bader; +Cc: linux-kernel, torvalds
In-Reply-To: <20030107063239.F1ED73745@mcspd15.ucom.lsi.nec.co.jp>
In message <20030107063239.F1ED73745@mcspd15.ucom.lsi.nec.co.jp> you write:
> Since these are just symbols in the module object, they need symbol name
> munging to find the symbol from the parameter name.
Good point. Linus, please apply.
> [I guess using the stack is bad in general, but parameter names should be
> very short, and hey if they're obsolete, it seems pointless to spend
> much effort.]
Should be fine here. I removed the spaces between the funcname and
the brackets tho.
Thanks!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Name: Make obsolete module parameters work with MODULE_SYMBOL_PREFIX
Author: Miles Bader
Status: Trivial
D: Since these are just symbols in the module object, they need symbol name
D: munging to find the symbol from the parameter name.
diff -ruN -X../cludes linux-2.5.54-moo.orig/kernel/module.c linux-2.5.54-moo/kernel/module.c
--- linux-2.5.54-moo.orig/kernel/module.c 2003-01-06 10:51:20.000000000 +0900
+++ linux-2.5.54-moo/kernel/module.c 2003-01-07 14:31:53.000000000 +0900
@@ -666,13 +666,18 @@
num, obsparm[i].name, obsparm[i].type);
for (i = 0; i < num; i++) {
+ char sym_name[strlen(obsparm[i].name) + 2];
+
+ strcpy(sym_name, MODULE_SYMBOL_PREFIX);
+ strcat(sym_name, obsparm[i].name);
+
kp[i].name = obsparm[i].name;
kp[i].perm = 000;
kp[i].set = set_obsolete;
kp[i].get = NULL;
obsparm[i].addr
= (void *)find_local_symbol(sechdrs, symindex, strtab,
- obsparm[i].name);
+ sym_name);
if (!obsparm[i].addr) {
printk("%s: falsely claims to have parameter %s\n",
name, obsparm[i].name);
^ permalink raw reply
* Re: [PATCH] Embed __this_module in module itself.
From: Rusty Russell @ 2003-01-08 11:51 UTC (permalink / raw)
To: Miles Bader; +Cc: linux-kernel, rth
In-Reply-To: <buoadid1pxl.fsf@mcspd15.ucom.lsi.nec.co.jp>
In message <buoadid1pxl.fsf@mcspd15.ucom.lsi.nec.co.jp> you write:
> Miles Bader <miles@lsi.nec.co.jp> writes:
> > When I try to build modules using 2.5.54, the resulting .ko files lack
> > the .gnu.linkonce.* sections, which causes the kernel module loader to
> > fail on them -- those sections _are_ present in the .o files, but the
> > linker apparently removes them!
>
> Ok, I found out why this is happening -- the v850 default linker
> scripts, for whatever reason, merge any section called `.gnu.linker.t*'
> with .text.
That's about as wierdass as it comes.
> I can prevent this by adding the option `--unique=.gnu.linkonce.this_module'
> to the linker flags (specifically, to LDFLAGS_MODULE in the top-level
> Makefile). I suppose another way to do it would be to rename the
> section something that doesn't match `.gnu.linker.t*'.
Or you could add this flag in arch/v850/Makefile.
> What's the right way to handle this?
>
> [from perusing the ld srcs, a few other archs seem to have the same
> `feature,' though the only that I think has linux support is `cris']
I think:
LDFLAGS_MODULE += -T arch/v850/module.lds
And include a linker script there which works.
Thanks for finding this...
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply
* Re: PATCH: module_text_address() defined but not used in module.h
From: Rusty Russell @ 2003-01-08 12:01 UTC (permalink / raw)
To: Muli Ben-Yehuda; +Cc: Linux-Kernel, torvalds
In-Reply-To: <20030107131243.GJ25540@alhambra>
In message <20030107131243.GJ25540@alhambra> you write:
> module_text_address() is defined as 'static int ...' if modules are
> not configured in in module.h, leading to a compiler warning that it
> is defined but not used. Make it static inline. Patch against
> 2.5.54-bk.
Linus, please apply. Obviously correct, my mistake.
From: Muli Ben-Yehuda <mulix@mulix.org>
diff -Nru a/include/linux/module.h b/include/linux/module.h
--- a/include/linux/module.h Tue Jan 7 14:18:37 2003
+++ b/include/linux/module.h Tue Jan 7 14:18:37 2003
@@ -328,7 +328,7 @@
}
/* Is this address in a module? */
-static int module_text_address(unsigned long addr)
+static inline int module_text_address(unsigned long addr)
{
return 0;
}
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply
* Re: Userspace Test Framework for module loader porting
From: Rusty Russell @ 2003-01-08 11:21 UTC (permalink / raw)
To: davidm
Cc: linux-kernel, rth, bjornw, geert, ralf, mkp, willy, anton, gniibe,
kkojima, Jeff Dike
In-Reply-To: <15897.56108.201340.229554@napali.hpl.hp.com>
In message <15897.56108.201340.229554@napali.hpl.hp.com> you write:
> >>>>> On Mon, 06 Jan 2003 13:27:02 +1100, Rusty Russell <rusty@rustcorp.com.a
u> said:
>
> Rusty> BTW, the change to use shared objects for modules is going to
> Rusty> be a 2.7 thing: after 10 architectures, MIPS toolchain issues
> Rusty> made it non-trivial. So the current stuff is what is going
> Rusty> to be there for 2.6, so no point waiting 8)
>
> What about all the problems that Richard Henderson pointed out with
> the original in-kernel module loader? Were those solved?
Yes. Richard withdrew the one about allocation (we used a special
per-arch allocator, he missed it), the one about common section
ordering was fixed by RTH noticing we use -fno-common, so all that
logic was dropped anyway, and his section ordering query was fixed by
his section ordering patch (which changed the arch interface
slightly).
> My gut feeling is that we really want shared objects for kernel
> modules on ia64 (and probably alpha?).
It's certainly simpler. My ia64 current implementation is around 500
lines, vs 225 lines for the shared version.
But I'm not prepared to shaft an arch over it this late in the cycle,
and the current scheme puts less pressure on toolchains (several other
binutils "issues" were discovered in implementing
modules-as-shared-objects).
Hope that clarifies,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply
* Re: [TRIVIAL] [PATCH 1 of 3] Fix errors making Docbook documentation
From: Rusty Russell @ 2003-01-10 0:50 UTC (permalink / raw)
To: Alan Cox; +Cc: Linus Torvalds, Linux Kernel Mailing List, Craig Wilkie
In-Reply-To: <1041866409.17472.25.camel@irongate.swansea.linux.org.uk>
In message <1041866409.17472.25.camel@irongate.swansea.linux.org.uk> you write:
> On Mon, 2003-01-06 at 03:47, Rusty Trivial Russell wrote:
> > From: Craig Wilkie <craig@homerjay.homelinux.org>
> > Documentation/Docbook/kernel-api.tmpl - Remove references to source
> > files which do not contain kernel-doc comments, which caused "errors" in
> > the generated documentation.
>
> Please don't do this. The proper fixes already exist just never got
> merged. Also documentation exists for those files and isnt merged. The
> docbook is not the problem, the pile of other missing bits is
>
> Grab the docbook for those files from 2.4 and also the changes to the
> docbook generator
Too late, Linus took it. Craig, since you're doing Documentation
patches, a forward port would be nice.
Thanks,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply
* Re: [parisc-linux] unaligned accesses
From: jsoe0708 @ 2003-01-10 7:29 UTC (permalink / raw)
To: Randolph Chung, parisc-linux
In-Reply-To: <20030109082902.GF23535@tausq.org>
>-- Original Message --
>From: Randolph Chung <randolph@tausq.org>
>To: parisc-linux@lists.parisc-linux.org
>Subject: Re: [parisc-linux] unaligned accesses
>Reply-To: Randolph Chung <randolph@tausq.org>
>Date: Thu, 9 Jan 2003 00:29:02 -0800
>
>
>> The other question. I am using emacs, and I regularly see these messag=
es:
>>
>> Jan 8 23:52:33 hp kernel: emacs(17795): unaligned access to 0x001cdaf=
2
>at ip=3D0x0008937f
>> Jan 8 23:52:33 hp kernel: emacs(17795): unaligned access to 0x001cdaf=
2
>at ip=3D0x0008930b
>>
>> What are they?
>
>Blame LaMont!
>(yes, I'm just kidding, I've just been waiting for my chance to say
>this... :-)
>
Do you think that this tcpdump pb is also related to Lamont job (to be ho=
nest
I do not remember what was it?):
...
Jan 9 09:59:58 fw01 kernel: tcpdump(4638): unaligned access to 0x0011e78=
a
at ip=3D0x0002ab83
Jan 9 09:59:34 fw01 kernel: tcpdump(4638): unaligned access to 0x0011e78=
e
at ip=3D0x0002ab83
...
>On a more serious note, on parisc load/stores to half-words, words,
>doublewords have specific address alignment requirements. the message
>usually means the program in question is buggy and is making unaligned
hmmm buggy: not always, the triky case is when you have to access to thos=
e
kind of data encapsulated into a structure. I do not yet find any workaro=
und
or how to fix this kind of pb. Any idea (gcc-3.3?)?
>accesses. The unaligned access is trapped and emulated by the kernel,
>so normally the message itself is simply informational.
>
>This is definitely a FAQ.... maybe we should add it to the list :)
>
Yes, works fine but this consume a lot of CPU resources.
Joel
********************************************
Promo Tiscali ADSL: 35 Euros/mois, 1er mois et activation =3D 0 Euro http=
://adsl.tiscali.be
^ permalink raw reply
* nForce IDE in 2.5?
From: Joshua M. Kwan @ 2003-01-10 7:35 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1.1: Type: text/plain, Size: 259 bytes --]
It's missing a PCI identifier variable for the chipset itself, and if I
knew what its value is supposed to be, or where to put it, I would make
a patch for it.. =\
Attached is the error log from the build. I am using 2.5.x-current...
Regards
Josh
[-- Attachment #1.2: nforce.fail.log --]
[-- Type: text/plain, Size: 2256 bytes --]
In file included from drivers/ide/pci/nvidia.c:29:
drivers/ide/pci/nvidia.h:35: `PCI_DEVICE_ID_NVIDIA_NFORCE_IDE' undeclared here (not in a function)
drivers/ide/pci/nvidia.h:35: initializer element is not constant
drivers/ide/pci/nvidia.h:35: (near initialization for `nvidia_chipsets[0].device')
drivers/ide/pci/nvidia.h:43: initializer element is not constant
drivers/ide/pci/nvidia.h:43: (near initialization for `nvidia_chipsets[0].enablebits[0]')
drivers/ide/pci/nvidia.h:43: initializer element is not constant
drivers/ide/pci/nvidia.h:43: (near initialization for `nvidia_chipsets[0].enablebits[1]')
drivers/ide/pci/nvidia.h:43: initializer element is not constant
drivers/ide/pci/nvidia.h:43: (near initialization for `nvidia_chipsets[0].enablebits')
drivers/ide/pci/nvidia.h:46: initializer element is not constant
drivers/ide/pci/nvidia.h:46: (near initialization for `nvidia_chipsets[0]')
drivers/ide/pci/nvidia.c: In function `nforce_ratemask':
drivers/ide/pci/nvidia.c:79: `PCI_DEVICE_ID_NVIDIA_NFORCE_IDE' undeclared (first use in this function)
drivers/ide/pci/nvidia.c:79: (Each undeclared identifier is reported only once
drivers/ide/pci/nvidia.c:79: for each function it appears in.)
drivers/ide/pci/nvidia.c: In function `ata66_nforce':
drivers/ide/pci/nvidia.c:288: `PCI_DEVICE_ID_NVIDIA_NFORCE_IDE' undeclared (first use in this function)
drivers/ide/pci/nvidia.c: In function `nforce_init_one':
drivers/ide/pci/nvidia.c:338: warning: `_MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:419)
drivers/ide/pci/nvidia.c: At top level:
drivers/ide/pci/nvidia.c:343: `PCI_DEVICE_ID_NVIDIA_NFORCE_IDE' undeclared here (not in a function)
drivers/ide/pci/nvidia.c:343: initializer element is not constant
drivers/ide/pci/nvidia.c:343: (near initialization for `nforce_pci_tbl[0].device')
drivers/ide/pci/nvidia.c:343: initializer element is not constant
drivers/ide/pci/nvidia.c:343: (near initialization for `nforce_pci_tbl[0]')
drivers/ide/pci/nvidia.c:344: initializer element is not constant
drivers/ide/pci/nvidia.c:344: (near initialization for `nforce_pci_tbl[1]')
make[3]: *** [drivers/ide/pci/nvidia.o] Error 1
make[2]: *** [drivers/ide/pci] Error 2
make[1]: *** [drivers/ide] Error 2
make: *** [drivers] Error 2
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Make `obsolete params' work correctly if MODULE_SYMBOL_PREFIX is non-empty
From: Miles Bader @ 2003-01-10 7:39 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-kernel, torvalds
In-Reply-To: <20030110073328.D41A52C310@lists.samba.org>
Rusty Russell <rusty@rustcorp.com.au> writes:
> I removed the spaces between the funcname and the brackets tho.
Curses, foiled again!
-Miles
--
`The suburb is an obsolete and contradictory form of human settlement'
^ permalink raw reply
* Re: [parisc-linux] unaligned accesses
From: Randolph Chung @ 2003-01-10 7:36 UTC (permalink / raw)
To: jsoe0708; +Cc: parisc-linux
In-Reply-To: <3E1AA8D500000856@ocpmta8.freegates.net>
> >Blame LaMont!
> >(yes, I'm just kidding, I've just been waiting for my chance to say
> >this... :-)
> >
> Do you think that this tcpdump pb is also related to Lamont job (to be honest
> I do not remember what was it?):
LaMont recently improved the unaligned handler to be more correct and
more robust... as well as handle more cases.
> ...
> Jan 9 09:59:58 fw01 kernel: tcpdump(4638): unaligned access to 0x0011e78a
> at ip=0x0002ab83
> Jan 9 09:59:34 fw01 kernel: tcpdump(4638): unaligned access to 0x0011e78e
> at ip=0x0002ab83
> ...
yes, tcpdump (and several other network tools) are known to generate a
lot of unaligned accesses.
> 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 workaround
> or how to fix this kind of pb. Any idea (gcc-3.3?)?
eh? what do you mean?
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
^ permalink raw reply
* [linux-lvm] Volume Group with 4 HDs- one crashed
From: nik-da-3'9'' @ 2003-01-10 7:38 UTC (permalink / raw)
To: linux-lvm
Hello ,
I'm having a hard time with LVM, in my PC I have setup a VG with 4
harddisks, and one of the HDs crashed. Well, I know I should have
backed up the data,
which I did, but the backup is far too old. You know how hard it is to backup
big big HDs/partitions w/o having bunches of backup media. Anyway, I have
consulted Heinz, who was so kind pointing to LVM2, with its help it should have
been possible to mount the VG partially. What I did was:
1. upgrade my kernel, so I could use the device-mapper, which is important
for LVM2
2. installed LVM2
3. tried "vgchange -P -ay", which gave me following output:
> -----
> 3 logical volume(s) in volume group "data" now active
> Finding volume group "mpeg"
> 3 PV(s) found for VG mpeg: expected 4
> Logical volume (mp3) contains an incomplete mapping table.
> 2 logical volume(s) in volume group "mpeg" already active
> 3 PV(s) found for VG mpeg: expected 4
> Logical volume (mp3) contains an incomplete mapping table.
> Found volume group "mpeg"
> 3 PV(s) found for VG mpeg: expected 4
> Logical volume (mp3) contains an incomplete mapping table.
> Found volume group "mpeg"
> 3 PV(s) found for VG mpeg: expected 4
> Logical volume (mp3) contains an incomplete mapping table.
> Found volume group "mpeg"
> 3 PV(s) found for VG mpeg: expected 4
> Logical volume (mp3) contains an incomplete mapping table.
> Found volume group "mpeg"
> Activated logical volumes in volume group "mpeg"
> 2 logical volume(s) in volume group "mpeg" now active
> ----
>
> vgdisplay :
> Finding volume group "mpeg"
> 3 PV(s) found for VG mpeg: expected 4
> Volume group "mpeg" doesn't exist
>
> ----
even vgscan did not help:
: # LVM2.1.95.12/tools/lvm vgscan -v
Wiping cache of LVM-capable devices
Wiping internal cache
Reading all physical volumes. This may take a while...
Finding all volume groups
Finding volume group "data"
Found volume group "data" using metadata type lvm1
Finding volume group "mpeg"
3 PV(s) found for VG mpeg: expected 4
Volume group "mpeg" not found
: # mount -a
mount: special device /dev/mpeg/mp3 does not exist
mount: special device /dev/mpeg/movie does not exist
VG "data" is a VG on different SCSI-HDs (which is backed up on a reg
basis... anyway this VG was never touched, as it didnt crash).
I also remove the devnodes left by LVM 1 (/dev/mpeg/mp3 /dev/mpeg/mpvie),
but still I cant access the VG's.
What to do next? Any help is really appreciated, as there is still lots of
important data on the VGs.
Thanks
--
Regards,
nik-da-3'9''
mailto:nik39.at.gmx.dot.net@check.this.mailadress.com
^ permalink raw reply
* Re: [parisc-linux] Printing problem with HP9000 712/80
From: Vilmos Soti @ 2003-01-10 7:39 UTC (permalink / raw)
To: parisc-linux
Hello,
Thanks all of you for the answers. Now at least I know that the unaligned
access message is normal and the harmony is full duplex.
About the printer.
This is a full-blown (not windows only) printer. I tried to connect
it to another Linux box, and I could print a pcl file by catting it to
/dev/lp0. I could also print a text file (/etc/passwd and an ^L at the
end) by sending it to /dev/lp0.
However, when I connect it to the HP9000 712/80 box, then nothing happens
even if I tried to cat the same pcl file to the printer port. I massaged
the connectors to make sure that there is no contact error. This is not
the case since the printer works perfectly on the two other boxes. On
the other hand, I do have an old Panasonic dot matrix printer, and if I
connect that printer to the box, and send a text file with an ^L at the
end, it does print. So now I am in the situation that the HP computer
doesn't talk to the HP printer but to the Panasonic one.
The printer has only one connector which seems proprietary, but the
other end of the end of the cable is parallel.
Thanks, Vilmos
^ permalink raw reply
* [parisc-linux] Re: floating point exception error
From: Randolph Chung @ 2003-01-10 7:54 UTC (permalink / raw)
To: John David Anglin; +Cc: parisc-linux
In-Reply-To: <200212112305.gBBN5Bdj021432@hiauly1.hia.nrc.ca>
In reference to a message from John David Anglin, dated Dec 11:
> > The code _seems_ to trap on a PA8600. Though I won't say anything until
> > I enable debugging in the trap handler and rerun the test.
>
> The code doesn't seem to trap on a A500 which I believe is a PA8500.
> I think we need to look at bits 0..1 of the coprocessor configuration
> register to determine instruction validity. See table 8-6 on page 8-11.
> I can look at what the HP compiler does. Up to now, we have assumed
> that all PA8000 machines have the same instruction set.
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....
puzzled,
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
^ permalink raw reply
* Re: [patch 2.5] 2-pass PCI probing, generic part
From: Eric W. Biederman @ 2003-01-10 7:56 UTC (permalink / raw)
To: Grant Grundler
Cc: Linus Torvalds, Ivan Kokshaysky, Benjamin Herrenschmidt, Alan Cox,
Paul Mackerras, davidm, Linux Kernel Mailing List, greg
In-Reply-To: <20030110010906.GC18141@cup.hp.com>
grundler@cup.hp.com (Grant Grundler) writes:
> On Thu, Jan 09, 2003 at 03:35:32PM -0800, Linus Torvalds wrote:
> > The only real reason to worry about BAR sizing is really to do resource
> > discovery in order to make sure that out bridges have sufficiently big
> > windows for the IO regions. Agreed?
>
> yes. And eventually to make sure regions don't overlap.
>
> > And that should be a non-issue especially on a host bridge, since we
> > almost certainly don't want to reprogram the bridge windows there anyway.
>
> Current PARISC servers do not allocate MMIO/IO resources for all PCI devices.
> Only boot devices are configured. Fortunately, default MMIO/IO address
> space assigned to Host bridges seems to work - at least I've not heard
> anyone complain (yet). But no one has tried PCI expansion chassis or
> cards with massive (> 64MB) MMIO BARs.
For what it is worth these cards exist though.
Quadris cards have a 256MB bar, and dolphin cards default to having a 512MB bar.
Both are high performance I/O adapters.
> Because of PCI hotplug, rumor is ia64 firmware folks want to do
> the same thing in the near future.
If someone leaves a big enough hole for hotplug cards I guess it can work...
How you define a potential boot device, and what it saves you to not assign
it resources I don't know.
I am still recovering from putting a 256MB bar and 4GB of ram in a 4GB hole,
with minimal loss on x86, so my imagination of what can be sanely done
on a 64bit arch may be a little stunted..
Eric
^ permalink raw reply
* Re: Are linux network drivers really affected by this?
From: andrea.glorioso @ 2003-01-10 8:08 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
In-Reply-To: <1042116723.2556.3.camel@station3>
>>>>> "npv" == Nils Petter Vaskinn <nils.petter.vaskinn@itsopen.net> writes:
npv> http://www.kb.cert.org/vuls/id/412115
npv> Summary: Some network drivers don't pad ethernet packets with
npv> nulls, they are filled with "garbage" often from previously
npv> sent packets. Linux is mentioned as vulnerable.
The paper presented by Olaf Arkin (amongst other) points to some parts
of the linux code where this "vulnerability" exists. I think Alan Cox
is working on some patches for his tree. I wonder whether it's better
to null-pad ethernet packets or to fill them with random values
(possibly an overkill, but more resiliant against fingerprinting).
bye,
andrea
--
Andrea Glorioso andrea.glorioso@binary-only.com
Binary Only http://www.binary-only.com/
Via A. Zanolini, 7/b Tel: +39-348.921.43.79
40126 Bologna Fax: +39-051-930.31.133
^ permalink raw reply
* Re: nForce IDE in 2.5?
From: Joshua M. Kwan @ 2003-01-10 8:12 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20030110073530.GA6681@kamui>
[-- Attachment #1: Type: text/plain, Size: 2754 bytes --]
Bleh, ignore me. I just read the archives
-Josh
On Thu, Jan 09, 2003 at 11:35:30PM -0800, Joshua M. Kwan wrote:
> It's missing a PCI identifier variable for the chipset itself, and if I
> knew what its value is supposed to be, or where to put it, I would make
> a patch for it.. =\
>
> Attached is the error log from the build. I am using 2.5.x-current...
>
> Regards
> Josh
> In file included from drivers/ide/pci/nvidia.c:29:
> drivers/ide/pci/nvidia.h:35: `PCI_DEVICE_ID_NVIDIA_NFORCE_IDE' undeclared here (not in a function)
> drivers/ide/pci/nvidia.h:35: initializer element is not constant
> drivers/ide/pci/nvidia.h:35: (near initialization for `nvidia_chipsets[0].device')
> drivers/ide/pci/nvidia.h:43: initializer element is not constant
> drivers/ide/pci/nvidia.h:43: (near initialization for `nvidia_chipsets[0].enablebits[0]')
> drivers/ide/pci/nvidia.h:43: initializer element is not constant
> drivers/ide/pci/nvidia.h:43: (near initialization for `nvidia_chipsets[0].enablebits[1]')
> drivers/ide/pci/nvidia.h:43: initializer element is not constant
> drivers/ide/pci/nvidia.h:43: (near initialization for `nvidia_chipsets[0].enablebits')
> drivers/ide/pci/nvidia.h:46: initializer element is not constant
> drivers/ide/pci/nvidia.h:46: (near initialization for `nvidia_chipsets[0]')
> drivers/ide/pci/nvidia.c: In function `nforce_ratemask':
> drivers/ide/pci/nvidia.c:79: `PCI_DEVICE_ID_NVIDIA_NFORCE_IDE' undeclared (first use in this function)
> drivers/ide/pci/nvidia.c:79: (Each undeclared identifier is reported only once
> drivers/ide/pci/nvidia.c:79: for each function it appears in.)
> drivers/ide/pci/nvidia.c: In function `ata66_nforce':
> drivers/ide/pci/nvidia.c:288: `PCI_DEVICE_ID_NVIDIA_NFORCE_IDE' undeclared (first use in this function)
> drivers/ide/pci/nvidia.c: In function `nforce_init_one':
> drivers/ide/pci/nvidia.c:338: warning: `_MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:419)
> drivers/ide/pci/nvidia.c: At top level:
> drivers/ide/pci/nvidia.c:343: `PCI_DEVICE_ID_NVIDIA_NFORCE_IDE' undeclared here (not in a function)
> drivers/ide/pci/nvidia.c:343: initializer element is not constant
> drivers/ide/pci/nvidia.c:343: (near initialization for `nforce_pci_tbl[0].device')
> drivers/ide/pci/nvidia.c:343: initializer element is not constant
> drivers/ide/pci/nvidia.c:343: (near initialization for `nforce_pci_tbl[0]')
> drivers/ide/pci/nvidia.c:344: initializer element is not constant
> drivers/ide/pci/nvidia.c:344: (near initialization for `nforce_pci_tbl[1]')
> make[3]: *** [drivers/ide/pci/nvidia.o] Error 1
> make[2]: *** [drivers/ide/pci] Error 2
> make[1]: *** [drivers/ide] Error 2
> make: *** [drivers] Error 2
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Causes of missing /proc/acpi/sleep entry?
From: Nigel Cunningham @ 2003-01-10 8:06 UTC (permalink / raw)
To: ACPI List
[-- Attachment #1: Type: text/plain, Size: 206 bytes --]
Hi all.
I've just given 2.5.55 a try. With or without a DSDT override for my
Omnibook XE3, I get no /proc/acpi/sleep file. Any suggestions as to what
I should look at/for?
Regards,
Nigel
(Log attached)
[-- Attachment #2: 2.5.55dmesg --]
[-- Type: text/plain, Size: 11102 bytes --]
Linux version 2.5.55 (root-udXHSmD1qAz9bBlWBkG5g4WQyAnV0byH@public.gmane.org) (gcc version 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)) #1 Fri Jan 10 20:44:34 NZDT 2003
Video mode to be used for restore is 317
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009e800 (usable)
BIOS-e820: 000000000009e800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000ce000 - 00000000000d0000 (reserved)
BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000076f0000 (usable)
BIOS-e820: 00000000076f0000 - 00000000076ff000 (ACPI data)
BIOS-e820: 00000000076ff000 - 0000000007700000 (ACPI NVS)
BIOS-e820: 0000000007700000 - 0000000007780000 (usable)
BIOS-e820: 0000000007780000 - 0000000008000000 (reserved)
BIOS-e820: 00000000ffb80000 - 00000000ffc00000 (reserved)
BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
119MB LOWMEM available.
On node 0 totalpages: 30592
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 26496 pages, LIFO batch:6
HighMem zone: 0 pages, LIFO batch:1
ACPI: RSDP (v000 HP-MCD ) @ 0x000f6190
ACPI: RSDT (v001 HP-MCD RSDT 01540.00000) @ 0x076f9cf3
ACPI: FADT (v001 HP-MCD GF DSDT 01540.00000) @ 0x076fef8c
ACPI: DSDT (v001 HP-MCD GF DSDT 01540.00000) @ 0x00000000
ACPI: BIOS passes blacklist
Building zonelist for node : 0
Kernel command line: BOOT_IMAGE=devel ro root=306 quiet devfs=mount resume=/dev/hda5 init S
Initializing CPU#0
PID hash table entries: 512 (order 9: 4096 bytes)
Detected 929.918 MHz processor.
Console: colour dummy device 80x25
Calibrating delay loop... 1839.10 BogoMIPS
Memory: 117148k/122368k available (1947k kernel code, 4596k reserved, 942k data, 124k init, 0k highmem)
Dentry cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
-> /dev
-> /dev/console
-> /root
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
CPU: After generic, caps: 0383f9ff 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Celeron (Coppermine) stepping 0a
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
mtrr: v2.0 (20020519)
device class 'cpu': registering
device class cpu: adding driver system:cpu
PCI: PCI BIOS revision 2.10 entry at 0xfd98a, last bus=2
PCI: Using configuration type 1
device class cpu: adding device CPU 0
interfaces: adding device CPU 0
BIO: pool of 256 setup, 14Kb (56 bytes/bio)
biovec pool[0]: 1 bvecs: 228 entries (12 bytes)
biovec pool[1]: 4 bvecs: 228 entries (48 bytes)
biovec pool[2]: 16 bvecs: 228 entries (192 bytes)
biovec pool[3]: 64 bvecs: 228 entries (768 bytes)
biovec pool[4]: 128 bvecs: 114 entries (1536 bytes)
biovec pool[5]: 256 bvecs: 57 entries (3072 bytes)
ACPI: Subsystem revision 20021217
tbget-0272: *** Info: Table [DSDT] replaced by host OS
tbxface-0098 [03] acpi_load_tables : ACPI Tables successfully acquired
Parsing all Control Methods:...........................................................................................................................................................................
Table [DSDT] - 598 Objects with 53 Devices 171 Methods 22 Regions
ACPI Namespace successfully loaded at root c042713c
evxfevnt-0073 [04] acpi_enable : Transition to ACPI mode successful
evgpe-0258: *** Info: GPE Block0 defined as GPE0 to GPE15
evgpe-0258: *** Info: GPE Block1 defined as GPE16 to GPE31
Executing all Device _STA and_INI methods:.....................................................
53 Devices found containing: 53 _STA, 3 _INI methods
Completing Region/Field/Buffer/Package initialization:...........................................................
Initialized 10/22 Regions 0/0 Fields 33/33 Buffers 16/16 Packages (598 nodes)
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
Transparent bridge - Intel Corp. 82801BAM/CAM PCI Bri
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT]
pci_bind-0188 [07] acpi_pci_bind : Device 00:02:06.00 not present in PCI namespace
pci_bind-0188 [08] acpi_pci_bind : Device 00:02:00.00 not present in PCI namespace
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 10 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 9 10 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 9 10 11 12 14 15, disabled)
ACPI: Embedded Controller [EC0] (gpe 28)
Linux Plug and Play Support v0.93 (c) Adam Belay
PnPBIOS: Found PnP BIOS installation structure at 0xc00f6210
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0x9c33, dseg 0x400
pnp: 00:0a: ioport range 0x4d0-0x4d1 has been reserved
pnp: 00:0a: ioport range 0x1000-0x105f has been reserved
pnp: 00:0a: ioport range 0x1060-0x107f has been reserved
pnp: 00:0a: ioport range 0x1180-0x11bf has been reserved
PnPBIOS: 18 nodes reported by PnP BIOS; 18 recorded by driver
block request queues:
128 requests per read queue
128 requests per write queue
8 requests per batch
enter congestion at 31
exit congestion at 33
ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 11
pci_link-0331 [13] acpi_pci_link_set : Link disabled
ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 0
ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 11
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
Enabling SEP on CPU 0
aio_setup: sizeof(struct page) = 40
Journalled Block Device driver loaded
Installing knfsd (copyright (C) 1996 okir-pn4DOG8n3UYbFoVRYvo4fw@public.gmane.org).
ACPI: AC Adapter [ACAD] (on-line)
ACPI: Battery Slot [BAT1] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Processor [CPU0] (supports C1 C2 C3)
Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing disabled
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP]
parport0: irq 7 detected
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
vesafb: framebuffer at 0xe8000000, mapped to 0xc8006000, size 8000k
vesafb: mode is 1024x768x16, linelength=2048, pages=4
vesafb: protected mode interface info at a5f3:1f5f
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
fb0: VESA VGA frame buffer device
device class 'tty': registering
Console: switching to colour frame buffer device 128x48
pty: 256 Unix98 ptys configured
lp0: using parport0 (polling).
Non-volatile memory driver v1.2
i810_rng hardware driver 0.9.8 loaded
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected an Intel 830M Chipset.
agpgart: Maximum main memory to use for agp memory: 86M
agpgart: detected 8060K stolen memory.
agpgart: AGP aperture is 128M @ 0xe8000000
[drm] Initialized i830 1.2.1 20020828 on minor 0
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <saw-5bpFXmC1L3aJ4eUNlOKu3Q@public.gmane.org> and others
eth0: OEM i82557/i82558 10/100 Ethernet, 00:02:3F:30:CD:4A, IRQ 10.
Board assembly 000000-000, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0x04f4518b).
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH3M: IDE controller at PCI slot 00:1f.1
PCI: Enabling device 00:1f.1 (0005 -> 0007)
ICH3M: chipset revision 1
ICH3M: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x1860-0x1867, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x1868-0x186f, BIOS settings: hdc:DMA, hdd:pio
hda: HITACHI_DK23CA-10, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: CD-224E, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: host protected area => 1
hda: 19640880 sectors (10056 MB) w/512KiB Cache, CHS=19485/16/63, UDMA(100)
hda: hda1 hda2 < hda5 hda6 >
end_request: I/O error, dev hdc, sector 0
hdc: ATAPI 24X CD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
end_request: I/O error, dev hdc, sector 0
Console: switching to colour frame buffer device 128x48
Linux Kernel Card Services 3.1.22
options: [pci] [cardbus] [pm]
PCI: Enabling device 02:04.0 (0081 -> 0083)
PCI: Enabling device 02:04.1 (0081 -> 0083)
device class 'input': registering
register interface 'mouse' with class 'input'
mice: PS/2 mouse device common for all mice
i8042.c: Detected active multiplexing controller, rev 1.1.
serio: i8042 AUX0 port at 0x60,0x64 irq 12
serio: i8042 AUX1 port at 0x60,0x64 irq 12
serio: i8042 AUX2 port at 0x60,0x64 irq 12
input: PS/2 Synaptics TouchPad on isa0060/serio4
serio: i8042 AUX3 port at 0x60,0x64 irq 12
input: AT Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
maestro3: version 1.23 built at 20:40:58 Jan 10 2003
maestro3: Configuring ESS Allegro found at IO 0x2000 IRQ 5
maestro3: subvendor id: 0x0021103c
Yenta IRQ list 0098, PCI irq9
Socket status: 30000006
Yenta IRQ list 0098, PCI irq9
Socket status: 30000006
ac97_codec: AC97 Audio codec, id: 0x4583:0x8308 (ESS Allegro ES1988)
NET4: Linux TCP/IP 1.0 for NET4.0
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
ip_conntrack version 2.1 (956 buckets, 7648 max) - 304 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
BIOS EDD facility v0.07 2002-Oct-24, 1 devices found
Resume Machine: resuming from /dev/hda5
Resuming from device ide0(3,5)
Resume Machine: This is normal swap space
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 124k freed
EXT3 FS 2.4-0.9.16, 02 Dec 2001 on ide0(3,6), internal journal
Adding 257000k swap on /dev/hda5. Priority:-1 extents:1
end_request: I/O error, dev hdc, sector 0
end_request: I/O error, dev hdc, sector 0
hdc: DMA disabled
^ 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.