* Re: [PATCH]: remove warnings on promlib
From: Juan Quintela @ 2002-12-19 10:17 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: linux-mips, Ralf Baechle
In-Reply-To: <Pine.GSO.3.96.1021218174743.5977E-100000@delta.ds2.pg.gda.pl>
>>>>> "maciej" == Maciej W Rozycki <macro@ds2.pg.gda.pl> writes:
maciej> On 18 Dec 2002, Juan Quintela wrote:
>> Index: arch/mips/lib/promlib.c
>> ===================================================================
>> RCS file: /home/cvs/linux/arch/mips/lib/promlib.c,v
>> retrieving revision 1.1.2.1
>> diff -u -r1.1.2.1 promlib.c
>> --- arch/mips/lib/promlib.c 28 Sep 2002 22:28:38 -0000 1.1.2.1
>> +++ arch/mips/lib/promlib.c 18 Dec 2002 00:49:18 -0000
>> @@ -1,3 +1,7 @@
>> +
>> +#include <asm/sgialib.h>
>> +#include <linux/kernel.h>
>> +
>> #include <stdarg.h>
>>
>> void prom_printf(char *fmt, ...)
maciej> A few comments:
maciej> 1. <linux> includes first, <asm> ones following (hmm, shouldn't that be
maciej> obvious...).
maciej> 2. <linux/kernel.h> is obviously OK for vsprintf().
maciej> 3. I would hesitate using <asm/sgialib.h> here being too much platform
maciej> specific. Either a separate generic <asm/prom.h> should be created for
maciej> primitives like prom_putchar(), prom_getchar(), etc. or a private
maciej> conservative declaration should be used here. The reason is the functions
maciej> are much platform-specific, e.g. they may be pointers or even macros --
maciej> see <asm/dec/prom.h> for a not-so-trivial example (luckily, DECstations
maciej> support prom_printf() directly, so they don't have to use promlib.c).
Something like that?
Once there, s/vsprintf/vsnprintf/.
If anybody calls prom_printf with more than 1024 chars, we were b0rked
:((
I didn't did the changes for the other users of prom_* that was using
asm/sgialib.h, but change is trivial.
Later, Juan.
diff -uNp build/include/asm-mips/prom.h.orig build/include/asm-mips/prom.h
--- build/include/asm-mips/prom.h.orig 1970-01-01 01:00:00.000000000 +0100
+++ build/include/asm-mips/prom.h 2002-12-18 19:00:47.000000000 +0100
@@ -0,0 +1,21 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Interface with the low level prom consoles.
+ *
+ * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com)
+ * Copyright (C) 2001, 2002 Ralf Baechle (ralf@gnu.org)
+ */
+#ifndef _ASM_PROM_H
+#define _ASM_PROM_H
+
+/* Simple char-by-char console I/O. */
+extern void prom_putchar(char c);
+extern char prom_getchar(void);
+
+/* Generic printf() console I/O. */
+extern void prom_printf(char *fmt, ...);
+
+#endif /* _ASM_PROM_H */
Index: arch/mips/arc/init.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/arc/init.c,v
retrieving revision 1.10.2.3
diff -u -r1.10.2.3 init.c
--- arch/mips/arc/init.c 1 Aug 2002 22:26:40 -0000 1.10.2.3
+++ arch/mips/arc/init.c 19 Dec 2002 09:21:07 -0000
@@ -11,6 +11,7 @@
#include <linux/kernel.h>
#include <asm/sgialib.h>
+#include <asm/prom.h>
#undef DEBUG_PROM_INIT
Index: arch/mips/lib/promlib.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/lib/promlib.c,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 promlib.c
--- arch/mips/lib/promlib.c 28 Sep 2002 22:28:38 -0000 1.1.2.1
+++ arch/mips/lib/promlib.c 19 Dec 2002 09:21:08 -0000
@@ -1,13 +1,20 @@
+
+
+#include <linux/kernel.h>
+#include <asm/prom.h>
+
#include <stdarg.h>
+#define BUFSIZE 1024
+
void prom_printf(char *fmt, ...)
{
va_list args;
- char ppbuf[1024];
+ char ppbuf[BUFSIZE];
char *bptr;
va_start(args, fmt);
- vsprintf(ppbuf, fmt, args);
+ vsnprintf(ppbuf, BUFSIZE, fmt, args);
bptr = ppbuf;
Index: arch/mips/sgi-ip22/ip22-system.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sgi-ip22/ip22-system.c,v
retrieving revision 1.1.2.8
diff -u -r1.1.2.8 ip22-system.c
--- arch/mips/sgi-ip22/ip22-system.c 18 Dec 2002 19:11:09 -0000 1.1.2.8
+++ arch/mips/sgi-ip22/ip22-system.c 19 Dec 2002 09:21:09 -0000
@@ -11,6 +11,7 @@
#include <asm/cpu.h>
#include <asm/sgi/sgi.h>
#include <asm/sgialib.h>
+#include <asm/prom.h>
enum sgi_mach sgimach;
Index: include/asm-mips/sgialib.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/sgialib.h,v
retrieving revision 1.10.2.3
diff -u -r1.10.2.3 sgialib.h
--- include/asm-mips/sgialib.h 1 Aug 2002 22:26:40 -0000 1.10.2.3
+++ include/asm-mips/sgialib.h 19 Dec 2002 09:21:15 -0000
@@ -30,13 +30,6 @@
/* Init the PROM library and it's internal data structures. */
extern void prom_init(int argc, char **argv, char **envp, int *prom_vec);
-/* Simple char-by-char console I/O. */
-extern void prom_putchar(char c);
-extern char prom_getchar(void);
-
-/* Generic printf() using ARCS console I/O. */
-extern void prom_printf(char *fmt, ...);
-
/* Memory descriptor management. */
#define PROM_MAX_PMEMBLOCKS 32
struct prom_pmemblock {
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* Re: 2.5.52-mm2
From: William Lee Irwin III @ 2002-12-19 10:12 UTC (permalink / raw)
To: Andrew Morton, lkml, linux-mm
In-Reply-To: <20021219092853.GK1922@holomorphy.com>
On Wed, Dec 18, 2002 at 09:53:18PM -0800, Andrew Morton wrote:
>>> url: http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.52/2.5.52-mm2/
On Thu, Dec 19, 2002 at 12:54:26AM -0800, William Lee Irwin III wrote:
>> Kernel compile on ramfs, shpte off, overcommit on (probably more like a
>> stress test for shpte):
On Thu, Dec 19, 2002 at 01:28:53AM -0800, William Lee Irwin III wrote:
> With shpte on:
With the following patch:
c013d4d4 94944 0.310788 zap_pte_range
c01355d0 104773 0.342962 nr_free_pages
c014f65c 107566 0.352105 __fput
c01b1750 112055 0.366799 __copy_user_intel
c0115350 121040 0.39621 smp_apic_timer_interrupt
c0119814 126089 0.412738 kmap_atomic
c014b6cc 145095 0.474952 pte_unshare
c01fb11c 145992 0.477888 sync_buffer
c0122a78 148079 0.484719 current_kernel_time
c01168b8 193805 0.634398 x86_profile_hook
c013f140 205233 0.671806 do_no_page
c0164aac 235356 0.77041 d_lookup
c01b18f8 257358 0.842431 __copy_from_user
c0131f7c 275559 0.90201 find_get_page
c011a560 282341 0.92421 scheduler_tick
c0140090 300128 0.982434 vm_enough_memory
c013f4bc 310474 1.0163 handle_mm_fault
c014f3d0 312725 1.02367 get_empty_filp
c011a0a8 365066 1.195 load_balance
c014f9e9 502737 1.64565 .text.lock.file_table
c01b1890 719105 2.35391 __copy_to_user
c0135768 911894 2.98498 __get_page_state
c013ee50 952823 3.11895 do_anonymous_page
c01436d0 1079864 3.53481 page_add_rmap
c01438cc 1186938 3.8853 page_remove_rmap
c0106f38 17763755 58.1476 poll_idle
pfn_to_nid() got lots of icache misses. Try using a macro.
arch/i386/kernel/i386_ksyms.c | 1 -
arch/i386/kernel/numaq.c | 15 ++-------------
include/asm-i386/numaq.h | 3 ++-
3 files changed, 4 insertions(+), 15 deletions(-)
diff -urpN linux-2.5.52-mm1/arch/i386/kernel/i386_ksyms.c mm1-2.5.52-1/arch/i386/kernel/i386_ksyms.c
--- linux-2.5.52-mm1/arch/i386/kernel/i386_ksyms.c 2002-12-16 19:29:45.000000000 -0800
+++ mm1-2.5.52-1/arch/i386/kernel/i386_ksyms.c 2002-12-17 08:47:25.000000000 -0800
@@ -67,7 +67,6 @@ EXPORT_SYMBOL(EISA_bus);
EXPORT_SYMBOL(MCA_bus);
#ifdef CONFIG_DISCONTIGMEM
EXPORT_SYMBOL(node_data);
-EXPORT_SYMBOL(pfn_to_nid);
#endif
#ifdef CONFIG_X86_NUMAQ
EXPORT_SYMBOL(xquad_portio);
diff -urpN linux-2.5.52-mm1/arch/i386/kernel/numaq.c mm1-2.5.52-1/arch/i386/kernel/numaq.c
--- linux-2.5.52-mm1/arch/i386/kernel/numaq.c 2002-12-15 18:08:13.000000000 -0800
+++ mm1-2.5.52-1/arch/i386/kernel/numaq.c 2002-12-17 08:51:44.000000000 -0800
@@ -27,6 +27,7 @@
#include <linux/mm.h>
#include <linux/bootmem.h>
#include <linux/mmzone.h>
+#include <linux/module.h>
#include <asm/numaq.h>
/* These are needed before the pgdat's are created */
@@ -82,19 +83,7 @@ static void __init smp_dump_qct(void)
* physnode_map[8- ] = -1;
*/
int physnode_map[MAX_ELEMENTS] = { [0 ... (MAX_ELEMENTS - 1)] = -1};
-
-#define PFN_TO_ELEMENT(pfn) (pfn / PAGES_PER_ELEMENT)
-#define PA_TO_ELEMENT(pa) (PFN_TO_ELEMENT(pa >> PAGE_SHIFT))
-
-int pfn_to_nid(unsigned long pfn)
-{
- int nid = physnode_map[PFN_TO_ELEMENT(pfn)];
-
- if (nid == -1)
- BUG(); /* address is not present */
-
- return nid;
-}
+EXPORT_SYMBOL(physnode_map);
/*
* for each node mark the regions
diff -urpN linux-2.5.52-mm1/include/asm-i386/numaq.h mm1-2.5.52-1/include/asm-i386/numaq.h
--- linux-2.5.52-mm1/include/asm-i386/numaq.h 2002-12-15 18:08:09.000000000 -0800
+++ mm1-2.5.52-1/include/asm-i386/numaq.h 2002-12-17 08:45:19.000000000 -0800
@@ -38,10 +38,11 @@
#define MAX_ELEMENTS 256
#define PAGES_PER_ELEMENT (16777216/256)
+extern int physnode_map[];
+#define pfn_to_nid(pfn) ({ physnode_map[(pfn) / PAGES_PER_ELEMENT]; })
#define pfn_to_pgdat(pfn) NODE_DATA(pfn_to_nid(pfn))
#define PHYSADDR_TO_NID(pa) pfn_to_nid(pa >> PAGE_SHIFT)
#define MAX_NUMNODES 8
-extern int pfn_to_nid(unsigned long);
extern void get_memcfg_numaq(void);
#define get_memcfg_numa() get_memcfg_numaq()
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* NMI: IOCK error (debug interrupt?) - nope
From: Gianni Tedesco @ 2002-12-19 10:23 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]
Hello,
A firewall of ours recently went tits up (2.4.19). It was still routing
traffic but when I connected to SSH for example the SSH banner would not
appear, it looked like all userspace was dead.
When we looked in the logs there was this. Presumably the hardware is
broken. But I wonder if anyone can confirm this? Thanks!
NMI: IOCK error (debug interrupt?)
CPU: 0
EIP: 0010:[default_idle+34/48] Not tainted
EIP: 0010:[<c0106e12>] Not tainted
EFLAGS: 00000246
eax: 00000000 ebx: c0106df0 ecx: 00000032 edx: 00000019
esi: c02f6000 edi: c02f6000 ebp: c0106df0 esp: c02f7fcc
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=c02f7000)
Stack: c0106e92 00000002 00098700 c0105000 0008e000 c02f8759 c028e6c0
0001ffc0
0001ffc0 0001ffc0 0001ffc0 c03404c0 c0100191
Call Trace: [cpu_idle+82/112] [_stext+0/48]
Call Trace: [<c0106e92>] [<c0105000>]
Code: f4 c3 fb c3 8d 76 00 8d bc 27 00 00 00 00 fb b8 ff ff ff ff
--
// Gianni Tedesco (gianni at ecsc dot co dot uk)
lynx --source www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* vt8235 fix, hopefully last variant
From: Vojtech Pavlik @ 2002-12-19 10:26 UTC (permalink / raw)
To: John Reiser, AnonimoVeneziano, Patrick Petermair, Roland Quast,
LKML
[-- Attachment #1: Type: text/plain, Size: 183 bytes --]
Hi!
Can you guys try out this last take on a fix for your ATAPI device
problems? Applies against clean 2.4.20.
Please report failure/success.
Thanks.
--
Vojtech Pavlik
SuSE Labs
[-- Attachment #2: vt8235-atapi --]
[-- Type: text/plain, Size: 1331 bytes --]
ChangeSet@1.884, 2002-12-19 11:23:11+01:00, vojtech@suse.cz
VIA IDE: Always use slow address setup timings for ATAPI devices.
via82cxxx.c | 19 ++++++-------------
1 files changed, 6 insertions(+), 13 deletions(-)
diff -Nru a/drivers/ide/pci/via82cxxx.c b/drivers/ide/pci/via82cxxx.c
--- a/drivers/ide/pci/via82cxxx.c Thu Dec 19 11:23:42 2002
+++ b/drivers/ide/pci/via82cxxx.c Thu Dec 19 11:23:42 2002
@@ -1,16 +1,5 @@
/*
- * $Id: via82cxxx.c,v 3.35-ac2 2002/09/111 Alan Exp $
- *
- * Copyright (c) 2000-2001 Vojtech Pavlik
- *
- * Based on the work of:
- * Michel Aubry
- * Jeff Garzik
- * Andre Hedrick
- */
-
-/*
- * Version 3.35
+ * Version 3.36
*
* VIA IDE driver for Linux. Supported southbridges:
*
@@ -152,7 +141,7 @@
via_print("----------VIA BusMastering IDE Configuration"
"----------------");
- via_print("Driver Version: 3.35-ac");
+ via_print("Driver Version: 3.36");
via_print("South Bridge: VIA %s",
via_config->name);
@@ -351,6 +340,10 @@
ide_timing_compute(peer, peer->current_speed, &p, T, UT);
ide_timing_merge(&p, &t, &t, IDE_TIMING_8BIT);
}
+
+ /* Always use 4 address setup clocks on ATAPI devices */
+ if (drive->media != ide_disk)
+ t.setup = 4;
via_set_speed(HWIF(drive)->pci_dev, drive->dn, &t);
^ permalink raw reply
* Re: [PATCH]: make prototype of printk available
From: Juan Quintela @ 2002-12-19 10:25 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: linux mips mailing list, Ralf Baechle
In-Reply-To: <Pine.GSO.3.96.1021218173641.5977C-100000@delta.ds2.pg.gda.pl>
>>>>> "maciej" == Maciej W Rozycki <macro@ds2.pg.gda.pl> writes:
maciej> On 18 Dec 2002, Juan Quintela wrote:
>> Once there, put a tag to the printk.
maciej> Why is the default log level incorrect here?
The problem (not here in general), is that if printk's use the default
log level, then you as a user has no way to raise/lower the default
log level (i.e. the messages that you want to printk or not).
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Dave Jones @ 2002-12-19 10:27 UTC (permalink / raw)
To: John Bradford; +Cc: Alan Cox, lm, lm, torvalds, vonbrand, linux-kernel, akpm
In-Reply-To: <200212190059.gBJ0xLdv008694@darkstar.example.net>
On Thu, Dec 19, 2002 at 12:59:20AM +0000, John Bradford wrote:
> I don't like bugzilla particularly, it's too clunky, and it's
> difficult to check that you are not entering a duplicate bug when the
> database gets too big.
File bug anyway and worry about it later. The bugzilla elves regularly
go through the database cleaning up crufty bits, marking dupes,
closing invalids, world peace etc etc. It seems to be holding
up well so far. Of the 180 bugs filed, I think I've personally rejected
<10 dupes/invalids. Other folks haven't done that many too.
Here's to hoping it continues to remain high signal.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
^ permalink raw reply
* Re: EDE - 0.0.5
From: Harry Kalogirou @ 2002-12-19 10:22 UTC (permalink / raw)
To: jb1; +Cc: Neil Holmes, Linux 8086
In-Reply-To: <Pine.LNX.4.33.0212190138350.23943-100000@olympus.btstream.com>
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]
> On Wed, 18 Dec 2002, Neil Holmes wrote:
>
> ...
> > I have, for 0.0.5, also upgraded the version of elkscmd programs. I have
> > taken what was the latest download on sourceforge, namely elkscmd_20020501,
> > at the time I was building the release.
> ...
>
> The elkscmd CVS has a *bunch* of problems. Please check my (jb1's)
> submissions to the mailing list, September through December 2002; much of
> it is about problems in another package (elksnet), but I remember
> submitting a list of problems ("Re: root disk!" in reply to Paul Nasrat)
> and at least two bug fixes (for more.c and clock.c). My stuff is in no way
> "official", so you should check with the developers ... I haven't heard
> from them.
>
I believe EDE 0.0.5 can come out as it is now. I will make a new release
of the kernel soon and then we update the EDE. For example the next EDE
sould have :
- 0.1.2 kernel.
- Swapfile setup system.
- programs compiled to the new file format that enables
better memory managment.
Harry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: [Lse-tech] Re: 15000+ processes -- poor performance ?!
From: William Lee Irwin III @ 2002-12-19 10:27 UTC (permalink / raw)
To: Denis Vlasenko
Cc: David Lang, Robert Love, Till Immanuel Patzschke, lse-tech,
linux-kernel
In-Reply-To: <200212191015.gBJAFss28329@Port.imtp.ilyichevsk.odessa.ua>
On 19 December 2002 00:05, William Lee Irwin III wrote:
>> Well, a better solution would be a userspace free of /proc/
>> dependency.
>> Or actually fixing the kernel. proc_pid_readdir() wants an
>> efficiently indexable linear list, e.g. TAOCP's 6.2.3 "Linear List
>> Representation". At that point its expense is proportional to the
>> buffer size and "seeking" about the list as it is wont to do is
>> O(lg(processes)).
On Thu, Dec 19, 2002 at 01:05:03PM -0200, Denis Vlasenko wrote:
> A short-time solution: run top d 30 to make it refresh only every 30 seconds.
> This will greatly reduce top's own load skew.
As userspace solutions go your suggestions is just as good. The kernel
still needs to get its act together and with some urgency.
Bill
^ permalink raw reply
* Re: 2.5.52-mm2
From: Andrew Morton @ 2002-12-19 10:31 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: lkml, linux-mm
In-Reply-To: <20021219101219.GS31800@holomorphy.com>
William Lee Irwin III wrote:
>
> On Wed, Dec 18, 2002 at 09:53:18PM -0800, Andrew Morton wrote:
> >>> url: http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.52/2.5.52-mm2/
>
> On Thu, Dec 19, 2002 at 12:54:26AM -0800, William Lee Irwin III wrote:
> >> Kernel compile on ramfs, shpte off, overcommit on (probably more like a
> >> stress test for shpte):
>
> On Thu, Dec 19, 2002 at 01:28:53AM -0800, William Lee Irwin III wrote:
> > With shpte on:
>
> With the following patch:
>
> c013d4d4 94944 0.310788 zap_pte_range
> c01355d0 104773 0.342962 nr_free_pages
> c014f65c 107566 0.352105 __fput
> c01b1750 112055 0.366799 __copy_user_intel
> c0115350 121040 0.39621 smp_apic_timer_interrupt
> c0119814 126089 0.412738 kmap_atomic
> c014b6cc 145095 0.474952 pte_unshare
> c01fb11c 145992 0.477888 sync_buffer
> c0122a78 148079 0.484719 current_kernel_time
> c01168b8 193805 0.634398 x86_profile_hook
> c013f140 205233 0.671806 do_no_page
> c0164aac 235356 0.77041 d_lookup
> c01b18f8 257358 0.842431 __copy_from_user
> c0131f7c 275559 0.90201 find_get_page
> c011a560 282341 0.92421 scheduler_tick
> c0140090 300128 0.982434 vm_enough_memory
> c013f4bc 310474 1.0163 handle_mm_fault
> c014f3d0 312725 1.02367 get_empty_filp
> c011a0a8 365066 1.195 load_balance
> c014f9e9 502737 1.64565 .text.lock.file_table
> c01b1890 719105 2.35391 __copy_to_user
> c0135768 911894 2.98498 __get_page_state
> c013ee50 952823 3.11895 do_anonymous_page
> c01436d0 1079864 3.53481 page_add_rmap
> c01438cc 1186938 3.8853 page_remove_rmap
> c0106f38 17763755 58.1476 poll_idle
Is that improved?
> pfn_to_nid() got lots of icache misses. Try using a macro.
What's the callsite?
Actually, just looking at mmzone.h, I have to say "ick". The
non-NUMA case seems unnecessarily overdone. eg:
#define page_to_pfn(page)
((page - page_zone(page)->zone_mem_map) + page_zone(page)->zone_start_pfn)
Ouch. Why can't we have the good old `page - mem_map' here?
^ permalink raw reply
* Re: [Lse-tech] Re: 15000+ processes -- poor performance ?!
From: Denis Vlasenko @ 2002-12-19 15:05 UTC (permalink / raw)
To: William Lee Irwin III, David Lang
Cc: Robert Love, Till Immanuel Patzschke, lse-tech, linux-kernel
In-Reply-To: <20021219020552.GO31800@holomorphy.com>
On 19 December 2002 00:05, William Lee Irwin III wrote:
> On Wed, Dec 18, 2002 at 05:44:46PM -0800, David Lang wrote:
> > In my case I will still be running thousands of processes, so I
> > have to just teach everyone not to use top instead.
> > David Lang
>
> Well, a better solution would be a userspace free of /proc/
> dependency.
>
> Or actually fixing the kernel. proc_pid_readdir() wants an
> efficiently indexable linear list, e.g. TAOCP's 6.2.3 "Linear List
> Representation". At that point its expense is proportional to the
> buffer size and "seeking" about the list as it is wont to do is
> O(lg(processes)).
A short-time solution: run top d 30 to make it refresh only every 30 seconds.
This will greatly reduce top's own load skew.
--
vda
^ permalink raw reply
* Re: 2.4.19, don't "hdparm -I /dev/hde" if hde is on a Asus A7V133 Promise ctrlr, or...
From: Andre Hedrick @ 2002-12-19 10:19 UTC (permalink / raw)
To: Denis Vlasenko
Cc: Alan Cox, D.A.M. Revok, Manish Lachwani,
Linux Kernel Mailing List
In-Reply-To: <200212190951.gBJ9pCs28149@Port.imtp.ilyichevsk.odessa.ua>
On Thu, 19 Dec 2002, Denis Vlasenko wrote:
> On 18 December 2002 20:38, Alan Cox wrote:
> > On Wed, 2002-12-18 at 21:35, D.A.M. Revok wrote:
> > > So. I /think/ that somehow the Promise controller isn't being
> > > initialized properly by the Linux kernel, UNLESS the mobo's BIOS
> > > inits it first?
> >
> > In some situations yes. The BIOS does stuff including fixups we mere
> > mortals arent permitted to know about.
>
> OTOH mere mortals are allowed to make full dump of PCI config ;)
>
> "D.A.M. Revok" <marvin@synapse.net>, can you send lspci -vvvxxx
> outputs when you boot with BIOS enabled and BIOS disabled?
Promise knows this point.
Thus they moved the setting to a push/pull in the vendor space in the
dma_base+1 and dma_base+3 respectively.
lspci -vvvxxx fails when the content is located in bar4 io space.
Andre Hedrick
LAD Storage Consulting Group
^ permalink raw reply
* [linux-lvm] LVM and ext3
From: Paul Seniuk @ 2002-12-19 10:31 UTC (permalink / raw)
To: linux-lvm
Hello,
Is there support for ext3 partion resizing? (RH 7.3)?
Paul Seniuk
Freestyle Networks
v: 780-919-3629
^ permalink raw reply
* Re: 2.5.52-mm2
From: Andrew Morton @ 2002-12-19 10:31 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: lkml, linux-mm
In-Reply-To: <20021219101219.GS31800@holomorphy.com>
William Lee Irwin III wrote:
>
> On Wed, Dec 18, 2002 at 09:53:18PM -0800, Andrew Morton wrote:
> >>> url: http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.52/2.5.52-mm2/
>
> On Thu, Dec 19, 2002 at 12:54:26AM -0800, William Lee Irwin III wrote:
> >> Kernel compile on ramfs, shpte off, overcommit on (probably more like a
> >> stress test for shpte):
>
> On Thu, Dec 19, 2002 at 01:28:53AM -0800, William Lee Irwin III wrote:
> > With shpte on:
>
> With the following patch:
>
> c013d4d4 94944 0.310788 zap_pte_range
> c01355d0 104773 0.342962 nr_free_pages
> c014f65c 107566 0.352105 __fput
> c01b1750 112055 0.366799 __copy_user_intel
> c0115350 121040 0.39621 smp_apic_timer_interrupt
> c0119814 126089 0.412738 kmap_atomic
> c014b6cc 145095 0.474952 pte_unshare
> c01fb11c 145992 0.477888 sync_buffer
> c0122a78 148079 0.484719 current_kernel_time
> c01168b8 193805 0.634398 x86_profile_hook
> c013f140 205233 0.671806 do_no_page
> c0164aac 235356 0.77041 d_lookup
> c01b18f8 257358 0.842431 __copy_from_user
> c0131f7c 275559 0.90201 find_get_page
> c011a560 282341 0.92421 scheduler_tick
> c0140090 300128 0.982434 vm_enough_memory
> c013f4bc 310474 1.0163 handle_mm_fault
> c014f3d0 312725 1.02367 get_empty_filp
> c011a0a8 365066 1.195 load_balance
> c014f9e9 502737 1.64565 .text.lock.file_table
> c01b1890 719105 2.35391 __copy_to_user
> c0135768 911894 2.98498 __get_page_state
> c013ee50 952823 3.11895 do_anonymous_page
> c01436d0 1079864 3.53481 page_add_rmap
> c01438cc 1186938 3.8853 page_remove_rmap
> c0106f38 17763755 58.1476 poll_idle
Is that improved?
> pfn_to_nid() got lots of icache misses. Try using a macro.
What's the callsite?
Actually, just looking at mmzone.h, I have to say "ick". The
non-NUMA case seems unnecessarily overdone. eg:
#define page_to_pfn(page)
((page - page_zone(page)->zone_mem_map) + page_zone(page)->zone_start_pfn)
Ouch. Why can't we have the good old `page - mem_map' here?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* [PATCH]: unaligned
From: Juan Quintela @ 2002-12-19 10:40 UTC (permalink / raw)
To: Ralf Baechle, mipslist
Hi
- asm wants a unsigned long
- verify_area wants a void *
one of the two places need a cast.
Once there, ralf? forgot that emulate_load_store returns void, then
nuke the return 1 part.
Later, Juan.
Index: arch/mips/kernel/unaligned.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/unaligned.c,v
retrieving revision 1.15.2.11
diff -u -r1.15.2.11 unaligned.c
--- arch/mips/kernel/unaligned.c 17 Dec 2002 23:20:08 -0000 1.15.2.11
+++ arch/mips/kernel/unaligned.c 19 Dec 2002 10:17:48 -0000
@@ -139,7 +139,7 @@
* The remaining opcodes are the ones that are really of interest.
*/
case lh_op:
- if (verify_area(VERIFY_READ, addr, 2))
+ if (verify_area(VERIFY_READ, (void *)addr, 2))
goto sigbus;
__asm__(".set\tnoat\n"
@@ -171,7 +171,7 @@
break;
case lw_op:
- if (verify_area(VERIFY_READ, addr, 4))
+ if (verify_area(VERIFY_READ, (void *)addr, 4))
goto sigbus;
__asm__(
@@ -200,7 +200,7 @@
break;
case lhu_op:
- if (verify_area(VERIFY_READ, addr, 2))
+ if (verify_area(VERIFY_READ, (void *)addr, 2))
goto sigbus;
__asm__(
@@ -241,7 +241,7 @@
* would blow up, so for now we don't handle unaligned 64-bit
* instructions on 32-bit kernels.
*/
- if (verify_area(VERIFY_READ, addr, 4))
+ if (verify_area(VERIFY_READ, (void *)addr, 4))
goto sigbus;
__asm__(
@@ -284,7 +284,7 @@
* would blow up, so for now we don't handle unaligned 64-bit
* instructions on 32-bit kernels.
*/
- if (verify_area(VERIFY_READ, addr, 8))
+ if (verify_area(VERIFY_READ, (void *)addr, 8))
goto sigbus;
__asm__(
@@ -317,7 +317,7 @@
goto sigill;
case sh_op:
- if (verify_area(VERIFY_WRITE, addr, 2))
+ if (verify_area(VERIFY_WRITE, (void *)addr, 2))
goto sigbus;
value = regs->regs[insn.i_format.rt];
@@ -353,7 +353,7 @@
break;
case sw_op:
- if (verify_area(VERIFY_WRITE, addr, 4))
+ if (verify_area(VERIFY_WRITE, (void *)addr, 4))
goto sigbus;
value = regs->regs[insn.i_format.rt];
@@ -391,7 +391,7 @@
* would blow up, so for now we don't handle unaligned 64-bit
* instructions on 32-bit kernels.
*/
- if (verify_area(VERIFY_WRITE, addr, 8))
+ if (verify_area(VERIFY_WRITE, (void *)addr, 8))
goto sigbus;
value = regs->regs[insn.i_format.rt];
@@ -469,7 +469,7 @@
printk(KERN_DEBUG "%s: Forwarding exception at [<%lx>] (%lx)\n",
current->comm, regs->cp0_epc, new_epc);
regs->cp0_epc = new_epc;
- return 1;
+ return;
}
die_if_kernel ("Unhandled kernel unaligned access", regs);
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* Re: Via KT400
From: Dave Jones @ 2002-12-19 10:41 UTC (permalink / raw)
To: Matthew D. Pitts; +Cc: linux-kernel
In-Reply-To: <001301c2a6ed$d9e7c3e0$0100a8c0@pcs686>
On Wed, Dec 18, 2002 at 06:33:20PM -0500, Matthew D. Pitts wrote:
> Has anyone on the list used a motherboard that uses the Via KT400 AGPset? I
> just purchased a Gigabyte GA-7VAX that has it.
See http://bugzilla.kernel.org/show_bug.cgi?id=14
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: [Lse-tech] Re: 15000+ processes -- poor performance ?!
From: Denis Vlasenko @ 2002-12-19 15:15 UTC (permalink / raw)
To: William Lee Irwin III
Cc: David Lang, Robert Love, Till Immanuel Patzschke, lse-tech,
linux-kernel
In-Reply-To: <20021219102720.GT31800@holomorphy.com>
On 19 December 2002 08:27, William Lee Irwin III wrote:
> On 19 December 2002 00:05, William Lee Irwin III wrote:
> >> Well, a better solution would be a userspace free of /proc/
> >> dependency.
> >> Or actually fixing the kernel. proc_pid_readdir() wants an
> >> efficiently indexable linear list, e.g. TAOCP's 6.2.3 "Linear List
> >> Representation". At that point its expense is proportional to the
> >> buffer size and "seeking" about the list as it is wont to do is
> >> O(lg(processes)).
>
> On Thu, Dec 19, 2002 at 01:05:03PM -0200, Denis Vlasenko wrote:
> > A short-time solution: run top d 30 to make it refresh only every
> > 30 seconds. This will greatly reduce top's own load skew.
>
> As userspace solutions go your suggestions is just as good. The
> kernel still needs to get its act together and with some urgency.
That was just a suggestion as to how to get realistic picture
of system load for Till Immanuel Patzschke <tip@inw.de>.
--
vda
^ permalink raw reply
* Re: Via KT400
From: Dave Jones @ 2002-12-19 10:43 UTC (permalink / raw)
To: Courtney Grimland; +Cc: Tupshin Harper, linux-kernel
In-Reply-To: <20021218232653.45c6eac7.cgrimland@yahoo.com>
On Wed, Dec 18, 2002 at 11:26:53PM -0600, Courtney Grimland wrote:
> I have the 7VAXP. I only had problems with AGP and sound, and using
> 2.4.20-ac2 absolutely everything on this board works (finally -
> sound!). AGP worked in 2.4.20-ac1 as well as 2.4.21-pre1. I think
> the the IDE issue was resolved in 2.4.20.
The AGP only works if the chipset is in 2.0 compatability mode.
Luckily some BIOSen out there seem to do that if a 2.0 card is present.
If you have an AGP 3.0 card in there you're shit out of luck right now.
I'm working on it..
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: [Lse-tech] Re: 15000+ processes -- poor performance ?!
From: Alex Tomas @ 2002-12-19 10:37 UTC (permalink / raw)
To: William Lee Irwin III
Cc: Denis Vlasenko, David Lang, Robert Love, Till Immanuel Patzschke,
lse-tech, linux-kernel
In-Reply-To: <20021219102720.GT31800@holomorphy.com>
>>>>> William Lee Irwin (WLI) writes:
WLI> On 19 December 2002 00:05, William Lee Irwin III wrote:
>>> Well, a better solution would be a userspace free of /proc/
>>> dependency. Or actually fixing the kernel. proc_pid_readdir()
>>> wants an efficiently indexable linear list, e.g. TAOCP's 6.2.3
>>> "Linear List Representation". At that point its expense is
>>> proportional to the buffer size and "seeking" about the list as
>>> it is wont to do is O(lg(processes)).
WLI> On Thu, Dec 19, 2002 at 01:05:03PM -0200, Denis Vlasenko wrote:
>> A short-time solution: run top d 30 to make it refresh only every
>> 30 seconds. This will greatly reduce top's own load skew.
WLI> As userspace solutions go your suggestions is just as good. The
WLI> kernel still needs to get its act together and with some
WLI> urgency.
what about retreiving info from /proc/kmem or something like? just to
avoid binary -> text(proc) -> binary
^ permalink raw reply
* Re: Docs for the new style dpalloc/hostalloc patch.
From: Pantelis Antoniou @ 2002-12-19 10:39 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-embedded
In-Reply-To: <IGEFJKJNHJDCBKALBJLLEEPCFIAA.joakim.tjernlund@lumentis.se>
Joakim Tjernlund wrote:
>Hi
>
>This looks good to me. It's only a bit big, but I guess that's the price one
>has to pay. I haven't tested it yet though.
>
> Jocke
>
Hi
Yes unfortunately is too big, the complexity will pay off
on the upcoming patches, that will allow to use every last bit
of the dpram.
Just enable the options when compiling.
Every current driver that uses the old-style interface
should work without a problem.
I would be very interested to see them used your updated enet driver.
Regards
Pantelis
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [PATCH]: fix unknown value of page mask
From: Juan Quintela @ 2002-12-19 10:46 UTC (permalink / raw)
To: Ralf Baechle, mipslist
Hi
here we don't do anything if we don't know the size :(
returning a sensical value.
Later, Juan.
Index: arch/mips/lib/dump_tlb.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/lib/dump_tlb.c,v
retrieving revision 1.8.2.6
diff -u -r1.8.2.6 dump_tlb.c
--- arch/mips/lib/dump_tlb.c 18 Dec 2002 22:47:37 -0000 1.8.2.6
+++ arch/mips/lib/dump_tlb.c 19 Dec 2002 10:38:02 -0000
@@ -31,6 +31,7 @@
case PM_64M: return "64Mb";
case PM_256M: return "256Mb";
#endif
+ default: return "unknown size";
}
}
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* Test program for raid
From: SCHEP. - Schepke, Arnt @ 2002-12-19 10:41 UTC (permalink / raw)
To: 'linux-raid@vger.kernel.org'
Hi,
just a little question: I want to test my Software-RAID1 System.
I have some errors and want something like a one year usage in a one day
test.
Do you have an idea what program to use?
Regards
Arnt Schepke
schep@hoeft-wessel.de
^ permalink raw reply
* Re: 2.4.19, don't "hdparm -I /dev/hde" if hde is on a Asus A7V133 Promise ctrlr, or...
From: Denis Vlasenko @ 2002-12-19 15:14 UTC (permalink / raw)
To: Andre Hedrick
Cc: Alan Cox, D.A.M. Revok, Manish Lachwani,
Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.10.10212190217240.8350-100000@master.linux-ide.org>
On 19 December 2002 08:19, Andre Hedrick wrote:
> Promise knows this point.
> Thus they moved the setting to a push/pull in the vendor space in the
> dma_base+1 and dma_base+3 respectively.
> lspci -vvvxxx fails when the content is located in bar4 io space.
Neither I nor original bug reporter (I think) did understand
a bit what you said. Can we plead for IDE -> English translation?
;)
If lspci is of no help, what can we use instead?
--
vda
^ permalink raw reply
* Re: 2.4.19, don't "hdparm -I /dev/hde" if hde is on a Asus A7V133 Promise ctrlr, or...
From: Andre Hedrick @ 2002-12-19 10:33 UTC (permalink / raw)
To: Denis Vlasenko
Cc: Alan Cox, D.A.M. Revok, Manish Lachwani,
Linux Kernel Mailing List
In-Reply-To: <200212191024.gBJAOqs28377@Port.imtp.ilyichevsk.odessa.ua>
On Thu, 19 Dec 2002, Denis Vlasenko wrote:
> On 19 December 2002 08:19, Andre Hedrick wrote:
> > Promise knows this point.
> > Thus they moved the setting to a push/pull in the vendor space in the
> > dma_base+1 and dma_base+3 respectively.
> > lspci -vvvxxx fails when the content is located in bar4 io space.
>
> Neither I nor original bug reporter (I think) did understand
> a bit what you said. Can we plead for IDE -> English translation?
> ;)
> If lspci is of no help, what can we use instead?
They move the setting which were readable in the asic from PCI space in
the 20246/47/62/65/67 into a sense mode of the asic sniffing the contents
of the taskfile registers to internally do the same thing but hide it all.
The new 20268/69/7* report all zeros in the PCI space.
ioperm()
But be prepared to roast your data.
I do not have a good answer!
Andre Hedrick
LAD Storage Consulting Group
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Dave Jones @ 2002-12-19 10:50 UTC (permalink / raw)
To: Alan Cox, Linux Kernel Mailing List; +Cc: Russell King
In-Reply-To: <20021219003740.C20566@flint.arm.linux.org.uk>
On Thu, Dec 19, 2002 at 12:37:40AM +0000, Russell King wrote:
> On Thu, Dec 19, 2002 at 01:09:17AM +0000, Alan Cox wrote:
> > How the actual patches get applied really isnt relevant. I know Linus
> > hated jitterbug, Im guessing he hates bugzilla too ?
>
> I'm waiting for the kernel bugzilla to become useful - currently the
> record for me has been:
>
> 3 bugs total
> 3 bugs for serial code for drivers I don't maintain, reassigned to mbligh.
That was unfortunate, and you got dumped with those because some thought
"Ah, serial! RMK!". Some of the categories in bugzilla still need
broadening IMO.
> This means I write (choose one):
> 1. non-buggy code (highly unlikely)
> 2. code no one tests
> 3. code people do test but report via other means (eg, email, irc)
>
> If it's (3), which it seems to be, it means that bugzilla is failing to
> do its job properly, which is most unfortunate.
It's early days. The types of bugs being filed still fall into the
"useful" "not useful" categories though. I don't think it's really
that important that we track what doesn't compile at this stage.
Those reports are being either closed within a few hours of them
being opened with a "Fixed in BK", or are drivers which no-one currently
wants to fix/can fix (Things like the various sti/cli breakage)
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* [REPORT] unexpected IO-APIC
From: Guillaume Morin @ 2002-12-19 10:43 UTC (permalink / raw)
To: linux-smp; +Cc: guillaume
On my new box, Linux 2.4.20 prints this :
IO APIC #2......
.... register #00: 02000000
....... : physical APIC id: 02
.... register #01: 00178003
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0003
WARNING: unexpected IO-APIC, please mail
to linux-smp@vger.kernel.org
I don't know what information you need exactly. Here is the complete
bootlog :
Linux version 2.4.20 (root@dick) (gcc version 2.95.4 20011002 (Debian prerelease)) #1 Thu Dec 19 01:43:44 CET 2002
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000ce000 - 00000000000d4000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
BIOS-e820: 000000000fff0000 - 000000000fff8000 (ACPI data)
BIOS-e820: 000000000fff8000 - 0000000010000000 (ACPI NVS)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
255MB LOWMEM available.
found SMP MP-table at 000fb940
hm, page 000fb000 reserved twice.
hm, page 000fc000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f7000 reserved twice.
On node 0 totalpages: 65520
zone(0): 4096 pages.
zone(1): 61424 pages.
zone(2): 0 pages.
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: VIA Product ID: VT5440B APIC at: 0xFEE00000
Processor #0 Pentium(tm) Pro APIC version 17
I/O APIC #2 Version 3 at 0xFEC00000.
Processors: 1
Kernel command line: BOOT_IMAGE=Linux ro root=303
Initializing CPU#0
Detected 1533.453 MHz processor.
Console: colour dummy device 80x25
Calibrating delay loop... 3060.53 BogoMIPS
Memory: 256712k/262080k available (1282k kernel code, 4980k reserved, 513k data, 104k init, 0k highmem)
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0383fbff c1c3fbff 00000000 00000000
CPU: Common caps: 0383fbff c1c3fbff 00000000 00000000
CPU: AMD Athlon(tm) XP 1800+ stepping 02
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000080
ESR value after enabling vector: 00000000
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-17, 2-19, 2-20, 2-22, 2-23 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 20.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
....... : physical APIC id: 02
.... register #01: 00178003
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0003
WARNING: unexpected IO-APIC, please mail
to linux-smp@vger.kernel.org
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 001 01 0 0 0 0 0 1 1 39
02 001 01 0 0 0 0 0 1 1 31
03 001 01 0 0 0 0 0 1 1 41
04 001 01 0 0 0 0 0 1 1 49
05 000 00 1 0 0 0 0 0 0 00
06 001 01 0 0 0 0 0 1 1 51
07 001 01 0 0 0 0 0 1 1 59
08 001 01 0 0 0 0 0 1 1 61
09 001 01 0 0 0 0 0 1 1 69
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 001 01 0 0 0 0 0 1 1 71
0d 001 01 0 0 0 0 0 1 1 79
0e 001 01 0 0 0 0 0 1 1 81
0f 001 01 0 0 0 0 0 1 1 89
10 001 01 1 1 0 1 0 1 1 91
11 000 00 1 0 0 0 0 0 0 00
12 001 01 1 1 0 1 0 1 1 99
13 000 00 1 0 0 0 0 0 0 00
14 000 00 1 0 0 0 0 0 0 00
15 001 01 1 1 0 1 0 1 1 A1
16 000 00 1 0 0 0 0 0 0 00
17 000 00 1 0 0 0 0 0 0 00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ18 -> 0:18
IRQ21 -> 0:21
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1533.3276 MHz.
..... host bus clock speed is 266.6656 MHz.
cpu: 0, clocks: 2666656, slice: 1333328
CPU0<T0:2666656,T1:1333328,D:0,S:1333328,C:2666656>
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfdaf1, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router default [1106/3177] at 00:11.0
PCI->APIC IRQ transform: (B0,I8,P0) -> 18
PCI->APIC IRQ transform: (B0,I12,P0) -> 16
PCI->APIC IRQ transform: (B0,I16,P0) -> 21
PCI->APIC IRQ transform: (B0,I16,P1) -> 21
PCI->APIC IRQ transform: (B0,I16,P2) -> 21
PCI->APIC IRQ transform: (B0,I16,P3) -> 21
PCI->APIC IRQ transform: (B0,I17,P0) -> 16
PCI: Via IRQ fixup for 00:10.2, from 10 to 5
PCI: Via IRQ fixup for 00:10.1, from 10 to 5
PCI: Via IRQ fixup for 00:10.0, from 11 to 5
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
IA-32 Microcode Update Driver: v1.11 <tigran@veritas.com>
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16)
Starting kswapd
Journalled Block Device driver loaded
NTFS driver v1.1.22 [Flags: R/O]
ACPI: APM is already active, exiting
radeonfb: ref_clk=2700, ref_div=12, xclk=16600 from BIOS
Console: switching to colour frame buffer device 80x30
radeonfb: ATI Radeon QY VE DDR SGRAM 32 MB
radeonfb: DVI port no monitor connected
radeonfb: CRT port CRT monitor connected
pty: 256 Unix98 ptys configured
Real Time Clock Driver v1.10e
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 89
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci00:11.1
ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:pio, hdd:DMA
hda: Nikimi NIK-XR102A, ATA DISK drive
hdd: 50X CD-ROM, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
blk: queue c030ab24, I/O limit 4095Mb (mask 0xffffffff)
hda: 20066251 sectors (10274 MB) w/1900KiB Cache, CHS=1249/255/63, UDMA(66)
hdd: set_drive_speed_status: status=0x7f { DriveReady DeviceFault SeekComplete DataRequest CorrectedError Index Error }
hdd: set_drive_speed_status: error=0x7f
ide1: Drive 1 didn't accept speed setting. Oh, well.
hdd: ATAPI 40X CD-ROM drive, 128kB Cache, (U)DMA
Uniform CD-ROM driver Revision: 3.12
Partition check:
hda: hda1 hda2 < hda5 > hda3 hda4
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
8139too Fast Ethernet driver 0.9.26
eth0: RealTek RTL8139 Fast Ethernet at 0xd2806f00, 00:e0:4c:39:2b:93, IRQ 18
eth0: Identified 8139 chip type 'RTL-8139C'
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 203M
agpgart: Unsupported Via chipset (device id: 3189), you might want to try agp_try_unsupported=1.
agpgart: no supported devices found.
[drm] Initialized radeon 1.1.1 20010405 on minor 0
cmpci: version $Revision: 5.64 $ time 01:44:41 Dec 19 2002
cmpci: found CM8738 adapter at io 0xe800 irq 16
cmpci: chip version = 055
usb.c: registered new driver hub
uhci.c: USB Universal Host Controller Interface driver v1.1
uhci.c: USB UHCI at I/O 0xe400, IRQ 21
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
uhci.c: USB UHCI at I/O 0xe000, IRQ 21
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
uhci.c: USB UHCI at I/O 0xdc00, IRQ 21
usb.c: new USB bus registered, assigned bus number 3
hub.c: USB hub found
hub.c: 2 ports detected
usb.c: registered new driver hid
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
hid-core.c: USB HID support drivers
mice: PS/2 mouse device common for all mice
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 104k freed
hub.c: new USB device 00:10.2-2, assigned address 2
usb.c: USB device 2 (vend/prod 0x4a9/0x220d) is not claimed by any active driver.
Adding Swap: 240964k swap-space (priority -1)
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,3), internal journal
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 45e1.
If you need more information, do not hesisate to write to me.
Regards,
PS: please keep me CC'ed as I am not subscribed
--
Guillaume Morin <guillaume@morinfr.org>
Je préfère à l'ennui, m'endormir pour toujours (FFF)
^ 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.