Re: Sound broken on -current again...
On Sun, Aug 19, 2001 at 04:42:35PM -0500, some SMTP stream spewed forth: > > > Søren Schmidt wrote: > > > It seems Alexander Leidinger wrote: > > > >>On 19 Aug, Søren Schmidt wrote: > >> > >> > >Yups, reverting this, even in a newer kernel makes sound work again, > >well the VIA support is still not sounding proberly, but it didn't > >before as well so thats not related to this bogon... > > > Perhaps the bug in the chipset^wPCI-spec? > > >>>I dont think so, before the latest changes it worked just fine... > >>> > >>What's the problem? I didn't noticed anything. > >> > > > > It seems that there is either a slight pause, or random noise > > between each DMA buffer played... > > > > -Søren > > > Was this chipset or motherboard-dependant? With regard to the issues I mentioned earlier in this thread (that ~1 second of audio plays before the audio stops and I must kill xmms or mpg123), I am using Asus K7V Athlon 700 SoundBlaster Live! Platinum > Like I said, I had no problems running SMP and with a SB/Live!-Value... > > Current as of yesterday morning [6-7AMish CDT], Tyan S1696DLUA motherboard, 2 >Pentium-II/333's, SB/Live! Value card. Did not produce > thse issues. I have experienced this since the 17th. There have been no commits remotely near the sound system since then. gh > jim > -- > ET has one helluva sense of humor! > He's always anal-probing right-wing schizos! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sound broken on -current again...
On Wed, Aug 15, 2001 at 07:01:46PM +0200, some SMTP stream spewed forth: > > One gets the first DMA buffer full, then the process hangs... Due to the lack of replies, I'll go ahead. I am seeing sound breakage also. My card is a Creative Labs SoundBlaster Live!. xmms will play a short (less than a second) spurt of audio and then stop responding. mpg123 will not play (any audio to the speakers) at all. I ran a buildworld today which apparently broke it. That puts the breakage between today and sometime less than 2 months ago. (I really cannot be more specific.) Suggestions gladly welcomed. > -Søren Daniel M. Kurry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: X in free(): error: recursive call.
On Tue, Jul 31, 2001 at 09:13:29AM +0200, some SMTP stream spewed forth: > Hello, > > I was running in the same problem early this year. Probably you > have found my mails in the archive. Unfortunately I was not able > solve the problem. I am running now 3.3.6 on my laptop (which > furtunately supports the graphics chips that my laptop has). > > Just as a datapoint: My understanding of the problem is that it > is really a problem of XFree (as opposed to FreeBSD) There seems > to be a situation where malloc is called within a signal > handler. It was explained to me that malloc cannot be recursively > called. Therefore, if a signal interrupts Xfree when it is in the > libc *alloc-functions, this can crash the server. Indeed. It was a Big Fat Mess inside the 3-button emulation code. libc is innocent, I tell you, innocent! ;-) > The following trace shows this scenario: > > #0 0x2820a9e8 in kill () from /usr/lib/libc.so.5 > #1 0x2825bb3d in abort () from /usr/lib/libc.so.5 > #2 0x2825a682 in isatty () from /usr/lib/libc.so.5 > #3 0x2825a6b0 in isatty () from /usr/lib/libc.so.5 > #4 0x2825b6a6 in malloc () from /usr/lib/libc.so.5 > #5 0x80d19ff in Xalloc (amount=16) at utils.c:1225 > #6 0x80cc30c in TimerSet (timer=0x0, flags=0, millis=50, func=0x8788ef0, > arg=0x88a0b00) at WaitFor.c:744 > #7 0x87890fa in ?? () > #8 0x878927d in ?? () > #9 0x8788bf0 in ?? () > #10 0x807da23 in xf86SigioReadInput (fd=7, closure=0x88a0b00) > at xf86Events.c:1039 > #11 0x8093d48 in xf86SIGIO (sig=23) at sigio.c:99 ^^^ This is the Big Red Truck that I missed during my debugging. > #12 0xbfbfffac in ?? () > #13 0x2825b1b0 in isatty () from /usr/lib/libc.so.5 > #14 0x2825b901 in realloc () from /usr/lib/libc.so.5 > #15 0x80d1b18 in Xrealloc (ptr=0x8eb3000, amount=4096) at utils.c:1322 > #16 0x80ceef4 in StandardReadRequestFromClient (client=0x8a0d100) at io.c:403 > #17 0x80ac00c in Dispatch () at dispatch.c:438 > #18 0x80bc395 in main (argc=3, argv=0xbfbffdc0, envp=0xbfbffdd0) at main.c:439 > #19 0x806b31d in _start () > > My understanding is that the problem is with XFree using malloc in a > signal-handler. Indeed, see above. > Strange enough, my system at home (with a Matrox G400-Card and Xfree86-4.1.0) > does not show this symptom. Indeed, again, I believe it was fixed before that release was, er, released. This is also fixed in cvs. XFree86, is zarking cool. You would enjoy the upgrade. > Michael Daniel M. Kurry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: X in free(): error: recursive call.
On Sun, Jul 29, 2001 at 10:29:40PM +0800, some SMTP stream spewed forth: > I am running -CURRENT as of 2001/01/31 12:00, more or less uneventfully > for the last six months on a Dell 5000e. > > The one problem is that X occasionally dies without coredump or cleanup with > the error 'X in free(): error: recursive call.'. This usually (but not > always) happens while using Mozilla with heavy window creation/deletion and > heavy (dialup) network activity. This has happened under several recent > versions of Mozilla, two different versions of fvwm2, with and without > session managers, and with both X 4.0.3 and 4.1.0. *ding* So I'm not alone on this. I experienced this a while back running XF86 HEAD from cvs. The developers tracked it down to a signal handler calling malloc/free through the 3-button emulation code. You could be experiencing something completely different, but they fixed my particular version of this problem in cvs a couple months ago (I believe). When experiencing the "crash", I would be heavily "clicking", opening/moving/hiding/showing windows. > It took me a while to identify the problem, because it happens infrequently, > unpredicably, and leaves the video drivers in an unusable state (forcing a > blind reboot). I tried linking /etc/malloc.conf to 'A' to get a coredump > from X, but that doesn't work. I found a very short discussion of a related > problem in the -CURRENT mail archives from the beginning of January, but > there wasn't any apparent resolution of the problem. This was discussed on the XFree86 lists, which you probably weren't reading, being using a release. > I'd like to get advice on which of the following courses of action to take: > > 1. Isolate and fix the problem. I would need some help here. You /could/ fire up a copy of gdb on the server binary, but I believe there are some messes with the modules XFree86 uses. (Don't take my word for this, I know largely nothing about debugging X.) > 2. Downgrade to -STABLE. The reason I was running -CURRENT originally was > for ACPI support, but Dell has since released an APM-enabled BIOS for > the 5000e, so -CURRENT is no longer a requirement. This seems very much *not* a FreeBSD problem. > 3. Upgrade to current -CURRENT. I don't know if this is such a good idea > judging from mailing list traffic. Same as above, NAFP. > 4. Hang in with the status quo for another couple months until 5.0 is > released, install that, and start back at #1 if that doesn't work. Yet again, NAFP. > Any advice, comments, or suggestions warmly appreciated. Can you run a CVS version of XFree86? I believe this was repaired in one of the more-recent (most-, possibly) 4.x releases. > Thanks. > > -Michael Robinson G'luck, cheers. Daniel M. Kurry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
