Hello ...
Linux version 2.5.70-bk15 (root@macbeth) (gcc version 3.3 (Debian)) #9 SMP Tue Jun 10 15:25:41 CEST 2003
Video mode to be used for restore is f00
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000c000000 (usable)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
192MB LOWMEM available.
found SMP MP-table at 000f5620
hm, page 000f5000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f1000 reserved twice.
hm, page 000f2000 reserved twice.
On node 0 totalpages: 49152
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 45056 pages, LIFO batch:11
HighMem zone: 0 pages, LIFO batch:1
Intel MultiProcessor Specification v1.1
Virtual Wire compatibility mode.
OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
Processor #0 6:3 APIC version 17
Processor #1 6:3 APIC version 17
I/O APIC #2 Version 17 at 0xFEC00000.
Enabling APIC mode: Flat. Using 1 I/O APICs
Processors: 2
Building zonelist for node : 0
Kernel command line: auto BOOT_IMAGE=Linux ro root=801 video=matroxfb:vesa:0x11A console=ttyS1,57600n8 console=tty0
Initializing CPU#0
PID hash table entries: 1024 (order 10: 8192 bytes)
Detected 233.923 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 459.77 BogoMIPS
Memory: 191236k/196608k available (1725k kernel code, 4712k reserved, 396k data, 340k init, 0k highmem)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (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: 512K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Checking 'hlt' instruction... OK.
POSIX conforance testing by UNIFIX
CPU0: Intel Pentium II (Klamath) stepping 04
per-CPU timelice cutoff: 1465.81 usecs.
task migration cache decay timeout: 2 msecs.
enabledExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabing vector: 00000000
Booting processor 1/1 eip 2000
Initializing CPU#1
masked ExtINT on CPU#1
ESR value before enabling ector: 00000000
ESR value after enabling vector: 00000000
Calibrating delay loo... 465.92 BogoMIPS
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
Intel machine check architecture supported.
Intel machine check reporting enabled n CPU#1.
CPU1: Intel Pentium II (Klamath) stepping 04
Total of 2 processors acivated (925.69 BogoMIPS).
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
..TIMER: vecto=0x31 pin1=2 pin2=0
testing the IO APIC.......................
................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ..
..... CPU clock speed is 233.0815 MHz.
..... host bus clock speed is 66.0804 MHz.
checking TSC synchronization across 2 CPUs: passed.
Starting migration thread for cpu 0
Bringing up 1
CPU 1 IS NOW UP!
Starting migration thread for cpu 1
CPUS done 2
mtrr: v2.0 (20020519)
mtrr: your CPUs had inconsistent fixed MTRR settings
mtrr: probably your BIOS does not setup all CPUs.
mtrr: corrected configuration.
Initializing RT netlink socket
PCI: PCI BIOS revision 2.10 entry at 0xfacd0, last bus=2
PCI: Using configuration type 1
BIO: pool of 256 setup, 14Kb (56 bytes/bio)
biovec pool[0]: 1 bvecs: 256 entries (12 bytes)
biovec pool[1]: 4 bvecs: 256 entries (48 bytes)
biovec pool[2]: 16 bvecs: 256 entries (192 bytes)
biovec pool[3]: 64 bvecs: 256 entries (768 bytes)
biovec pool[4]: 128 bvecs: 256 entries (1536 bytes)
biovec pool[5]: 256 bvecs: 256 entries (3072 bytes)
Linux Plug and Play Support v0.96 (c) Adam Belay
pty: 256 Unix98 ptys configured
block request queues:
4/128 requests per read queue
4/128 requests per write queue
enter congestion at 15
exit congestion at 17
SCSI subsystem initialized
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
00000000
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<00000000>] Not tainted
EFLAGS: 00010246
eax: 00000000 ebx: cbd93c00 ecx: 00000006 edx: cbd93dcc
esi: cbd93c00 edi: 0000102b ebp: 00000d43 esp: cbf8be68
ds: 007b es: 007b ss: 0068
Process swapper (pid: 1, threadinfo=cbf8a000 task=c11ff8c0)
Stack: c0254888 cbd93c00 0000003f cbd93c00 c01c4f7b cbd93c00 0000003f c0307f00
c01c4fa7 cbd93c00 0000003f c02466e9 cbd93c00 00000000 00000004 cbf8bea8
02900007 85d788e0 c0307fc0 ffffffed cbd93c00 00000000 c01c6222 cbd93c00
Call Trace: [<c0254888>] [<c01c4f7b>] [<c01c4fa7>] [<c02466e9>] [<c01c6222>] [<c01c63bc>] [<c01c63ff>] [<c01ee395>] [<c01ee41f>] [<c01ee5d5>] [<c01ed661>] [<c032632c>] [<c0326315>] [<c0326e22>] [<c0330cbb>] [<c0330648>] [<c031694b>] [<c012f27f>] [<c01050d8>] [<c0105080>] [<c0107229>]
Code: Bad EIP value.
<0>Kernel panic: Attempted to kill init!
ksymoops:
---------
ksymoops 2.4.8 on i686 2.5.70-bk13. Options used
-v /usr/src/linux/vmlinux (specified)
-K (specified)
-L (specified)
-o /lib/modules/2.5.70-bk15/ (specified)
-m /usr/src/linux/System.map (specified)
No modules in ksyms, skipping objects
Unable to handle kernel NULL pointer dereference at virtual address 00000000
00000000
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<00000000>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 00000000 ebx: cbd93c00 ecx: 00000006 edx: cbd93dcc
esi: cbd93c00 edi: 0000102b ebp: 00000d43 esp: cbf8be68
ds: 007b es: 007b ss: 0068
Stack: c0254888 cbd93c00 0000003f cbd93c00 c01c4f7b cbd93c00 0000003f c0307f00
c01c4fa7 cbd93c00 0000003f c02466e9 cbd93c00 00000000 00000004 cbf8bea8
02900007 85d788e0 c0307fc0 ffffffed cbd93c00 00000000 c01c6222 cbd93c00
Call Trace: [<c0254888>] [<c01c4f7b>] [<c01c4fa7>] [<c02466e9>] [<c01c6222>] [<c01c63bc>] [<c01c63ff>] [<c01ee395>] [<c01ee41f>] [<c01ee5d5>] [<c01ed661>] [<c032632c>] [<c0326315>] [<c0326e22>] [<c0330cbb>] [<c0330648>] [<c031694b>] [<c012f27f>] [<c01050d8>] [<c0105080>] [<c0107229>]
Code: Bad EIP value.
>>EIP; 00000000 Before first symbol
>>ebx; cbd93c00 <_end+b9fe068/3fc68468>
>>edx; cbd93dcc <_end+b9fe234/3fc68468>
>>esi; cbd93c00 <_end+b9fe068/3fc68468>
>>esp; cbf8be68 <_end+bbf62d0/3fc68468>
Trace; c0254888 <pcibios_enable_device+28/30>
Trace; c01c4f7b <pci_enable_device_bars+2b/40>
Trace; c01c4fa7 <pci_enable_device+17/20>
Trace; c02466e9 <matroxfb_probe+d9/2d0>
Trace; c01c6222 <pci_device_probe_static+52/70>
Trace; c01c63bc <__pci_device_probe+3c/50>
Trace; c01c63ff <pci_device_probe+2f/50>
Trace; c01ee395 <bus_match+45/80>
Trace; c01ee41f <device_attach+4f/90>
Trace; c01ee5d5 <bus_add_device+65/b0>
Trace; c01ed661 <device_add+d1/100>
Trace; c032632c <pci_bus_add_devices+ac/e0>
Trace; c0326315 <pci_bus_add_devices+95/e0>
Trace; c0326e22 <pci_scan_bus_parented+42/50>
Trace; c0330cbb <pcibios_scan_root+6b/80>
Trace; c0330648 <pci_legacy_init+38/60>
Trace; c031694b <do_initcalls+2b/a0>
Trace; c012f27f <init_workqueues+f/24>
Trace; c01050d8 <init+58/200>
Trace; c0105080 <init+0/200>
Trace; c0107229 <kernel_thread_helper+5/c>
<0>Kernel panic: Attempted to kill init!
I use a plain kernel form ftp.xx.kernel.org with the
aic79xx-linux-2.5-20030603-tar.gz package from:
http://people.FreeBSD.org/~gibbs/linux/SRC/
-> (http://marc.theaimsgroup.com/?l=linux-kernel&m=105346338023590&w=2)
mfg
boris
boris mogwitz <[email protected]> wrote:
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> ...
>
> Trace; c0254888 <pcibios_enable_device+28/30>
> Trace; c01c4f7b <pci_enable_device_bars+2b/40>
> Trace; c01c4fa7 <pci_enable_device+17/20>
> Trace; c02466e9 <matroxfb_probe+d9/2d0>
> Trace; c01c6222 <pci_device_probe_static+52/70>
> Trace; c01c63bc <__pci_device_probe+3c/50>
> Trace; c01c63ff <pci_device_probe+2f/50>
> Trace; c01ee395 <bus_match+45/80>
> Trace; c01ee41f <device_attach+4f/90>
> Trace; c01ee5d5 <bus_add_device+65/b0>
> Trace; c01ed661 <device_add+d1/100>
> Trace; c032632c <pci_bus_add_devices+ac/e0>
> Trace; c0326315 <pci_bus_add_devices+95/e0>
> Trace; c0326e22 <pci_scan_bus_parented+42/50>
> Trace; c0330cbb <pcibios_scan_root+6b/80>
> Trace; c0330648 <pci_legacy_init+38/60>
> Trace; c031694b <do_initcalls+2b/a0>
> Trace; c012f27f <init_workqueues+f/24>
> Trace; c01050d8 <init+58/200>
> Trace; c0105080 <init+0/200>
> Trace; c0107229 <kernel_thread_helper+5/c>
pcibios_irq_init() _must_ run before pcibios_enable_device(). But they are
both at subsys_initcall(), so we are at the mercy of link order, which
appears to be incorrect.
Does this fix it?
diff -puN arch/i386/pci/irq.c~pci-init-ordering-fix arch/i386/pci/irq.c
--- 25/arch/i386/pci/irq.c~pci-init-ordering-fix Tue Jun 10 14:29:40 2003
+++ 25-akpm/arch/i386/pci/irq.c Tue Jun 10 14:29:40 2003
@@ -791,7 +791,7 @@ static int __init pcibios_irq_init(void)
return 0;
}
-subsys_initcall(pcibios_irq_init);
+arch_initcall(pcibios_irq_init);
void pcibios_penalize_isa_irq(int irq)
_
Andrew Morton <[email protected]> wrote:
>
> boris mogwitz <[email protected]> wrote:
> >
> > Unable to handle kernel NULL pointer dereference at virtual address 00000000
> > ...
> >
> > Trace; c0254888 <pcibios_enable_device+28/30>
> > Trace; c01c4f7b <pci_enable_device_bars+2b/40>
> > Trace; c01c4fa7 <pci_enable_device+17/20>
> > Trace; c02466e9 <matroxfb_probe+d9/2d0>
> > Trace; c01c6222 <pci_device_probe_static+52/70>
> > Trace; c01c63bc <__pci_device_probe+3c/50>
> > Trace; c01c63ff <pci_device_probe+2f/50>
> > Trace; c01ee395 <bus_match+45/80>
> > Trace; c01ee41f <device_attach+4f/90>
> > Trace; c01ee5d5 <bus_add_device+65/b0>
> > Trace; c01ed661 <device_add+d1/100>
> > Trace; c032632c <pci_bus_add_devices+ac/e0>
> > Trace; c0326315 <pci_bus_add_devices+95/e0>
> > Trace; c0326e22 <pci_scan_bus_parented+42/50>
> > Trace; c0330cbb <pcibios_scan_root+6b/80>
> > Trace; c0330648 <pci_legacy_init+38/60>
> > Trace; c031694b <do_initcalls+2b/a0>
> > Trace; c012f27f <init_workqueues+f/24>
> > Trace; c01050d8 <init+58/200>
> > Trace; c0105080 <init+0/200>
> > Trace; c0107229 <kernel_thread_helper+5/c>
>
> pcibios_irq_init() _must_ run before pcibios_enable_device(). But they are
> both at subsys_initcall(), so we are at the mercy of link order, which
> appears to be incorrect.
It's worse than that.
> Does this fix it?
It won't.
Look,
pci_legacy_init() sets pci_root_bus
pcibios_irq_init() calls pirq_peer_trick(), which uses pci_root_bus
Hence: pci_legacy_init() must come before pcibios_irq_init()
pcibios_irq_init() sets pcibios_enable_irq
pci_legacy_init() calls into drivers, which call pcibios_enable_device(),
which uses pcibios_enable_irq
Hence: pci_legacy_init() must come _after_ pcibios_irq_init()
uh-oh.
(and pci_direct_init() and pci_pcbios_init() need to come before
pci_legacy_init(), because pci_legacy_init() needs pci_root_ops)
For some reason, the below patch stops the oopses. Not sure why.
Greg, do you have time/inclination to untangle (and preferably document)
this mess?
diff -puN arch/i386/pci/irq.c~pci-init-ordering-fix arch/i386/pci/irq.c
--- 25/arch/i386/pci/irq.c~pci-init-ordering-fix Tue Jun 10 15:40:19 2003
+++ 25-akpm/arch/i386/pci/irq.c Tue Jun 10 15:40:19 2003
@@ -791,7 +791,7 @@ static int __init pcibios_irq_init(void)
return 0;
}
-subsys_initcall(pcibios_irq_init);
+arch_initcall(pcibios_irq_init);
void pcibios_penalize_isa_irq(int irq)
diff -puN arch/i386/pci/legacy.c~pci-init-ordering-fix arch/i386/pci/legacy.c
--- 25/arch/i386/pci/legacy.c~pci-init-ordering-fix Tue Jun 10 15:46:35 2003
+++ 25-akpm/arch/i386/pci/legacy.c Tue Jun 10 15:46:47 2003
@@ -65,4 +65,4 @@ static int __init pci_legacy_init(void)
return 0;
}
-subsys_initcall(pci_legacy_init);
+arch_initcall(pci_legacy_init);
_
On Tue, Jun 10, 2003 at 04:51:11PM -0700, Andrew Morton wrote:
>
> Greg, do you have time/inclination to untangle (and preferably document)
> this mess?
Ugh, what a mess. Hm, no I don't really have the time right now to do
this, but possibly will after the rest of the pci changes are done...
As for documenting, why? It's an arch specific thing that really does
not get touched very often, if at all.
thanks,
greg k-h
Greg KH <[email protected]> wrote:
>
> On Tue, Jun 10, 2003 at 04:51:11PM -0700, Andrew Morton wrote:
> >
> > Greg, do you have time/inclination to untangle (and preferably document)
> > this mess?
>
> Ugh, what a mess. Hm, no I don't really have the time right now to do
> this, but possibly will after the rest of the pci changes are done...
Thanks.
> As for documenting, why? It's an arch specific thing that really does
> not get touched very often, if at all.
a) so you can convince yourself that it's right
b) so someone else has a chance of modifying it later without it
exploding subtly in someone else's face.