LinuxLists.cc - [2.5.19] Oops during PCI scan on Alpha

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

From: Anton Blanchard <[email protected]>
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.

2002-06-04 15:54:21

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

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

> From: Anton Blanchard <[email protected]>
> 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

2002-06-04 17:09:42

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

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;

2002-06-04 18:16:57

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

From: Patrick Mochel <[email protected]>
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.

2002-06-04 19:02:51

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

> > 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

2002-06-04 19:42:13

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

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

> From: Patrick Mochel <[email protected]>
> 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

2002-06-04 19:45:53

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

From: Patrick Mochel <[email protected]>
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?

2002-06-04 20:54:32

by Benjamin Herrenschmidt

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

>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.

2002-06-04 20:57:55

by Tom Rini

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

On Tue, Jun 04, 2002 at 12:42:41PM -0700, David S. Miller wrote:
> From: Patrick Mochel <[email protected]>
> 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/

2002-06-04 21:14:33

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

> 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;

2002-06-04 21:17:30

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

From: Patrick Mochel <[email protected]>
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?

2002-06-04 21:18:34

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

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

> From: Patrick Mochel <[email protected]>
> 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

2002-06-04 21:26:23

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

From: Patrick Mochel <[email protected]>
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.

2002-06-04 21:33:28

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

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

> From: Patrick Mochel <[email protected]>
> 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

2002-06-04 21:38:05

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

From: Patrick Mochel <[email protected]>
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.

2002-06-04 22:07:44

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

> 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

[email protected], 2002-06-04 14:58:08-07:00, [email protected]
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

[email protected], 2002-06-04 14:57:10-07:00, [email protected]
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)

2002-06-04 22:12:43

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

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

2002-06-05 14:20:55

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

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.

2002-06-05 14:23:50

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

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.

2002-06-05 22:33:51

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

From: Ivan Kokshaysky <[email protected]>
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.

2002-06-06 00:05:46

[permalink] [raw]

Subject: Re: [2.5.19] Oops during PCI scan on Alpha

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

2002-06-06 13:23:06