Bug 21624

	

gusc_attach() causes panic by calling device_get_parent(0)

Boot and trap messages:

unknown: <Synth & Codec> can't assign resources
gusc0: <Gravis UltraSound Plug & Play OPL> at port 0x388-0x389 irq 5 on isa0
gusc1: <Gravis UltraSound Plug & Play MIDI> at port 0x330-0x331 irq 10 on isa0

Fatal trap 12
fault virtual address = 0x8		( == 0->parent )
instruction pointer = 0x8:0xc01913d6    (in device_get_parent())
stack pointer = 0x10:0xc0458ae0
frame pointer = 0x10:0xc0458ae0
...

A hand-copied ddb trace:

device_get_parent(0)
find_masterdev(c09e4400) +0x4c
alloc_resouce(c09e4400) +0x286
gusc_attach + 0x26

I'm a little confused, since I can't actually find a call to
device_get_parent() in find_masterdev().

Fix: 

Disable "device gusc" and "device pcm" from kernel.

(Note that this card never successfully probed with 4.0:

unknown: <Synth & Codec> can't assign resources
adv1: Invalid baseport of 0x168 specified. Neerest valid baseport is 0x190.  Fai
ling probe.
unknown0: <Generic ESDI/IDE/ATA controller> at port 0x168-0x16f,0x36e-0x36f irq 
11 drq 0 on isa0
adv1: Invalid baseport of 0x201 specified. Neerest valid baseport is 0x210.  Fai
ling probe.
unknown1: <Game Port> at port 0x201 on isa0
adv1: Invalid baseport of 0x388 specified. Neerest valid baseport is 0x330.  Fai
ling probe.
unknown2: <SB Digital Audio> at port 0x388-0x389 irq 5 on isa0
unknown: <GM Music> can't assign resources

but I'm not sure that probing and then trapping is better =)
How-To-Repeat: 
	
Boot 4.1.1-STABLE with my Gravis Ultrasound Plug & Play in the machine.