On Wed, 2 May 2018, Michael Schmitz wrote:
Hi Finn, this one seems to cause a regression when attempting to load the mac8390 driver on Amiga (Adrian just tried that): [ 16.360000] kernel BUG at drivers/base/driver.c:151! [ 16.370000] *** TRAP #7 *** FORMAT=0 [ 16.380000] Current process id is 1 [ 16.390000] BAD KERNEL TRAP: 00000000 [ 16.400000] Modules linked in: [ 16.410000] PC: [<001b42aa>] driver_register+0x2a/0xc6 [ 16.420000] SR: 2000 SP: (ptrval) a2: 06c1f690 [ 16.430000] d0: 00000028 d1: 00000000 d2: 0000005b d3: 00000000 [ 16.440000] d4: 00000007 d5: 0040daf0 a0: 0039917e a1: 00399182 [ 16.450000] Process swapper (pid: 1, task=(ptrval)) [ 16.460000] Frame format=0 [ 16.470000] Stack from 06c21f10: [ 16.470000] 003344c2 00358c5f 00000097 0000005b 00401436 00401442 003b3bcc 00002160 [ 16.470000] 0000005b 0029adea 00000007 0040daf0 00000000 00000000 00406a70 00406a50 [ 16.470000] 00406a50 00002106 0003fc10 0038fbcc 0000005a 00060006 005600e1 005600f4 [ 16.470000] 003eaf8e 00358ff2 00560090 0038f4c4 0000005b 00000006 00000006 00000000 [ 16.470000] 0003fc10 003eafa0 00401436 00000000 00000000 00000000 00000000 0029e9c2 [ 16.470000] 00000000 00000000 00000000 0029e9ca 0029e9c2 00002898 00000000 00000000 [ 16.480000] Call Trace: [<00401436>] mac8390_init+0x0/0x10 [ 16.490000] [<00401442>] mac8390_init+0xc/0x10 [ 16.500000] [<00002160>] do_one_initcall+0x5a/0x16a [ 16.510000] [<0029adea>] strcpy+0x0/0x18 [ 16.520000] [<00002106>] do_one_initcall+0x0/0x16a [ 16.530000] [<0003fc10>] parse_args+0x0/0x2e8 [ 16.540000] [<00060006>] do_setitimer+0xf2/0x1a2 [ 16.550000] [<003eaf8e>] kernel_init_freeable+0xe8/0x184 [ 16.560000] [<0003fc10>] parse_args+0x0/0x2e8 [ 16.570000] [<003eafa0>] kernel_init_freeable+0xfa/0x184 [ 16.580000] [<00401436>] mac8390_init+0x0/0x10 [ 16.590000] [<0029e9c2>] kernel_init+0x0/0xd2 [ 16.600000] [<0029e9ca>] kernel_init+0x8/0xd2 [ 16.610000] [<0029e9c2>] kernel_init+0x0/0xd2 [ 16.620000] [<00002898>] ret_from_kernel_thread+0xc/0x14 [ 16.630000] Code: 8c5f 4879 0033 44c2 4eb9 0004 f7d0 4e47 <4aa8> 0020 6706 4aab 001e 6618 4aa8 0024 6706 4aab 0022 660c 4aa8 0028 6716 4aab [ 16.640000] Disabling lock debugging due to kernel taint [ 16.650000] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 16.650000] [ 16.650000] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 16.650000] ]--- That's BUG_ON(!drv->bus->p); in drivers/base/driver.c:driver_register(). Just guessing from the stack trace at this point - can't see why nubus_driver_register() fails in this way. The subsys_private field is initialized by bus_register, but this might not actually run from nubus_bus_register() on non-Mac?
Right, nubus_bus_register() is not called unless MACH_IS_MAC().
I can see no safeguards against mac8390_init() being run on other m68k machines than Mac ...
I removed the MACH_IS_MAC() tests from the platform drivers because it already gates the instantiation of the corresponding platform devices, and because the MACH_IS_WHATEVER() tests are non-portable. I think the failure you describe has to do with registering a driver for a bus that's not (yet) registered. I'll try to find out how that's meant to be handled. Possibly the bus should be registered regardless of platform (given CONFIG_NUBUS).
Happens at initrd module load time so somewhat inconvenient to debug remotely :-). Did not happen on m68k v4.16rc2 earlier. We were a little slack with kernel upgrades on elgar, would have spotted that earlier otherwise.
I'm guessing that this is mainline v4.16? Sorry for the regression :( --
Cheers, Michael
-- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
