recent Maestro messages.

[Pyun YongHyeon]

On Mon, Jan 02, 2006 at 10:28:56AM -0800, Julian Elischer wrote:
 > Recently the MAestro attach code has started to spew out the following 
 > during boot.
 > 
 > someone who knows pcm_addchan() should look to see it the locking in 
 > agg_attach()
 > can be adjusted to avoid this error safely.
 > 
 > =====================
 > 
 > malloc(M_WAITOK) of "256", forcing M_NOWAIT with the following 
 > non-sleepable loc
 > ks held:
 > exclusive sleep mutex ESS Technology Maestro-2E (hardware status lock) r = 
 > 0 (0x
 > c228be28) locked @ 
 > /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sou
 > nd/pci/maestro.c:270
 > KDB: stack backtrace:
 > kdb_backtrace(1,e0,c10653c0,4,c0c209ec) at kdb_backtrace+0x29
 > witness_warn(5,0,c089b071,c0840681,e0) at witness_warn+0x192
 > uma_zalloc_arg(c10653c0,0,502) at uma_zalloc_arg+0x41
 > malloc(d8,c0907860,502,c0c20a38,c062efe8) at malloc+0xb2
 > devfs_alloc(c22c3800,0,c22c3780,c0c20a60,c062f0d4) at devfs_alloc+0x17
 > make_dev_credv(c0ae0420,30004,0,0,0) at make_dev_credv+0x34
 > make_dev(c0ae0420,30004,0,0,1b6) at make_dev+0x20
 > pcm_chn_add(c228bc00,c22fad80,c228be00,0,0) at pcm_chn_add+0x14e
 > pcm_addchan(c22ba600,1,c0ac4ca0,c228be00,c228be28) at pcm_addchan+0x36
 > agg_attach(c22ba600) at agg_attach+0x553
 > device_attach(c22ba600,c22ba880,c22ba600,c22ba380,0) at device_attach+0x58
 > device_probe_and_attach(c22ba600) at device_probe_and_attach+0xe0
 > bus_generic_attach(c22ba380,6,c229d7c0,1,c0b2c39c) at 
 > bus_generic_attach+0x16
 > acpi_pci_attach(c22ba380) at acpi_pci_attach+0xd0
 > device_attach(c22ba380,c228acf0,c22ba380,0,c223ea80) at device_attach+0x58
 > device_probe_and_attach(c22ba380) at device_probe_and_attach+0xe0
 > bus_generic_attach(c223ea80,c223ea80,0,c229d7c0,c22b5480) at 
 > bus_generic_attach+
 > 0x16
 > acpi_pcib_attach(c223ea80,c22b5494,0,c0c20c58,c066e3cc) at 
 > acpi_pcib_attach+0x12
 > f
 > acpi_pcib_acpi_attach(c223ea80) at acpi_pcib_acpi_attach+0xcf
 > device_attach(c223ea80,c0c20ca0,c223ea80,c22b2c80,c223d600) at 
 > device_attach+0x5
 > 8
 > device_probe_and_attach(c223ea80) at device_probe_and_attach+0xe0
 > bus_generic_attach(c223d600,103f,1016,c22a3468,4) at bus_generic_attach+0x16
 > acpi_attach(c223d600) at acpi_attach+0x631
 > device_attach(c223d600,0,c223d600,c223dd00,0) at device_attach+0x58
 > device_probe_and_attach(c223d600) at device_probe_and_attach+0xe0
 > bus_generic_attach(c223dd00,c223dd00,c223dd00,c0c20d40,c066a624) at 
 > bus_generic_
 > attach+0x16
 > nexus_attach(c223dd00) at nexus_attach+0x13
 > device_attach(c223dd00,c0951fb4,c223dd00,c0923ed0,c28000) at 
 > device_attach+0x58
 > device_probe_and_attach(c223dd00) at device_probe_and_attach+0xe0
 > root_bus_configure(c0c20d88,c062b006,0,c1ec00,c1e000) at 
 > root_bus_configure+0x16
 > configure(0,c1ec00,c1e000,0,c0446ce5) at configure+0x9
 > mi_startup() at mi_startup+0x96
 > begin() at begin+0x2c

I'm not surprised that maestro(4) would freeze system. As maestro(4)
invokes pci_set_powerstate() in suspend/resume/play/capture, it would
generates lots of LORs and it even calls msleep(9) with driver lock held.
In addition, DMA buffering used in maestro(4) is questionable and we
should cleanup this too.
I have a patch that partially addresses the issue but it still does
not fix other issues mentioned in kern/63204. As my system works
without problems, I don't know what caused this. :-(

http://people.freebsd.org/~yongari/maestro.c
http://people.freebsd.org/~yongari/maestro_reg.h
Captuing was not tested and wouldn't work.

-- 
Regards,
Pyun YongHyeon