Re: kernel trap 12

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:The device_printf() was something I didn't try yet.  Combined with BUS_DEBUG
:still in my kernel it yields:
:
:devclass_find_internal:115: looking for nexus
:devclass_add_device:404: (null) in devclass nexus
:devclass_alloc_unit:353: unit 0 in devclass nexus
:devclass_alloc_unit:393: now: unit 0 in devclass nexus
:root_bus_configure:2309: .
:devclass_find_driver_internal:253: nexus in devclass root
:device_probe_child:641: Trying nexus
:nexus0: nexus_probe()
:
:After that it kernel trap 12's.
:
:-- 
:Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono

    If it's printing nexus_probe() but not printing "generic probe of..."
    then it must by dying in the TAILQ_FOREACH() in bus_generic_probe().

/*
 * Call DEVICE_IDENTIFY for each driver.
 */
int
bus_generic_probe(device_t dev)
{
        devclass_t dc = dev->devclass;
        driverlink_t dl;
 
        TAILQ_FOREACH(dl, &dc->drivers, link) {
                printf("generic probe of driverlink %p\n", dl);
		...
	}
	...
}

    Which means that 'dc' is likely NULL, which could possibly have
    produced by your other comment:

:Is devclass_add_device:404: (null) in devclass nexus legal?
:
:*writing down the offsets and such now*
:
:--
:Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono

    This is worth a shot.  Try adding a KKASSERT() after that
    PDEBUG line (line 404 in kern/subr_bus.c) so we can hopefully get
    a backtrace of who called devclass_add_device() with a dev that
    has a NULL name.  If the dev has a NJULL name then it might have a
    NULL devclass too.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>