5.2-RELEASE TODO
Robert Watson
The live version of this list is available at:
http://www.FreeBSD.org/releases/5.2R/todo.html
Automated mailing of this list will continue through the release of
FreeBSD 5.2.
FreeBSD 5.2 Open Issues
Open Issues
This is a list of open issues that need to be resolved for FreeBSD 5.2. If
you have any updates for this list, please e-mail r...@FreeBSD.org.
Show stopper defects for 5.2-RELEASE
+------------------------------------------------------------------------+
| Issue | Status | Responsible | Description |
|-------------------+----------+-------------+---------------------------|
| | | | There is a repeatable |
| | | | panic happening for many |
| fsync panic while | | | people while installing |
| installing with | Not done | Doug White | 5.2-RC1 when softupdates |
| softupdates | | | are enabled on the root |
| enabled | | | partition. Contact Doug |
| | | | White for more |
| | | | information. |
+------------------------------------------------------------------------+
Required features for 5.2-RELEASE
+------------------------------------------------------------------------+
| Issue | Status | Responsible | Description |
|-----------------+-------------+-------------+--------------------------|
| | | | Significant parts of the |
| | | | network stack |
| | | | (especially IPv4 and |
| | | | IPv6) now have |
| | | | fine-grained locking of |
| | | | their data structures. |
| | | | However, it is not yet |
| | | | possible for the netisr |
| | | | threads to run without |
| Fine-grained | | | Giant, due to |
| network stack | In progress | Sam Leffler | dependencies on sockets, |
| locking without | | | routing, etc. A |
| Giant | | | 5.2-RELEASE goal is to |
| | | | have the network stack |
| | | | running largely without |
| | | | Giant, which should |
| | | | substantially improve |
| | | | performance of the |
| | | | stack, as well as other |
| | | | system components by |
| | | | reducing contention on |
| | | | Giant. |
+------------------------------------------------------------------------+
Desired features for 5.2-RELEASE
+------------------------------------------------------------------------+
| Issue | Status | Responsible | Description |
|---------------------+-------------+-------------+----------------------|
| | | | The FreeBSD KAME |
| | | | IPv6 code is now |
| | | | substantially dated |
| | | | with respect to the |
| KAME | | Hajimu | KAME vendor source. |
| Synchronization | In progress | UMEMOTO | The FreeBSD Project |
| | | | needs to take |
| | | | initiative in |
| | | | driving the merge of |
| | | | new bug fixes, |
| | | | features, et al. |
|---------------------+-------------+-------------+----------------------|
| | | | Currently, there are |
| | | | two classes of |
| | | | interrupt handlers |
| | | | in 5.x: fast |
| | | | interrupt handlers |
| | | | which run entirely |
| | | | in interrupt |
| | | | context, and |
| | | | heavy-weight |
| | | | handlers which |
| | | | execute in a |
| | | | full-weight kernel |
| | | | interrupt thread. It |
| | | | is possible to |
| | | | optimize interrupt |
| | | | thread context |
| | | | management such that |
| | | | a light-weight |
| | | | context switch is |
| | | | performed to begin |
| | | | execution of the |
| | | | interrupt thread in |
| | | | the handler context, |
| Light-weight | | | and only when a |
| interrupt threads, | Not done | -- | full-weight context |
| context switches | | | is required (such as |
| | | | sleeping on a lock) |
| | | | is that cost |
| | | | required. This |
| | | | optimization should |
| | | | substantially |
| | | | improve interrupt |
| | | | latency. There are |
| | | | also additional |
| | | | kernel thread |
| | | | context switch |
| | | | optimizations that |
| | | | can be made to |
| | | | improve the |
| | | | performance of |
| | | | thread workers in |
| | | | the kernel, such as |
| | | | found in the network |
| | | | stack, crypto worker |
| | | | threads, and GEOM. |
| | | | Bosko Milekic has |
| | | | done substantial |
| | | | prototyping work, |
| | | | and should be |
| | | | coordinated with. |
|---------------------+-------------+-------------+----------------------|
| | | | Currently, gbde must |
| | | | be manually |
| | | | configured at |
| | | | run-time each time |
| | | | an encrypted disk |
| | | | device is mounted. |
| | | | This prevents easy |
| Run-time | | | integration into |
| autoconfiguration | Not done | -- | /etc/fstab and easy |
| of GBDE and related | | | automated |
| transforms | | | deployment. Improved |
| | | | integration with the |
| | | | configuration, |
| | | | mounting, and boot |
| | | | process is required |
| | | | to make this feature |
| | | | more easily |
| | | | accessible. |
|---------------------+-------------+-------------+----------------------|
| gdb -k support for | Not done | Mark Peek | gdb -k doesn't work |
| alpha | | | on alpha |
+------------------------------------------------------------------------+
Documentation items desired for 5.2
+------------------------------------------------------------------------+
| Issue | Status | Responsible | Description |
|---------------+-------------+--------------+---------------------------|
| | | | The Early Adopters Guide |
| | | | needs to be revised, |
| Revise EAG | Done | Bruce A. Mah | hopefully for the last |
| | | | time, to reflect the |
| | | | state of 5.2. |
|---------------+-------------+--------------+---------------------------|
| | | | Ongoing project to remove |
| | | | redundancy in |
| Trim Hardware | | | documentation by removing |
| Notes | In progress | Bruce A. Mah | lists of specific devices |
| | | | from the hardware notes |
| | | | and pointing readers to |
| | | | driver manpages. |
+------------------------------------------------------------------------+
Testing focuses for 5.2-RELEASE
+---------------------------------------------------------------------------+
| Issue | Status |Responsible| Description |
|--------------+-------------+-----------+----------------------------------|
| | | |The PCM audio framework and device|
| | | |drivers have been locked and free |
|PCM locking | | |of Giant for quite a while, but |
|and |Needs testing|-- |LOR problems persist along with |
|performance | | |reports of poor audio performance |
|issues | | |under load. These problems are |
| | | |believed to have been corrected, |
| | | |but more testing is desired. |
|--------------+-------------+-----------+----------------------------------|
|ATA driver | | |New ATA model has arrived, |
|structural |Needs testing|So/ren |supporting fine-grained locking, |
|improvements, | |Schmidt |and more. Much testing is needed |
|MPsafety | | |to ensure no regressions. |
|--------------+-------------+-----------+----------------------------------|
|GPT support | |Marcel |Sysinstall and libdisk has been |
|for sysinstall|Needs testing|Moolenaar |overhauled to support the GPT |
| | | |partition scheme used on ia64. |
|--------------+-------------+-----------+----------------------------------|
| | | |Interrupt routing on ia32 has been|
| | | |completely re-written to support |
|Complete the | | |ACPI hints for PCI interrupt |
|APIC PCI | | |routing, along with ACPI hints for|
|interrupt |Needs testing|John |CPU enumeration. There have been |
|routing | |Baldwin |reports of interrupt storms or a |
|support | | |failure for interrupts to deliver,|
| | | |possibly a result of bad ACPI |
| | | |information. These problems need |
| | | |to be tracked down and resolved. |
|--------------+-------------+-----------+----------------------------------|
|ATAng | |So/ren |Performing a crashdump on an ATA |
|crashdump |Needs testing|Schmidt, |device can result in a corrupted |
|causes disk | |Tor Egge |MBR record. Tor has a possible |
|corruption | | |patch for this. |
|--------------+-------------+-----------+----------------------------------|
| | | |The ACPI code registers |
|SMP users | | |eventhandlers that are not |
|report | | |unregistered when ACPI shuts down |
|acpi_cpu panic|Needs testing|Nate Lawson|during system shutdown. The result|
|during | | |can be a panic during shutdown. |
|shutdown | | |Nate is circulating a patch that |
| | | |is believed to correct this |
| | | |problem. |
|--------------+-------------+-----------+----------------------------------|
| | | |There are reports of witness |
| | | |panics in |
| | | |random_harvest_internal() due to |
| | | |last minute changes in interrupt |
|random_harvest| | |entropy harvesting code. Systems |
|panic |Needs testing|Mark Murray|running with INVARIANTS will |
| | | |rapidly panic. Update: a |
| | | |workaround has been committed, but|
| | | |the original change must either be|
| | | |backed out or revised before we |
| | | |can cut the first beta. |
|--------------+-------------+-----------+----------------------------------|
| | | |In the last week, reports of two |
| | | |new (and possibly related) Vinum |
| | | |failures have come to light: a |
| | | |warning message of vinum: exiting |
|Vinum data | | |with malloc table inconsistency at|
|corruption and| | |0xc2053c00 from vinumio.c:755 has |
|memory |Needs testing|Greg Lehey |been experienced when Vinum |
|allocation | | |auto-configuration fails. Also, |
|problems | | |even simple test cases for Vinum |
| | | |I/O appear to result in incorrect |
| | | |data being returned from disk, |
| | | |rendering Vinum unusable in |
| | | |several reproduceable |
| | | |configurations. |
|--------------+-------------+-----------+----------------------------------|
| | | |The new i386 inpterrupt code |
| | | |should work whether the acpi |
|ACPI kernel | |John |driver is compiled into the kernel|
|module |Needs testing|Baldwin |or loaded as a module. The loader |
| | | |should automatically load the |
| | | |module if it's not already |
| | | |compiled in. |
|--------------+-------------+-----------+----------------------------------|
| | | |There have been a number of |
| | | |reports of NFS clients and server |
|Reported NFS | | |hangs. Unfortunately, these are |
|failures |Unknown | |difficult to reproduce, and have |
| | | |not yet been traced back to a |
| | | |particular change or reliable |
| | | |reproduction scenario. |
|--------------+-------------+-----------+----------------------------------|
| | | |panic: Assertion td->td_turnstile |
| | | |!= NULL failed at |
|Turnstile | |John |../../../kern/subr_turnstile.c:427|
|assertion |Unknown |Baldwin |has been affecting several users |
|failure | | |on multiple platforms. This has |
| | | |hopefully been fixed now, but more|
| | | |testinig is needed. |
+---------------------------------------------------------------------------+
----------------------------------------------------------------------
home | contact | legal | (c) 1995-2003 The FreeBSD Project.
All rights reserved.
Last modified: 2003/12/12 16:10:20
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Peter Schultz
> Testing focuses for 5.2-RELEASE
>
> +---------------------------------------------------------------------------+
> | Issue | Status |Responsible| Description |
> |--------------+-------------+-----------+----------------------------------|
> | | | |The PCM audio framework and device|
> | | | |drivers have been locked and free |
> |PCM locking | | |of Giant for quite a while, but |
> |and |Needs testing|-- |LOR problems persist along with |
> |performance | | |reports of poor audio performance |
> |issues | | |under load. These problems are |
> | | | |believed to have been corrected, |
> | | | |but more testing is desired. |
> |--------------+-------------+-----------+----------------------------------|
>
Xmms hasn't played mp3s without a hicup for me on -CURRENT since at
least a year, if not two or more. It's been so long I can't recall.
I'm testing with a soundblaster live! value card:
pcm0: <Creative EMU10K1> port 0xef20-0xef3f irq 17 at device 17.0 on pci0
pcm0: <SigmaTel STAC9721/23 AC97 Codec>
I'm running a -CURRENT SMP kernel on a Tyan S1832DL w/dual PII 350s. I
only assume it's working with 5.2 RC1.
Pete...
Munehiro Matsuda
Date: Mon, 15 Dec 2003 09:47:58 -0600
::Robert Watson wrote:
::> Testing focuses for 5.2-RELEASE
::>
::> +---------------------------------------------------------------------------+
::> | Issue | Status |Responsible| Description |
::> |--------------+-------------+-----------+----------------------------------|
::> | | | |The PCM audio framework and device|
::> | | | |drivers have been locked and free |
::> |PCM locking | | |of Giant for quite a while, but |
::> |and |Needs testing|-- |LOR problems persist along with |
::> |performance | | |reports of poor audio performance |
::> |issues | | |under load. These problems are |
::> | | | |believed to have been corrected, |
::> | | | |but more testing is desired. |
::> |--------------+-------------+-----------+----------------------------------|
:: >
::This longstanding problem has now been fixed as far as I'm concerned.
::Xmms hasn't played mp3s without a hicup for me on -CURRENT since at
::least a year, if not two or more. It's been so long I can't recall.
::
::I'm testing with a soundblaster live! value card:
::pcm0: <Creative EMU10K1> port 0xef20-0xef3f irq 17 at device 17.0 on pci0
::pcm0: <SigmaTel STAC9721/23 AC97 Codec>
::
::I'm running a -CURRENT SMP kernel on a Tyan S1832DL w/dual PII 350s. I
::only assume it's working with 5.2 RC1.
::
::Pete...
Hi,
I still get LOR with my sound card and some hicup under disk load, with
today's 5.2-CURRENT. It's a UP system with following sound card.
pcm0: <Yamaha DS-1E (YMF744)> port 0xfcac-0xfcaf,0xfc00-0xfc3f mem 0xfecf0000-0xfecf7fff irq 9 at device 9.0 on pci0
pcm0: <Asahi Kasei AK4543 AC97 Codec>
Also, here's hand written LOR message:
lock order reversal
1st 0xc3405440 pcm0 (sound softc) @ dev/sound/pci/ds1.c:734
2nd 0xc3405080 pcm0:play:0 (pcm play channel) @ dev/sound/pcm/channel.c:480
Stack backtrace:
....
witness_lock(c3405080,0,c07a8705,1e0,c33f7300) at witness_lock+0x672
_mtx_lock_flags(c3405080,0,c07a8705,1e0,0) at _mtx_lock_flags+0xba
chn_intr(c33f7300,104,4,4,c3405240) at chn_intr+0x2f
ds_intr(c340b4000,0,c07b3baa,21f,c334c1c4) at ds_intr+0xf5
ithread_loop(c1856900,d03a7d48,c07b3a24,311,3473635f) at ithread_loop+0x192
fork_exit(c059da00,c1856900,d03a7d48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
Thanks,
Haro
=------------------------------------------------------------------------------
_ _ Munehiro (haro) Matsuda
-|- /_\ |_|_| Internet Solution Dept., Kubota Graphics Technologies Inc.
/|\ |_| |_|_| 2-8-8 Shinjuku Shinjuku-ku Tokyo 160-0022, Japan
Tel: +81-3-3225-0767 Fax: +81-3-3225-0740
Email: ha...@kgt.co.jp
Munish Chopra
They haven't been corrected in my case, or the cases of quite a few
other folks experiencing them (see some of the other ongoing threads).
I'm not personally seeing any LOR's, but audio playback slows down under
load, and every few seconds I hear popping noises during audio playback,
whether under load or not.
I've got a simple SB16:
pcm0: <Creative CT5880-C> port 0xd800-0xd83f irq 5 at device 15.0 on
pci0
pcm0: <TriTech TR28602 AC97 Codec>
--
Munish Chopra
Jesse Guardiani
> From: Peter Schultz <pm...@bis.midco.net>
> Date: Mon, 15 Dec 2003 09:47:58 -0600
> ::
> ::Pete...
>
> Hi,
>
> I still get LOR with my sound card and some hicup under disk load, with
> today's 5.2-CURRENT. It's a UP system with following sound card.
>
> pcm0: <Yamaha DS-1E (YMF744)> port 0xfcac-0xfcaf,0xfc00-0xfc3f mem
> 0xfecf0000-0xfecf7fff irq 9 at device 9.0 on pci0 pcm0: <Asahi Kasei
> AK4543 AC97 Codec>
>
> Also, here's hand written LOR message:
>
> lock order reversal
> 1st 0xc3405440 pcm0 (sound softc) @ dev/sound/pci/ds1.c:734
> 2nd 0xc3405080 pcm0:play:0 (pcm play channel) @
> dev/sound/pcm/channel.c:480
> Stack backtrace:
> ....
> witness_lock(c3405080,0,c07a8705,1e0,c33f7300) at witness_lock+0x672
> _mtx_lock_flags(c3405080,0,c07a8705,1e0,0) at _mtx_lock_flags+0xba
> chn_intr(c33f7300,104,4,4,c3405240) at chn_intr+0x2f
> ds_intr(c340b4000,0,c07b3baa,21f,c334c1c4) at ds_intr+0xf5
> ithread_loop(c1856900,d03a7d48,c07b3a24,311,3473635f) at
> ithread_loop+0x192 fork_exit(c059da00,c1856900,d03a7d48) at fork_exit+0xb4
> fork_trampoline() at fork_trampoline+0x8
Hmmm... I'm not much of a kernel hacker, but that's certainly different from
the duplicate lock Matthew Kanner fixed here (which fixed my sound problems):
http://article.gmane.org/gmane.os.freebsd.current/34708
For what it's worth, I've also noticed a few hiccups in XMMS, but it's nothing
like what it was before Matthew Kanner's channel.c patch. I notice it only
under extremely high load and only once a day or week, rather than once every
5 minutes or so like it was in 5.1-RELEASE. Unfortunately I haven't seen an
LOR or dup lock the last few times it happened, so I thought the hiccups might
not be caused by the sound code... but maybe I was wrong... :)
To recap, my hardware is working great with 5.2-BETA (boot -v output below):
pcm0: <Intel ICH3 (82801CA)> port 0x18c0-0x18ff,0x1c00-0x1cff irq 5 at device 31.5 on pci0
pcm0: <Cirrus Logic CS4299 AC97 Codec (id = 0x43525936)>
pcm0: Codec features headphone, 20 bit DAC, 18 bit ADC, 6 bit master volume, Crystal Semi 3D Stereo Enhancement
pcm0: Primary codec extended features variable rate PCM, AMAP
pcm0: sndbuf_setmap 261000, 4000; 0xe38ec000 -> 261000
pcm0: sndbuf_setmap 27f000, 4000; 0xe38f0000 -> 27f000
pcm0: measured ac97 link rate at 47998 Hz, will use 48000 Hz
--
Jesse Guardiani, Systems Administrator
WingNET Internet Services,
P.O. Box 2605 // Cleveland, TN 37320-2605
423-559-LINK (v) 423-559-5145 (f)
http://www.wingnet.net
keoki seu
of the exact date). I'm using mpg321 with gqmpeg as a frontend.
My sound card a sb live! value, but apparently a different chip?
pcm0: <Creative EMU10K1> port 0xd000-0xd01f irq 11 at device 10.0 on pci0
pcm0: <TriTech TR28602 AC97 Codec>
I dont see any LOR's related to sound, but i get skips under heavy
(mostly disk) i/o.
and this is on a -CURRENT UP kernel:
FreeBSD 5.2-CURRENT #0: Wed Dec 10 06:32:42 EST 2003
keoki@hoku:/usr/obj/usr/src/sys/hoku
keoki
Mathew Kanner
--uAKRQypu60I7Lcqm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Dec 15, Munehiro Matsuda wrote:
> From: Peter Schultz <pm...@bis.midco.net>
> Date: Mon, 15 Dec 2003 09:47:58 -0600
> ::Robert Watson wrote:
> ::> Testing focuses for 5.2-RELEASE
> ::>
> ::> +---------------------------------------------------------------------------+
> ::> | Issue | Status |Responsible| Description |
> ::> |--------------+-------------+-----------+----------------------------------|
> ::> | | | |The PCM audio framework and device|
> ::> | | | |drivers have been locked and free |
> ::> |PCM locking | | |of Giant for quite a while, but |
> ::> |and |Needs testing|-- |LOR problems persist along with |
> ::> |performance | | |reports of poor audio performance |
> ::> |issues | | |under load. These problems are |
> ::> | | | |believed to have been corrected, |
> ::> | | | |but more testing is desired. |
> ::> |--------------+-------------+-----------+----------------------------------|
> :: >
> ::This longstanding problem has now been fixed as far as I'm concerned.
> ::Xmms hasn't played mp3s without a hicup for me on -CURRENT since at
> ::least a year, if not two or more. It's been so long I can't recall.
> ::
> ::I'm testing with a soundblaster live! value card:
> ::pcm0: <Creative EMU10K1> port 0xef20-0xef3f irq 17 at device 17.0 on pci0
> ::pcm0: <SigmaTel STAC9721/23 AC97 Codec>
> ::
> ::I'm running a -CURRENT SMP kernel on a Tyan S1832DL w/dual PII 350s. I
> ::only assume it's working with 5.2 RC1.
> ::
> ::Pete...
>
> Hi,
>
> I still get LOR with my sound card and some hicup under disk load, with
> today's 5.2-CURRENT. It's a UP system with following sound card.
>
> pcm0: <Yamaha DS-1E (YMF744)> port 0xfcac-0xfcaf,0xfc00-0xfc3f mem 0xfecf0000-0xfecf7fff irq 9 at device 9.0 on pci0
> pcm0: <Asahi Kasei AK4543 AC97 Codec>
>
> Also, here's hand written LOR message:
>
> lock order reversal
> 1st 0xc3405440 pcm0 (sound softc) @ dev/sound/pci/ds1.c:734
> 2nd 0xc3405080 pcm0:play:0 (pcm play channel) @ dev/sound/pcm/channel.c:480
> Stack backtrace:
> ....
> witness_lock(c3405080,0,c07a8705,1e0,c33f7300) at witness_lock+0x672
> _mtx_lock_flags(c3405080,0,c07a8705,1e0,0) at _mtx_lock_flags+0xba
> chn_intr(c33f7300,104,4,4,c3405240) at chn_intr+0x2f
> ds_intr(c340b4000,0,c07b3baa,21f,c334c1c4) at ds_intr+0xf5
> ithread_loop(c1856900,d03a7d48,c07b3a24,311,3473635f) at ithread_loop+0x192
> fork_exit(c059da00,c1856900,d03a7d48) at fork_exit+0xb4
> fork_trampoline() at fork_trampoline+0x8
Hello,
This LOR is mostly harmless. Please try the attached patch
the avoid it. Since this bug isn't critical, I won't commit it to 5.2
unless instructed otherwise by the -re team.
Thanks,
--Mat
--
Having your book made into a movie is like having your ox
made into a bouillon cube.
- Bill Neely
--uAKRQypu60I7Lcqm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="ds1.patch"
Index: ds1.c
===================================================================
RCS file: /home/ncvs/src/sys/dev/sound/pci/ds1.c,v
retrieving revision 1.36
diff -u -r1.36 ds1.c
--- ds1.c 2 Sep 2003 17:30:37 -0000 1.36
+++ ds1.c 15 Dec 2003 18:49:02 -0000
@@ -729,8 +729,15 @@
ds_intr(void *p)
{
struct sc_info *sc = (struct sc_info *)p;
- u_int32_t i, x;
+ int i, pch, rch;
+ /*
+ * In this particular scenerio, sc->lock only protects
+ * against hardware access. Other immutables, like the lock itself and
+ * the pointers to the pcm channel structure can be accessed safely without
+ * the lock.
+ */
+ pch = rch = 0;
snd_mtxlock(sc->lock);
i = ds_rd(sc, YDSXGR_STATUS, 4);
if (i & 0x00008000)
@@ -739,25 +746,26 @@
ds_wr(sc, YDSXGR_STATUS, i & 0x80008000, 4);
sc->currbank = ds_rd(sc, YDSXGR_CTRLSELECT, 4) & 0x00000001;
- x = 0;
- for (i = 0; i < DS1_CHANS; i++) {
- if (sc->pch[i].run) {
- x = 1;
- chn_intr(sc->pch[i].channel);
- }
- }
- for (i = 0; i < 2; i++) {
- if (sc->rch[i].run) {
- x = 1;
- chn_intr(sc->rch[i].channel);
- }
- }
+ for (i = 0; i < DS1_CHANS; i++)
+ if (sc->pch[i].run)
+ pch |= 1<<i;
+ for (i = 0; i < 2; i++)
+ if (sc->rch[i].run)
+ rch |= 1<<i;
i = ds_rd(sc, YDSXGR_MODE, 4);
- if (x)
+ if ( pch || rch )
ds_wr(sc, YDSXGR_MODE, i | 0x00000002, 4);
}
snd_mtxunlock(sc->lock);
+
+ for (i = 0; i<DS1_CHANS; i++)
+ if ( pch & (1<<i) )
+ chn_intr(sc->pch[i].channel);
+
+ for (i = 0; i<2; i++)
+ if ( rch & (1<<i) )
+ chn_intr(sc->rch[i].channel);
}
/* -------------------------------------------------------------------- */
--uAKRQypu60I7Lcqm
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
--uAKRQypu60I7Lcqm--
Mathew Kanner
> On 2003-12-15 09:47 +0000, Peter Schultz wrote:
... snip ...
> > This longstanding problem has now been fixed as far as I'm concerned.
> > Xmms hasn't played mp3s without a hicup for me on -CURRENT since at
> > least a year, if not two or more. It's been so long I can't recall.
> >
> > I'm testing with a soundblaster live! value card:
> > pcm0: <Creative EMU10K1> port 0xef20-0xef3f irq 17 at device 17.0 on pci0
> > pcm0: <SigmaTel STAC9721/23 AC97 Codec>
> >
> > I'm running a -CURRENT SMP kernel on a Tyan S1832DL w/dual PII 350s. I
> > only assume it's working with 5.2 RC1.
> >
>
> They haven't been corrected in my case, or the cases of quite a few
> other folks experiencing them (see some of the other ongoing threads).
>
> I'm not personally seeing any LOR's, but audio playback slows down under
> load, and every few seconds I hear popping noises during audio playback,
> whether under load or not.
>
> I've got a simple SB16:
> pcm0: <Creative CT5880-C> port 0xd800-0xd83f irq 5 at device 15.0 on
> pci0
> pcm0: <TriTech TR28602 AC97 Codec>
Hello Munish,
I would realy like to help you and others. Please describe in
detail the circumstances that create the problem. Are you
experiencing buffer overruns or underruns? How many devices are
sharing the IRQ? What are they? What happens when you cat a raw file
to the device? Does this happen with VCHANs? Have you tried the patch
I posted to -current under the heading "sound patch for pop &
crackles"?
Please read the pcm man page for a better description on how
the answer the above.
Thanks,
--Mat
--
If you optimize everything, you will always be unhappy.
- Don Knuth
Munish Chopra
> On Dec 15, Munish Chopra wrote:
> >
> > I'm not personally seeing any LOR's, but audio playback slows down under
> > load, and every few seconds I hear popping noises during audio playback,
> > whether under load or not.
> >
> > I've got a simple SB16:
> > pcm0: <Creative CT5880-C> port 0xd800-0xd83f irq 5 at device 15.0 on
> > pci0
> > pcm0: <TriTech TR28602 AC97 Codec>
>
> Hello Munish,
> I would realy like to help you and others. Please describe in
> detail the circumstances that create the problem. Are you
> experiencing buffer overruns or underruns? How many devices are
> sharing the IRQ? What are they? What happens when you cat a raw file
> to the device? Does this happen with VCHANs? Have you tried the patch
> I posted to -current under the heading "sound patch for pop &
> crackles"?
> Please read the pcm man page for a better description on how
> the answer the above.
>
There are two distinct problems in my case:
1) Load can be virtually zero, moderate, or heavy, either way every few
seconds (anywhere between 2 and 10 seconds or so) I hear snaps or
pops in the output. Some are pretty hard to hear, others are obvious,
depending on what's actually playing.
2) When untarring large gzip'ed or bzip2'ed tarballs, playback begins to
"slow down" to something like half the normal speed or less. I first
noticed this during portupgrade, when the XFree86 tarballs are
unpacked.
Interestingly enough, even when I hammer the disk with several FTP
transfers and copies, I don't see the "slow down" effect.
I'm seeing neither buffer overruns nor underruns. With hw.snd.verbose
set to 3, here's the output of `cat /dev/sndstat` towards the end of a
random MP3:
FreeBSD Audio Driver (newpcm)
Installed devices:
pcm0: <Creative CT5880-C> at io 0xd800 irq 5 (1p/1r/0v channels duplex
default)
[pcm0:record:0]: spd 0, fmt 0x00000000/0x00000008, flags
0x00000000, 0x00000000
interrupts 0, overruns 0, hfree 4096, sfree 0
{hardware} -> feeder_root(0x00000000) -> {userland}
[pcm0:play:0]: spd 44100/44099, fmt 0x10000010, flags
0x00005030, 0x00000000, pid 7063
interrupts 21630, underruns 0, ready 129600
{userland} -> feeder_root(0x10000010) -> {hardware}
File Versions:
$FreeBSD: src/sys/dev/sound/pci/es137x.c,v 1.48 2003/09/07 16:28:03 cg
Exp $
$FreeBSD: src/sys/dev/sound/isa/sndbuf_dma.c,v 1.2 2003/09/07 16:28:02
cg Exp $
$FreeBSD: src/sys/dev/sound/pcm/vchan.c,v 1.13 2003/09/07 16:28:03 cg
Exp $
$FreeBSD: src/sys/dev/sound/pcm/sound.c,v 1.86 2003/12/08 01:08:03
truckman Exp $
$FreeBSD: src/sys/dev/sound/pcm/sndstat.c,v 1.15 2003/12/08 01:08:03
truckman Exp $
$FreeBSD: src/sys/dev/sound/pcm/mixer.c,v 1.33 2003/11/11 05:38:28
scottl Exp $
$FreeBSD: src/sys/dev/sound/pcm/feeder_rate.c,v 1.10 2003/04/20 17:08:56
orion Exp $
$FreeBSD: src/sys/dev/sound/pcm/feeder_fmt.c,v 1.13 2003/09/07 16:28:03
cg Exp $
$FreeBSD: src/sys/dev/sound/pcm/feeder.c,v 1.32 2003/09/07 16:28:03 cg
Exp $
$FreeBSD: src/sys/dev/sound/pcm/fake.c,v 1.13 2003/09/07 16:28:03 cg Exp
$
$FreeBSD: src/sys/dev/sound/pcm/dsp.c,v 1.67 2003/11/11 05:38:28 scottl
Exp $
$FreeBSD: src/sys/dev/sound/pcm/channel.c,v 1.93 2003/12/05 02:08:13
matk Exp $
$FreeBSD: src/sys/dev/sound/pcm/buffer.c,v 1.21 2003/11/27 19:51:44 matk
Exp $
$FreeBSD: src/sys/dev/sound/pcm/ac97_patch.c,v 1.2 2003/08/21 15:44:55
orion Exp $
$FreeBSD: src/sys/dev/sound/pcm/ac97.c,v 1.49 2003/11/11 22:15:17
kuriyama Exp $
I can't see anything unusual above, but perhaps something's lurking. I
played this with no load on the box, and every few seconds there were
easily discernable popping noises.
There are no IRQ's being shared, though I hadn't noticed this before (it
looks harmless to me?): pcib0: slot 15 INTA is routed to irq 5
I cat'ed a file to the sound device and received static -- is there
something specific I should be looking for? For future reference, what
clues were you hoping to gain from this?
I'm not using VCHANS, though the last time I did (some months ago) I had
the same problems.
I haven't tried your patch, I fear I was pretty busy when you posted it
and brushed past it assuming it had been committed. I'll hunt it down
now and see if it changes anything.
Thanks for taking interest in this, I appreciate it.
--
Munish Chopra
Mathew Kanner
Hello Munish,
Thank you for the report. What program are you using? Could
I also have a dmesg.
Here are a few random thouhts: I'm going to try and tackle #1
in your issues above. #2 seems like bus contention or somthing like
that (I vaguely recall Cameron charecterizing it like that). Also, in
your /dev/sndstat output, your hardware speed != playing speed. Very
wierd and I haven't seen that before, I wonder what it means. Could
you also try
sysctl hw.snd.report_soft_formats=0
retest and provide the sndstat output.
In regards to the raw playing, forget it for now, though I
might ask later.
--Mat
--
I don't even know what street Canada is on.
- Al Capone
Matt Loschert
FWIW, I have been seeing the same thing (problem 2) while running xmms and
portupgrade on 4.9-STABLE. This particular problem is definitely not
confined to -CURRENT.
- Matt
--
Matt Loschert - Software Engineer | email: losc...@servint.com |
ServInt Internet Services | web: http://www.servint.net/ |
McLean, Virginia USA | phone: (703) 847-1381 |
Munish Chopra
> > > On Dec 15, Munish Chopra wrote:
> >
[...]
> > FreeBSD Audio Driver (newpcm)
> > Installed devices:
> > pcm0: <Creative CT5880-C> at io 0xd800 irq 5 (1p/1r/0v channels duplex
> > default)
> > [pcm0:record:0]: spd 0, fmt 0x00000000/0x00000008, flags
> > 0x00000000, 0x00000000
> > interrupts 0, overruns 0, hfree 4096, sfree 0
> > {hardware} -> feeder_root(0x00000000) -> {userland}
> > [pcm0:play:0]: spd 44100/44099, fmt 0x10000010, flags
> > 0x00005030, 0x00000000, pid 7063
> > interrupts 21630, underruns 0, ready 129600
> > {userland} -> feeder_root(0x10000010) -> {hardware}
>
> Hello Munish,
> Thank you for the report. What program are you using? Could
> I also have a dmesg.
XMMS and MPlayer. For the purpose of testing and providing sndstat
output, I was using MPlayer.
dmesg:
FreeBSD 5.2-CURRENT #0: Sun Dec 14 20:26:10 EST 2003
cho...@opiate.soulwax.net:/usr/obj/usr/src/sys/OPIATE
Preloaded elf kernel "/boot/kernel/kernel" at 0xc08d5000.
Preloaded elf module "/boot/kernel/linux.ko" at 0xc08d526c.
Preloaded elf module "/boot/kernel/snd_es137x.ko" at 0xc08d5318.
Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc08d53c8.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc08d5474.
Preloaded elf module "/boot/kernel/nvidia.ko" at 0xc08d5520.
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) Processor (1194.92-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0x644 Stepping = 4
Features=0x183f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,M MX,FXSR>
AMD Features=0xc0440000<RSVD,AMIE,DSP,3DNow!>
real memory = 536805376 (511 MB)
avail memory = 511991808 (488 MB)
Pentium Pro MTRR support enabled
npx0: [FAST]
npx0: <math processor> on motherboard
npx0: INT 16 interface
acpi0: <AMIINT SiS735XX> on motherboard
ACPI-0188: *** Error: No object was returned from
[\\_SB_.PCI0.SBRG.ECP_._STA] (Node 0xc3432ae0),
AE_NOT_EXIST
pcibios: BIOS version 2.10
Using $PIR table, 8 entries at 0xc00f7950
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
ACPI-0188: *** Error: No object was returned from
[\\_SB_.PCI0.SBRG.ECP_._STA] (Node 0xc3432ae0),
AE_NOT_EXIST
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
acpi_cpu0: <CPU> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib0: slot 3 INTA is routed to irq 10
pcib0: slot 15 INTA is routed to irq 5
pcib1: <PCI-PCI bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
pcib0: slot 1 INTA is routed to irq 11
pcib1: slot 0 INTA is routed to irq 11
nvidia0: <GeForce4 MX 440 with AGP8X> mem
0xc8000000-0xcbffffff,0xce000000-0xceffffff irq 11 at
device 0.0 on pci1
isab0: <PCI-ISA bridge> at device 2.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <SiS 735 UDMA100 controller> port 0xff00-0xff0f at device 2.5
on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]
sis0: <SiS 900 10/100BaseTX> port 0xdc00-0xdcff mem
0xcfffd000-0xcfffdfff irq 10 at devic e 3.0 on pci0
sis0: Ethernet address: 00:d0:09:e6:62:9b
miibus0: <MII bus> on sis0
rlphy0: <RTL8201L 10/100 media interface> on miibus0
rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pcm0: <Creative CT5880-C> port 0xd800-0xd83f irq 5 at device 15.0 on
pci0
pcm0: <TriTech TR28602 AC97 Codec>
acpi_button0: <Sleep Button> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x64,0x60 irq 1 on acpi0
atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: model MouseMan+, device ID 0
fdc0: cmd 3 failed at out byte 1 of 3
orm0: <Option ROM> at iomem 0xcf000-0xd6fff on isa0
fdc0: cannot reserve I/O port range (6 ports)
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on
isa0
Timecounter "TSC" frequency 1194921268 Hz quality 800
Timecounters tick every 1.000 msec
GEOM: create disk ad0 dp=0xc3476760
ad0: 39266MB <IC35L040AVER07-0> [79780/16/63] at ata0-master UDMA100
GEOM: create disk cd0 dp=0xc3457e00
cd0 at ata1 bus 0 target 0 lun 0
cd0: <HL-DT-ST CD-RW GCE-8320B 1.04> Removable CD-ROM SCSI-0 device
cd0: 3.300MB/s transfers
cd0: Attempt to query device size failed: NOT READY, Medium not present
Mounting root from ufs:/dev/ad0s1a
There were also a whole bunch of these, though I assume they're
irrelevant:
ACPI-0188: *** Error: No object was returned from
[\\_SB_.PCI0.SBRG.ECP_._STA] (Node 0xc3432ae0),
AE_NOT_EXIST
> Here are a few random thouhts: I'm going to try and tackle #1
> in your issues above. #2 seems like bus contention or somthing like
> that (I vaguely recall Cameron charecterizing it like that). Also, in
About #2, I seem to recall Cameron mentioning something similar, though
that must be at least six months ago now.
> your /dev/sndstat output, your hardware speed != playing speed. Very
> wierd and I haven't seen that before, I wonder what it means. Could
> you also try
> sysctl hw.snd.report_soft_formats=0
> retest and provide the sndstat output.
FreeBSD Audio Driver (newpcm)
Installed devices:
pcm0: <Creative CT5880-C> at io 0xd800 irq 5 (1p/1r/0v channels duplex
default)
[pcm0:record:0]: spd 0, fmt 0x00000000/0x00000008, flags
0x00000000, 0x00000000
interrupts 0, overruns 0, hfree 4096, sfree 0
{hardware} -> feeder_root(0x00000000) -> {userland}
[pcm0:play:0]: spd 44100/44099, fmt 0x10000010, flags
0x00005030, 0x00000000, pid 7779
interrupts 22068, underruns 0, ready 130560
{userland} -> feeder_root(0x10000010) -> {hardware}
I omitted the file versions since they're identical to my previous
output.
--
Munish Chopra