[2.5.19] Oops during PCI scan on Alpha

[2.5.19] Oops during PCI scan on Alpha

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 4935 bytes --]

Hi!

I'm getting this Oops on my Alpha (Avanti aka AlphaStation 255/300) on
startup:


ksymoops 2.4.5 on alpha 2.2.20.  Options used
     -v /boot/vmlinux-2.5.19--02debug (specified)
     -K (specified)
     -L (specified)
     -o /lib/modules/2.5.19/ (specified)
     -m /boot/System.map-2.5.19--02debug (specified)

No modules in ksyms, skipping objects
Kernel bug at /usr/src/packages/linux-2.5.19/include/linux/device.h:78
swapper(1): Kernel Bug 1
pc = [<fffffc00003cb0cc>]  ra = [<fffffc00003c9f04>]  ps = 0000    Not tainted
Using defaults from ksymoops -t elf64-alpha -a alpha
v0 = 0000000000000000  t0 = 0000000000000000  t1 = fffffc000050e628
t2 = fffffc000050e628  t3 = 0000000000000000  t4 = ffffffff00000000
t5 = 0000000000000001  t6 = fffffc0007f403a0  t7 = fffffc0007f58000
a0 = fffffc0000696878  a1 = 0000000000000000  a2 = 0000000000000000
a3 = 0000000000000000  a4 = fffffffffffffffe  a5 = 0000000000000001
t8 = fffffc0000506ad0  t9 = 0000000000002000  t10= 0000000000008000
t11= 0000000000008000  pv = fffffc00003cb0a0  at = fffffc0000509318
gp = fffffc0000549868  sp = fffffc0007f5b7a0
Trace:fffffc00003c9f04 fffffc00003c4e18 fffffc00003c4f0c fffffc00003c5060 fffffc00003c53a0 fffffc00003100f8 fffffc0000310748 fffffc0000324448 fffffc00003100a8 fffffc00003100e0 fffffc0000310730 
Code: e460001a  47e30402  2ffe0000  a022000c  f4200006  00000081 <0000004e> 004ea5a0 


>>RA;  fffffc00003c9f04 <device_register+144/1c0>

>>PC;  fffffc00003cb0cc <bus_add_device+2c/a0>   <=====

Trace; fffffc00003c9f04 <device_register+144/1c0>
Trace; fffffc00003c4e18 <pci_scan_device+118/160>
Trace; fffffc00003c4f0c <pci_scan_slot+ac/180>
Trace; fffffc00003c5060 <pci_do_scan_bus+80/140>
Trace; fffffc00003c53a0 <pci_scan_bus+40/80>
Trace; fffffc00003100f8 <init+18/200>
Trace; fffffc0000310748 <kernel_thread+28/90>
Trace; fffffc0000324448 <printk+228/280>
Trace; fffffc00003100a8 <rest_init+28/60>
Trace; fffffc00003100e0 <init+0/200>
Trace; fffffc0000310730 <kernel_thread+10/90>

Code;  fffffc00003cb0b4 <bus_add_device+14/a0>
0000000000000000 <_PC>:
Code;  fffffc00003cb0b4 <bus_add_device+14/a0>
   0:   1a 00 60 e4       beq  t2,6c <_PC+0x6c> fffffc00003cb120 <bus_add_device+80/a0>
Code;  fffffc00003cb0b8 <bus_add_device+18/a0>
   4:   02 04 e3 47       mov  t2,t1
Code;  fffffc00003cb0bc <bus_add_device+1c/a0>
   8:   00 00 fe 2f       unop 
Code;  fffffc00003cb0c0 <bus_add_device+20/a0>
   c:   0c 00 22 a0       ldl  t0,12(t1)
Code;  fffffc00003cb0c4 <bus_add_device+24/a0>
  10:   06 00 20 f4       bne  t0,2c <_PC+0x2c> fffffc00003cb0e0 <bus_add_device+40/a0>
Code;  fffffc00003cb0c8 <bus_add_device+28/a0>
  14:   81 00 00 00       call_pal     0x81
Code;  fffffc00003cb0cc <bus_add_device+2c/a0>   <=====
  18:   4e 00 00 00       call_pal     0x4e   <=====
Code;  fffffc00003cb0d0 <bus_add_device+30/a0>
  1c:   a0 a5 4e 00       call_pal     0x4ea5a0

Kernel panic: Attempted to kill init!

While running 2.2.20, I can get these informations from lspci:


00:06.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly NCR) 53c810 (rev 11)
	Flags: bus master, medium devsel, latency 255, IRQ 11
	I/O ports at 8000
	Memory at 0000000004200000 (32-bit, non-prefetchable)
00: 00 10 01 00 47 00 00 02 11 00 00 01 00 ff 00 00
10: 01 80 00 00 00 00 20 04 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 08 40

00:07.0 Non-VGA unclassified device: Intel Corp. 82378IB [SIO ISA Bridge] (rev 43)
	Flags: bus master, medium devsel, latency 0
00: 86 80 84 04 07 00 00 02 43 00 00 00 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:0d.0 VGA compatible controller: Digital Equipment Corporation PBXGB [TGA2] (rev 22) (prog-if 00 [VGA])
	Flags: bus master, medium devsel, latency 255, IRQ 10
	Memory at 0000000005000000 (32-bit, prefetchable)
	Expansion ROM at 00000000000c0000 [disabled]
00: 11 10 0d 00 47 00 80 82 22 00 00 03 00 ff 00 00
10: 08 00 00 05 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 01 00 0c 00 00 00 00 00 00 00 00 00 0a 01 08 40

00:0e.0 Ethernet controller: Digital Equipment Corporation DECchip 21040 [Tulip] (rev 26)
	Flags: bus master, medium devsel, latency 255, IRQ 15
	I/O ports at 8800
	Memory at 0000000006000000 (32-bit, non-prefetchable)
00: 11 10 02 00 47 00 80 02 26 00 00 02 00 ff 00 00
10: 01 88 00 00 00 00 00 06 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0f 01 00 00

Any help here?

MfG, JBG

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [2.5.19] Oops during PCI scan on Alpha

[Anton Blanchard]

 
> Trace; fffffc00003c9f04 <device_register+144/1c0>
> Trace; fffffc00003c4e18 <pci_scan_device+118/160>
> Trace; fffffc00003c4f0c <pci_scan_slot+ac/180>
> Trace; fffffc00003c5060 <pci_do_scan_bus+80/140>
> Trace; fffffc00003c53a0 <pci_scan_bus+40/80>
> Trace; fffffc00003100f8 <init+18/200>
> Trace; fffffc0000310748 <kernel_thread+28/90>
> Trace; fffffc0000324448 <printk+228/280>
> Trace; fffffc00003100a8 <rest_init+28/60>
> Trace; fffffc00003100e0 <init+0/200>
> Trace; fffffc0000310730 <kernel_thread+10/90>

On ppc64 I found that pcibios_init was being called before
pci_driver_init, maybe its happening on alpha too. I am using the
following hack for the moment, I'll leave it to Patrick to fix it properly.

Anton

===== drivers/pci/pci-driver.c 1.10 vs edited =====
--- 1.10/drivers/pci/pci-driver.c	Fri May 31 06:10:44 2002
+++ edited/drivers/pci/pci-driver.c	Sat Jun  1 09:46:37 2002
@@ -192,7 +192,7 @@
 	return bus_register(&pci_bus_type);
 }
 
-subsys_initcall(pci_driver_init);
+arch_initcall(pci_driver_init);
 
 EXPORT_SYMBOL(pci_match_device);
 EXPORT_SYMBOL(pci_register_driver);

Re: [2.5.19] Oops during PCI scan on Alpha

[David S. Miller]

   From: Anton Blanchard <anton@samba.org>
   Date: Mon, 3 Jun 2002 14:27:27 +1000
   
   On ppc64 I found that pcibios_init was being called before
   pci_driver_init, maybe its happening on alpha too. I am using the
   following hack for the moment, I'll leave it to Patrick to fix it properly.
   
It's happening on every platform.  It should be done before
arch_initcalls actually, but after core_initcalls.  I would suggest to
rename unused_initcall into postcore_iniscall, then use it for this
and sys_bus_init which has the same problem.

Re: [2.5.19] Oops during PCI scan on Alpha

[Patrick Mochel]

On Sun, 2 Jun 2002, David S. Miller wrote:

>    From: Anton Blanchard <anton@samba.org>
>    Date: Mon, 3 Jun 2002 14:27:27 +1000
>    
>    On ppc64 I found that pcibios_init was being called before
>    pci_driver_init, maybe its happening on alpha too. I am using the
>    following hack for the moment, I'll leave it to Patrick to fix it properly.
>    
> It's happening on every platform.  It should be done before
> arch_initcalls actually, but after core_initcalls.  I would suggest to
> rename unused_initcall into postcore_iniscall, then use it for this
> and sys_bus_init which has the same problem.

Can't it go the other way? Instead of mass-promotion of the setup 
functions, can't we demote the ones that are causing the problems? 

The initcalls levels were determined by looking at the explicit calls in
init/main.c. Recall that they were:

early_arch
mem
subsys
arch
fs
device
late

with the default being device_initcall. I initially thought that most
things in init/main.c could become initcalls. But, I failed to realize
that init is started before the initcalls are done (duh). (Most things in 
start_kernel() could become initcalls also, but it would require a 
separate initcall section).

Sometime in March, the ACPI people promoted their initialization above 
the initialization of the device model core. This caused a few things to 
fail, and Linus changed the initcall levels to what we have today:

core
unused
arch
subsys
fs
device
late

core is used for what's in drivers/base/*.c. unused is unused. 

arch can be used for arch- and platform-specific initialization. For PCI 
on x86, these determine things like the config space access method. 

subsys is intended primarily for initializing and advertising the 
existence of bus types and device class types (network, input, etc). 
Device probing doesn't necessarily have to take place here, and in some 
cases, it can't: e.g. when the firmware is used to inform the system of 
the PCI buses present.

Theoretically, we should be able to demote bus probing until after 
subsys_initcall. Right? By making them device_initcalls and relying on 
link order, we can guarantee that buses get probed before drivers are 
initialized and start looking for devices they support. (Or, we could make 
a driver_initcall just for drivers; or a bus_initcall for probing buses.)

Thoughts?

	-pat

Re: [2.5.19] Oops during PCI scan on Alpha

[Ivan Kokshaysky]

On Tue, Jun 04, 2002 at 08:50:11AM -0700, Patrick Mochel wrote:
> On Sun, 2 Jun 2002, David S. Miller wrote:
> > It's happening on every platform.  It should be done before
> > arch_initcalls actually, but after core_initcalls.  I would suggest to
> > rename unused_initcall into postcore_iniscall, then use it for this
> > and sys_bus_init which has the same problem.
> 
> Can't it go the other way? Instead of mass-promotion of the setup 
> functions, can't we demote the ones that are causing the problems? 

Agreed, but converting everything into initcalls without any good reason
looks like a bad idea either.
 
> core is used for what's in drivers/base/*.c. unused is unused.

So subsys_initcall(sys_bus_init) in base/sys.c should be
core_initcall(sys_bus_init), right? :-)

> subsys is intended primarily for initializing and advertising the 
> existence of bus types and device class types (network, input, etc). 
> Device probing doesn't necessarily have to take place here, and in some 
> cases, it can't: e.g. when the firmware is used to inform the system of 
> the PCI buses present.

pcibios_init on alpha and some other archs is a lot more than just
device probing. Basically it's a firmware, and we want it to be
executed early.
The PCI _is_ a subsystem, and pci_driver_init() as the part of the
subsystem should be called from inside of it - pci_allocate_primary_bus()
seems to be a proper place. What about following patch?

Ivan.

--- linux/drivers/base/sys.c~	Mon Jun  3 05:44:37 2002
+++ linux/drivers/base/sys.c	Tue Jun  4 16:09:16 2002
@@ -44,6 +44,6 @@ static int sys_bus_init(void)
        return device_register(&system_bus);
 }
 
-subsys_initcall(sys_bus_init);
+core_initcall(sys_bus_init);
 EXPORT_SYMBOL(register_sys_device);
 EXPORT_SYMBOL(unregister_sys_device);
--- linux/drivers/base/Makefile~	Mon Jun  3 05:44:45 2002
+++ linux/drivers/base/Makefile	Tue Jun  4 16:14:36 2002
@@ -1,6 +1,6 @@
 # Makefile for the Linux device tree
 
-obj-y		:= core.o sys.o interface.o fs.o power.o bus.o \
+obj-y		:= core.o interface.o fs.o power.o bus.o sys.o \
 			driver.o 
 
 export-objs	:= core.o fs.o power.o sys.o bus.o driver.o
--- linux/drivers/pci/pci-driver.c~	Tue Jun  4 15:35:54 2002
+++ linux/drivers/pci/pci-driver.c	Tue Jun  4 16:23:10 2002
@@ -199,13 +199,6 @@ struct bus_type pci_bus_type = {
 	bind:	pci_bus_bind,
 };
 
-static int __init pci_driver_init(void)
-{
-	return bus_register(&pci_bus_type);
-}
-
-subsys_initcall(pci_driver_init);
-
 EXPORT_SYMBOL(pci_match_device);
 EXPORT_SYMBOL(pci_register_driver);
 EXPORT_SYMBOL(pci_unregister_driver);
--- linux/drivers/pci/probe.c~	Mon Jun  3 05:44:42 2002
+++ linux/drivers/pci/probe.c	Tue Jun  4 16:24:55 2002
@@ -563,6 +563,9 @@ struct pci_bus * __devinit pci_alloc_pri
 		return NULL;
 	}
 
+	if (!atomic_read(&pci_bus_type.refcount))
+		bus_register(&pci_bus_type);
+
 	b = pci_alloc_bus();
 	if (!b)
 		return NULL;

Re: [2.5.19] Oops during PCI scan on Alpha

[Patrick Mochel]

> > Can't it go the other way? Instead of mass-promotion of the setup 
> > functions, can't we demote the ones that are causing the problems? 
> 
> Agreed, but converting everything into initcalls without any good reason
> looks like a bad idea either.

True, but IMO, there are good reasons for converting these to initcalls. 

> > core is used for what's in drivers/base/*.c. unused is unused.
> 
> So subsys_initcall(sys_bus_init) in base/sys.c should be
> core_initcall(sys_bus_init), right? :-)

No. The system "bus" is a subsystem, not a piece of the infrastructure. 
It's a pseudo-bus that provides a parent for system devices (since they 
otherwise appear as floating, autonomous beings).

> > subsys is intended primarily for initializing and advertising the 
> > existence of bus types and device class types (network, input, etc). 
> > Device probing doesn't necessarily have to take place here, and in some 
> > cases, it can't: e.g. when the firmware is used to inform the system of 
> > the PCI buses present.
> 
> pcibios_init on alpha and some other archs is a lot more than just
> device probing. Basically it's a firmware, and we want it to be
> executed early.

Sure. x86 is similar, to an extent. OWOA, there is a distinction between 
the initialization and the actual probing. And, it appears that alpha 
already has that. It appears that most of the alpha platforms use 
common_init_pci() for their init_pci entry point. A few more use 
cia_init_pci() for init_pci. The rest define their own (except the 
jensen, which is NULL). 

cia_init_pci does this: 

        verify_tb_operation();
        common_init_pci();

All the platforms that define their own init_pci callbacks either call 
common_init_pci() or cia_init_pci() before doing anything else. 

My point is that the only thing pcibios_init() appears to be doing on 
alpha is probing the bus. Whatever firmware black magic that must take 
place appears to either not exist, or have already been done by that 
point. 

I'm not going to try and force you to use a device_initcall. But, it 
appears that it will work, and it fits the nomenclature. 

	-pat

Re: [2.5.19] Oops during PCI scan on Alpha

[Benjamin Herrenschmidt]

>I'm not going to try and force you to use a device_initcall. But, it 
>appears that it will work, and it fits the nomenclature. 

Well, one problem I have with PCI probing beeing done that late
on PPC is that I need pcibios_init() to setup a few things, like
conversion tables between bus numbers, that has to be done before
devices are inited, and that need the bus to be probed as the
bus numbers can be reassigned at that point.

There are also other issues related to some of the "combo" ASICs
we have on pmac (and maybe other embedded platforms). Those aren't
currently probed using the PCI probe code, but rather (on pmac
at least), using the firmware device-tree so we can probe for
individual cells in these ASICs regardless of the actual PCI
device embedding the cells we care about.

However, this leads to a few issues: If we request resources for
these cells, the PCI bus must have been probed first or the resources
won't be properly be assigned as child of the correct ASIC pci_dev.
Also, some cells need to get to the pci_dev of their parent ASIC for
other reasons, and that also require the pci bus to have been probed
before those devices are inited.

Finally, add to that mix that some of the devices in those ASICs
are critical for the kernel early (like the PIC, timers used for
calibration or power management unit), so they must be probed
early. pffff...

So currently, device_initcall may work for pcibios_init on PPC
only because Makefile magic will cause arch/ppc/* stuff to be
called before other drivers. But that's not something I like ;)

I have plans to convert most of these drivers to something saner
for 2.5 around your new device model, probably some kind of
macio_device shell (for a device within a mac-io ASIC), the ASIC
itself acting like a PCI<->mac-io bridge.
I'll have to keep a few special cases for things like the PIC, but
there's nothing much we can do about that.

That's among the things we need to discuss at Ottawa ;)

Ben.

Re: [2.5.19] Oops during PCI scan on Alpha

[Ivan Kokshaysky]

On Tue, Jun 04, 2002 at 11:58:39AM -0700, Patrick Mochel wrote:
> My point is that the only thing pcibios_init() appears to be doing on 
> alpha is probing the bus.

No. Look at pci_assign_unassigned_resources() in drivers/pci/setup-bus.c.
Setting the BARs, initializing bridges etc. That's that i386 expects
to be done in BIOS.

Ivan.

Re: [2.5.19] Oops during PCI scan on Alpha

[David S. Miller]

   From: Patrick Mochel <mochel@osdl.org>
   Date: Tue, 4 Jun 2002 08:50:11 -0700 (PDT)

   On Sun, 2 Jun 2002, David S. Miller wrote:
   
   > It's happening on every platform.  It should be done before
   > arch_initcalls actually, but after core_initcalls.  I would suggest to
   > rename unused_initcall into postcore_iniscall, then use it for this
   > and sys_bus_init which has the same problem.
   
   Can't it go the other way? Instead of mass-promotion of the setup 
   functions, can't we demote the ones that are causing the problems? 
   
There's this middle area between core and subsys, why not
just be explicit about it's existence?

Short of making the true dependencies describable, I think my
postcore_initcall solution is fine.

Re: [2.5.19] Oops during PCI scan on Alpha

[Patrick Mochel]

On Tue, 4 Jun 2002, David S. Miller wrote:

>    From: Patrick Mochel <mochel@osdl.org>
>    Date: Tue, 4 Jun 2002 08:50:11 -0700 (PDT)
> 
>    On Sun, 2 Jun 2002, David S. Miller wrote:
>    
>    > It's happening on every platform.  It should be done before
>    > arch_initcalls actually, but after core_initcalls.  I would suggest to
>    > rename unused_initcall into postcore_iniscall, then use it for this
>    > and sys_bus_init which has the same problem.
>    
>    Can't it go the other way? Instead of mass-promotion of the setup 
>    functions, can't we demote the ones that are causing the problems? 
>    
> There's this middle area between core and subsys, why not
> just be explicit about it's existence?
> 
> Short of making the true dependencies describable, I think my
> postcore_initcall solution is fine.

What sense is there in naming it postcore_initcall? What does it tell you 
about the intent of the function? 

The problem is that if we have arbitrary names with arbitrary priority 
levels, people will think they're more important than most, if not all, of 
the other initcall users and leapfrog over them into earlier levels. It's 
already happened at least once, and I expect to happen more. 

The initcall levels are not a means to bypass true dependency resolution. 
They're an alternative means to solving some of the dependency problems 
without having a ton of #ifdefs and hardcoded, explicit calls to 
initialization routines. 

We can add more levels and change names. But, we should make them 
meaningful for at least two reasons:

- It's obvious to people who are using them what they should use
- It's obvious to someone looking at the code when it gets initialized

That said, how about doing this:

- core
- subsys
- arch
- driver

core initializes the core, as always.

subsys initializes bus and device class subsystems and registers them with 
the core.

arch does arch- and platform- specific initlization. arch_initcalls 
appear only in arch/ subdirectories, and they happen after 
subsys_initcalls. 

driver initializes all the device drivers compiled in. 

	-pat

Re: [2.5.19] Oops during PCI scan on Alpha

[David S. Miller]

   From: Patrick Mochel <mochel@osdl.org>
   Date: Tue, 4 Jun 2002 12:38:06 -0700 (PDT)

   
   > There's this middle area between core and subsys, why not
   > just be explicit about it's existence?
   > 
   > Short of making the true dependencies describable, I think my
   > postcore_initcall solution is fine.
   
   What sense is there in naming it postcore_initcall? What does it tell you 
   about the intent of the function? 
   
It says "this has to be initialized, but after core initcalls because
it expects core to be setup."  That's what "postcore" means. :-)

   The initcall levels are not a means to bypass true dependency resolution. 
   They're an alternative means to solving some of the dependency problems 
   without having a ton of #ifdefs and hardcoded, explicit calls to 
   initialization routines. 
   
I added no ifdefs, what are you talking about.

   We can add more levels and change names. But, we should make them 
   meaningful for at least two reasons:
   
   - It's obvious to people who are using them what they should use
   - It's obvious to someone looking at the code when it gets initialized
   
How much more meaning do you want than "this requires core to be
setup"  That describes a lot to me.

   That said, how about doing this:
   
   - core

+- postcore

   - subsys
   - arch
   - driver
   
   core initializes the core, as always.
   
   subsys initializes bus and device class subsystems and registers them with 
   the core.
   
But there are things between subsys and core as demonstrated by the
very bug we are trying to fix right now.

You people are blowing this shit WAY out of proportion.  Just fix the
bug now and reinplement the initcall hierarchy in a seperate changeset
so people can actually get work done in the 2.5.x tree while you do
that ok?

Re: [2.5.19] Oops during PCI scan on Alpha

[Tom Rini]

On Tue, Jun 04, 2002 at 12:42:41PM -0700, David S. Miller wrote:
>    From: Patrick Mochel <mochel@osdl.org>
>    Date: Tue, 4 Jun 2002 12:38:06 -0700 (PDT)
> 
>    
>    > There's this middle area between core and subsys, why not
>    > just be explicit about it's existence?
>    > 
>    > Short of making the true dependencies describable, I think my
>    > postcore_initcall solution is fine.
>    
>    What sense is there in naming it postcore_initcall? What does it tell you 
>    about the intent of the function? 
>    
> It says "this has to be initialized, but after core initcalls because
> it expects core to be setup."  That's what "postcore" means. :-)
> 
>    The initcall levels are not a means to bypass true dependency resolution. 
>    They're an alternative means to solving some of the dependency problems 
>    without having a ton of #ifdefs and hardcoded, explicit calls to 
>    initialization routines. 
>    
> I added no ifdefs, what are you talking about.

I think the ifdefs referred to any of the more complex, but also
arguably more correct ideas (ie things which actually do real
dependancies).  Or maybe hard-coding the corner cases and keeping the
current solution.

> You people are blowing this shit WAY out of proportion.  Just fix the
> bug now and reinplement the initcall hierarchy in a seperate changeset
> so people can actually get work done in the 2.5.x tree while you do
> that ok?

heh.  Or implement some sort of proper dependancies to it all as well.
:)

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: [2.5.19] Oops during PCI scan on Alpha

[Patrick Mochel]

> It says "this has to be initialized, but after core initcalls because
> it expects core to be setup."  That's what "postcore" means. :-)

Oh right; silly me. 

>    The initcall levels are not a means to bypass true dependency resolution. 
>    They're an alternative means to solving some of the dependency problems 
>    without having a ton of #ifdefs and hardcoded, explicit calls to 
>    initialization routines. 
>    
> I added no ifdefs, what are you talking about.

I was referring to the original motivation of the patch: what 
init/main.c::do_basic_setup() and arch/i386/kernel/pci-pc.c used to look 
like. 

> How much more meaning do you want than "this requires core to be
> setup"  That describes a lot to me.

Because it describes every initcall. But, whatever. Let me ask this 
instead: is there a better way to specify dependencies between components? 

> You people are blowing this shit WAY out of proportion.  Just fix the
> bug now and reinplement the initcall hierarchy in a seperate changeset
> so people can actually get work done in the 2.5.x tree while you do
> that ok?

Fine. Use Ivan's; it's appended below, and will be in BK soon. 

	-pat

--- linux/drivers/base/sys.c~	Mon Jun  3 05:44:37 2002
+++ linux/drivers/base/sys.c	Tue Jun  4 16:09:16 2002
@@ -44,6 +44,6 @@ static int sys_bus_init(void)
        return device_register(&system_bus);
 }
 
-subsys_initcall(sys_bus_init);
+core_initcall(sys_bus_init);
 EXPORT_SYMBOL(register_sys_device);
 EXPORT_SYMBOL(unregister_sys_device);
--- linux/drivers/base/Makefile~	Mon Jun  3 05:44:45 2002
+++ linux/drivers/base/Makefile	Tue Jun  4 16:14:36 2002
@@ -1,6 +1,6 @@
 # Makefile for the Linux device tree
 
-obj-y		:= core.o sys.o interface.o fs.o power.o bus.o \
+obj-y		:= core.o interface.o fs.o power.o bus.o sys.o \
 			driver.o 
 
 export-objs	:= core.o fs.o power.o sys.o bus.o driver.o
--- linux/drivers/pci/pci-driver.c~	Tue Jun  4 15:35:54 2002
+++ linux/drivers/pci/pci-driver.c	Tue Jun  4 16:23:10 2002
@@ -199,13 +199,6 @@ struct bus_type pci_bus_type = {
 	bind:	pci_bus_bind,
 };
 
-static int __init pci_driver_init(void)
-{
-	return bus_register(&pci_bus_type);
-}
-
-subsys_initcall(pci_driver_init);
-
 EXPORT_SYMBOL(pci_match_device);
 EXPORT_SYMBOL(pci_register_driver);
 EXPORT_SYMBOL(pci_unregister_driver);
--- linux/drivers/pci/probe.c~	Mon Jun  3 05:44:42 2002
+++ linux/drivers/pci/probe.c	Tue Jun  4 16:24:55 2002
@@ -563,6 +563,9 @@ struct pci_bus * __devinit pci_alloc_pri
 		return NULL;
 	}
 
+	if (!atomic_read(&pci_bus_type.refcount))
+		bus_register(&pci_bus_type);
+
 	b = pci_alloc_bus();
 	if (!b)
 		return NULL;

Re: [2.5.19] Oops during PCI scan on Alpha

[David S. Miller]

   From: Patrick Mochel <mochel@osdl.org>
   Date: Tue, 4 Jun 2002 14:10:27 -0700 (PDT)
   
   > You people are blowing this shit WAY out of proportion.  Just fix the
   > bug now and reinplement the initcall hierarchy in a seperate changeset
   > so people can actually get work done in the 2.5.x tree while you do
   > that ok?
   
   Fine. Use Ivan's; it's appended below, and will be in BK soon. 
   
   -subsys_initcall(sys_bus_init);
   +core_initcall(sys_bus_init);

Does sys_bus_init require the generic bus layer to be initialized
first?

Re: [2.5.19] Oops during PCI scan on Alpha

[Patrick Mochel]

On Tue, 4 Jun 2002, David S. Miller wrote:

>    From: Patrick Mochel <mochel@osdl.org>
>    Date: Tue, 4 Jun 2002 14:10:27 -0700 (PDT)
>    
>    > You people are blowing this shit WAY out of proportion.  Just fix the
>    > bug now and reinplement the initcall hierarchy in a seperate changeset
>    > so people can actually get work done in the 2.5.x tree while you do
>    > that ok?
>    
>    Fine. Use Ivan's; it's appended below, and will be in BK soon. 
>    
>    -subsys_initcall(sys_bus_init);
>    +core_initcall(sys_bus_init);
> 
> Does sys_bus_init require the generic bus layer to be initialized
> first?

Yes, and it is in drivers/base/bus.c just before sys_bus_init is called.

	-pat

Re: [2.5.19] Oops during PCI scan on Alpha

[David S. Miller]

   From: Patrick Mochel <mochel@osdl.org>
   Date: Tue, 4 Jun 2002 14:14:26 -0700 (PDT)

   On Tue, 4 Jun 2002, David S. Miller wrote:
   
   > Does sys_bus_init require the generic bus layer to be initialized
   > first?
   
   Yes, and it is in drivers/base/bus.c just before sys_bus_init is called.

Linkers are allowed to reorder object files unless you tell them
explicitly not to.

This is why you need to put this stuff into a seperate initcall level.
This is precisely why I suggest postcore_initcall as the fix.

Re: [2.5.19] Oops during PCI scan on Alpha

[Patrick Mochel]

On Tue, 4 Jun 2002, David S. Miller wrote:

>    From: Patrick Mochel <mochel@osdl.org>
>    Date: Tue, 4 Jun 2002 14:14:26 -0700 (PDT)
> 
>    On Tue, 4 Jun 2002, David S. Miller wrote:
>    
>    > Does sys_bus_init require the generic bus layer to be initialized
>    > first?
>    
>    Yes, and it is in drivers/base/bus.c just before sys_bus_init is called.
> 
> Linkers are allowed to reorder object files unless you tell them
> explicitly not to.
> 
> This is why you need to put this stuff into a seperate initcall level.
> This is precisely why I suggest postcore_initcall as the fix.

Ok, how about just keeping it a subsys_initcall, like it was in the first 
place? 

	-pat

Re: [2.5.19] Oops during PCI scan on Alpha

[David S. Miller]

   From: Patrick Mochel <mochel@osdl.org>
   Date: Tue, 4 Jun 2002 14:29:21 -0700 (PDT)

   
   On Tue, 4 Jun 2002, David S. Miller wrote:
   
   > Linkers are allowed to reorder object files unless you tell them
   > explicitly not to.
   > 
   > This is why you need to put this stuff into a seperate initcall level.
   > This is precisely why I suggest postcore_initcall as the fix.
   
   Ok, how about just keeping it a subsys_initcall, like it was in the first 
   place? 

Then there are ordering problems with subsys_initcalls which want to
add devices to sys_bus.  In fact, arch_initcalls are the places where
most of the actual uses of subsys_bus registry.

So for the ump-teenth time, you need to init this thing EXACTLY after
core_initcalls.  I can only say this so many times, this is the
initcall classification we need to fix this bug, "POST CORE INITCALL"
and "BEFORE ANYTHING ELSE".

One way to do that, for the ump-teenth time, is to rename
unused_initcall to postcore_initcall and use that new initcall
to fix the pci_bus and sys_bus generic bus initialization ordering
problems.

We're talking in circles and the fixes you're proposing are not
going to fix the bug, just create new versions of the old bug.

Re: [2.5.19] Oops during PCI scan on Alpha

[Patrick Mochel]

> We're talking in circles and the fixes you're proposing are not
> going to fix the bug, just create new versions of the old bug.

Go crazy. Also available from bk://linux.bkbits.net/linux-2.5

	-pat

ChangeSet@1.418, 2002-06-04 14:58:08-07:00, mochel@osdl.org
  s/subsys_initcall/postcore_initcall/ for sys_bys and pci, so they get initialized early enough for arch and subsys initcalls to use them.
  

 drivers/base/sys.c       |    2 +-
 drivers/pci/pci-driver.c |    2 +-
 2 files changed, 2 insertions, 2 deletions


ChangeSet@1.417, 2002-06-04 14:57:10-07:00, mochel@osdl.org
  Change unused_initcall to postcore_initcall for things that must be initialized early, but not too early (after the core is done)

 include/linux/init.h |    4 ++--
 1 files changed, 2 insertions, 2 deletions


diff -Nru a/drivers/base/sys.c b/drivers/base/sys.c
--- a/drivers/base/sys.c	Tue Jun  4 15:01:14 2002
+++ b/drivers/base/sys.c	Tue Jun  4 15:01:14 2002
@@ -44,6 +44,6 @@
        return device_register(&system_bus);
 }
 
-subsys_initcall(sys_bus_init);
+postcore_initcall(sys_bus_init);
 EXPORT_SYMBOL(register_sys_device);
 EXPORT_SYMBOL(unregister_sys_device);
diff -Nru a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
--- a/drivers/pci/pci-driver.c	Tue Jun  4 15:01:14 2002
+++ b/drivers/pci/pci-driver.c	Tue Jun  4 15:01:14 2002
@@ -204,7 +204,7 @@
 	return bus_register(&pci_bus_type);
 }
 
-subsys_initcall(pci_driver_init);
+postcore_initcall(pci_driver_init);
 
 EXPORT_SYMBOL(pci_match_device);
 EXPORT_SYMBOL(pci_register_driver);
diff -Nru a/include/linux/init.h b/include/linux/init.h
--- a/include/linux/init.h	Tue Jun  4 15:01:14 2002
+++ b/include/linux/init.h	Tue Jun  4 15:01:14 2002
@@ -61,7 +61,7 @@
 	static initcall_t __initcall_##fn __attribute__ ((unused,__section__ (".initcall" level ".init"))) = fn
 
 #define core_initcall(fn)		__define_initcall("1",fn)
-#define unused_initcall(fn)		__define_initcall("2",fn)
+#define postcore_initcall(fn)		__define_initcall("2",fn)
 #define arch_initcall(fn)		__define_initcall("3",fn)
 #define subsys_initcall(fn)		__define_initcall("4",fn)
 #define fs_initcall(fn)			__define_initcall("5",fn)
@@ -160,7 +160,7 @@
 #define __setup(str,func) /* nothing */
 
 #define core_initcall(fn)		module_init(fn)
-#define unused_initcall(fn)		module_init(fn)
+#define postcore_initcall(fn)		module_init(fn)
 #define arch_initcall(fn)		module_init(fn)
 #define subsys_initcall(fn)		module_init(fn)
 #define fs_initcall(fn)			module_init(fn)

Re: [2.5.19] Oops during PCI scan on Alpha

[Patrick Mochel]

On Tue, 4 Jun 2002, Patrick Mochel wrote:

> 
> > We're talking in circles and the fixes you're proposing are not
> > going to fix the bug, just create new versions of the old bug.
> 
> Go crazy. Also available from bk://linux.bkbits.net/linux-2.5

Erm, that should be bk://ldm.bkbits.net/linux-2.5

Re: [2.5.19] Oops during PCI scan on Alpha

[Ivan Kokshaysky]

On Tue, Jun 04, 2002 at 03:03:33PM -0700, Patrick Mochel wrote:
> -subsys_initcall(pci_driver_init);
> +postcore_initcall(pci_driver_init);

Fine, but my main objection was to pci_driver_init being an initcall
in general, no matter in what level. With current code we may have
pci_bus_type registered on a machine without PCI bus.
Real life example: jensen running generic alpha kernel.

Ivan.

Re: [2.5.19] Oops during PCI scan on Alpha

[David S. Miller]

   From: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
   Date: Wed, 5 Jun 2002 18:23:16 +0400

   On Tue, Jun 04, 2002 at 03:03:33PM -0700, Patrick Mochel wrote:
   > -subsys_initcall(pci_driver_init);
   > +postcore_initcall(pci_driver_init);
   
   Fine, but my main objection was to pci_driver_init being an initcall
   in general, no matter in what level. With current code we may have
   pci_bus_type registered on a machine without PCI bus.
   Real life example: jensen running generic alpha kernel.
   
Ok, then we should have pci_driver_init called from the beginning
of pcibios_init if PCI controllers are found.

Re: [2.5.19] Oops during PCI scan on Alpha

[Patrick Mochel]

On Wed, 5 Jun 2002, Ivan Kokshaysky wrote:

> On Tue, Jun 04, 2002 at 03:03:33PM -0700, Patrick Mochel wrote:
> > -subsys_initcall(pci_driver_init);
> > +postcore_initcall(pci_driver_init);
> 
> Fine, but my main objection was to pci_driver_init being an initcall
> in general, no matter in what level. With current code we may have
> pci_bus_type registered on a machine without PCI bus.
> Real life example: jensen running generic alpha kernel.

That's fine. That's exactly the same thing that happens with device
drivers you have compiled in but don't have hardware for and have hotplug
enabled. The fact that it's registered with the system simply advertises
its support.

The fact that it's unused and just sitting there taking up space is 
distasteful, but there are things that could be done about it. For one, we 
could compile PCI as a module and include it in an initramfs image (so it 
loaded early enough to not break too many things).

Or, after we probe for everything, we could make a sweep of all the 
drivers in the system and purge any that have a refcount of 1 (registered, 
but not used by anyone).

	-pat

Re: [2.5.19] Oops during PCI scan on Alpha

[Ivan Kokshaysky]

On Wed, Jun 05, 2002 at 05:01:30PM -0700, Patrick Mochel wrote:
> > Real life example: jensen running generic alpha kernel.
> 
> That's fine. That's exactly the same thing that happens with device
> drivers you have compiled in but don't have hardware for and have hotplug
> enabled. The fact that it's registered with the system simply advertises
> its support.

Ok, this makes sense.

Ivan.

Re: [2.5.19] Oops during PCI scan on Alpha

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

On Tue, 2002-06-04 08:50:11 -0700, Patrick Mochel <mochel@osdl.org>
wrote in message <Pine.LNX.4.33.0206040821100.654-100000@geena.pdx.osdl.net>:
> On Sun, 2 Jun 2002, David S. Miller wrote:
> >    From: Anton Blanchard <anton@samba.org>
> >    Date: Mon, 3 Jun 2002 14:27:27 +1000

[Order of grouped init calls]

> early_arch
> mem
> subsys
> arch
> fs
> device
> late

Just a dumb ass question: We're currently dealing with grouped init
calls. Why don't we simply give them numbers like we do in
/etc/rc<X>.d/S<YZ>startme.sh? That would possibly give an easier
mechanism of keeping all those init calls in a sane order!?

MfG, JBG

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]