Date: Tue, 20 Dec 2005 13:00:26 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Ariff Abdullah <skywizard@MyBSD.org.my> Cc: freebsd-multimedia@freebsd.org Subject: Re: kern/63204: [sound] /dev/mixer broken with ESS Maestro-2E (still on 5.4) Message-ID: <20051220040026.GA4075@rndsoft.co.kr> In-Reply-To: <20051217201154.43fb87d2.skywizard@MyBSD.org.my> References: <20051203092819.GB13672@rndsoft.co.kr> <20051204181714.C728@atlantis.403forbidden.net> <20051205060208.GC1086@rndsoft.co.kr> <20051205202824.C45817@atlantis.403forbidden.net> <20051212030939.GA1093@rndsoft.co.kr> <20051212201440.G701@atlantis.403forbidden.net> <20051213041830.GB5920@rndsoft.co.kr> <20051213200617.K701@atlantis.403forbidden.net> <20051214014838.GA10021@rndsoft.co.kr> <20051217201154.43fb87d2.skywizard@MyBSD.org.my>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 17, 2005 at 08:11:54PM +0800, Ariff Abdullah wrote:
> On Wed, 14 Dec 2005 10:48:38 +0900
> Pyun YongHyeon <pyunyh@gmail.com> wrote:
> > On Tue, Dec 13, 2005 at 08:16:44PM -0500, Steven S. wrote:
> > >
> > >
> > > I tried that patch and no difference.
> > >
> > > if it helps here is the verbose ssndstat output
> > >
> > >
> > > Installed devices:
> > > pcm0: <ESS Technology Maestro-2E> port 0xfc00-0xfcff irq 11 at
> > > device 12.0 on pci0 (4p/1r/4v channels duplex default)
> > > [pcm0:play:0]: spd 44100, fmt 0x10000010, flags
> > > 0x00001000,
> > > 0x00000000
> > > interrupts 0, underruns 0, ready 0
> > > {userland} -> feeder_vchan_s16(0x10000010) -> {hardware}
> > > [pcm0:play:1]: spd 44100, fmt 0x10000010, flags
> > > 0x00000000,
> > > 0x00000000
> > > interrupts 0, underruns 0, ready 0
> > > {userland} -> feeder_root(0x10000010) -> {hardware}
> > > [pcm0:play:2]: spd 0, fmt 0x00000000/0x00000008, flags
> > > 0x00000000,
> > > 0x00000000
> > > interrupts 0, underruns 0, ready 0
> > > {userland} -> feeder_root(0x00000000) -> {hardware}
> > > [pcm0:play:3]: spd 0, fmt 0x00000000/0x00000008, flags
> > > 0x00000000,
> > > 0x00000000
> > > interrupts 0, underruns 0, ready 0
> > > {userland} -> feeder_root(0x00000000) -> {hardware}
> > > [pcm0:record:0]: spd 0, fmt 0x00000000/0x00000008, flags
> > > 0x00000000, 0x00000000
> > > interrupts 0, overruns 0, hfree 16384, sfree 0
> > > {hardware} -> feeder_root(0x00000000) -> {userland}
> > > pcm0:play:0[pcm0:virtual:0]: spd 0, fmt
> > > 0x00000000/0x00000008,
> > > flags 0x10000000, 0x00000000
> > > interrupts 0, underruns 0, ready 0
> > > {userland} -> feeder_root(0x00000000) -> {hardware}
> > > pcm0:play:0[pcm0:virtual:1]: spd 0, fmt
> > > 0x00000000/0x00000008,
> > > flags 0x10000000, 0x00000000
> > > interrupts 0, underruns 0, ready 0
> > > {userland} -> feeder_root(0x00000000) -> {hardware}
> > > pcm0:play:0[pcm0:virtual:2]: spd 0, fmt
> > > 0x00000000/0x00000008,
> > > flags 0x10000000, 0x00000000
> > > interrupts 0, underruns 0, ready 0
> > > {userland} -> feeder_root(0x00000000) -> {hardware}
> > > pcm0:play:0[pcm0:virtual:3]: spd 0, fmt
> > > 0x00000000/0x00000008,
> > > flags 0x10000000, 0x00000000
> > > interrupts 0, underruns 0, ready 0
> > > {userland} -> feeder_root(0x00000000) -> {hardware}
> > >
> > > nothing else changed in dmesg or mixer
> > >
> >
> > Then I have no idea as my system works here. It seems it would be
> > difficult to fix the problem without accessing the hardware. :-(
> > How about setting hw.pci.enable_io_modes=0 or disabling ACPI in
> > loader.conf?
> >
> > Maybe ariff@ has better idea.(CCed)
> >
> To be truth, this is one of the issue that keep me puzzled. Lack of
> hardware is also an issue for me. One thing to note is, this driver
> used to work before the conversion of busdma (<= 5.1-R). The rest:
I don't know whether this driver used to work before contigmalloc(9)
behavior changes but it works here after the change(with/without my
patch).
> 1) Excessive inlining - maestro.c won't survive if WARN=1. Inlining
> failure probably cause incorrect code generation. This need to be
> addressed.
Agreed. AFAIK the driver has the following issues on CURRENT.
1. use of msleep(9) in the driver. Since the driver does not know
whether it has other locks held, I guess it should not use msleep(9).
2. As the driver directly changes PCI power state via
pci_set_powerstate(9) the driver gets numerous LORs. I think it's
job of bus layer and switching power state between start/stop/suspend
and resume routine is questionable.
3. use of critical_enter(9)/critical_exit(9). I don't know whether the
driver really need this calls as it alreay has a driver lock.
4. use of recursive mutex lock which should be elimited and locking is
not complete.
5. DMA buffer management issues. Due to lack of documentation we may
need to guess how to program APU/ASSP/WaveCache.
6. It seems that sometimes the driver fails to initialize codec. I guess
this is the main reason users report broken driver. My patch shamefully
borrowed Linux's magic initialization code but it didn't help.
7. As you said, excessive inlining : this can be easily removed.
The patch at http://people.freebsd.org/~yongari attempts to address all
issues except 5 and 6.
> 2) Delayed interrupt hook - few drivers (ich, atiixp) need to delay
> further chip initialization in order to let interrupt works first.
> I cannot tell whether this is the right solution, but probably
> worth a try.
>
I can't sure but this is not the case for maestro(4) as PR submitter
sees codec timeout messages(e.g. the user saw timeout message before
serving the first interrupt request).
> Anyway, I'll try to get the specific hardware first.
--
Regards,
Pyun YongHyeon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051220040026.GA4075>