Re: new panic in cpu_reset() with WITNESS
on 20/01/2012 17:41 Gleb Smirnoff said the following: > > On Tue, Jan 17, 2012 at 03:02:42PM +0400, Gleb Smirnoff wrote: > T> New panic has been introduced somewhere between > T> r229851 and r229932, that happens on shutdown if > T> kernel has WITNESS and doesn't have WITNESS_SKIPSPIN. > > I've run through binary search and panic was introduced > by r229854. > Which means that it was introduced by one of the earlier commits (probably mine). Thank you for this investigative work! Although, to be frank and honest, I still don't see how the problem could be a non-issue before. So any help/ideas/guesses are appreciated. P.S. I also have a big suspicion that we have more problems that can be triggered by WITNESS && !WITNESS_SKIPSPIN, but which are harmless in practice. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFT] Major snd_hda rewrite
On 01/21/12 15:17, Mickaël Maillot wrote: So i tried DTS-HDMA and Dolby TrueHD without success. when i play DTS-HDMA, my receiver display DTS-HR and seams to play dts core with lots of interruptions. and when i play TrueHD, my receiver display TrueHD but doesn't play anything. From that description I can conclude that you are passing through compressed DTS-HD and TrueHD streams to the receiver. What are the bitrates of streams you are playing? It looks like your receiver doesn't receives all data. If I understand right, to transfer with compressed bitrates above 6.144Mbps special High Bit Rate mode should be activated in CODEC, when data stream occupies all 8 HDMI channels instead of 2. I haven't implemented this feature yet as my receiver doesn't support such HD formats. I'll try to make a patch for it a bit later and send you to try. Until that time, is it possible to make your xbmc to decode those HD streams into different number of uncompressed LPCM channels to play it that way? It would be interesting to test 6.0, 6.1, 7.0 and 7.1 LPCM configurations with your receiver. Or at least normal definition 7.1 playback would be interesting to test (you can just set vchanformat to s16le:7.1 or s32le:7.1 and play anything). and sysctl show: dev.pcm.4.play.vchanmode: passthrough dev.pcm.4.play.vchanrate: 192000 dev.pcm.4.play.vchanformat: ac3:2.0 i tried without vchan with same results. i can't set more than 2 channels for my hdmi output (dsp4), i want to set 8 channels like alsa does. What do you mean that you can't set more then 2 channels? I've never tried to set ac3 format with more then 2 channels, but s16le:7.1 and s32le:7.1 should work fine. At least s16le:5.1 and s32le:5.1 are working perfectly for me. For HDA 24bit samples stored in memory as 32bit, so setting s24le format only cause extra 24->32bit conversion. i never show things like PCMDIR_...: Stream setup in my messages, so may be i use oss wrongly. They are printed only when hw.snd.verbose set to 4. you can find the source code of xbmc used to play losseless file here: https://github.com/Fneufneu/xbmc/blob/freebsdAE/xbmc/cores/AudioEngine/Sinks/AESinkOSS.cpp and my dmesg: http://fneufn.eu/freebsd/dmesg.verb.htpc.20120121.txt -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
locks under printf(9) and WITNESS [Was: new panic in cpu_reset() with WITNESS]
BTW, we have a quite strange situation with spin locks in console output path. cnputs_mtx is marked as MTX_NOWITNESS, supposedly because cnputs (printf) can be called in any locking context (even during normal operation). But there are a number of console-specific locks (scrlock, uart_hwmtx, "syscons video lock") which are acquired under cnputs_mtx, but which are *not* marked as MTX_NOWITNESS. More, they are specified in the witness order_lists as if we certainly know a correct order for them. I think that the msgbuf mutex also deserves mentioning in this context. I think that all of these spin locks should be marked as MTX_NOWITNESS (as long as they stay normal spinlocks), because printf(9) should be usable wherever I stick it in the code. P.S. The above only matters for WITNESS and !WITNESS_SKIPSPIN and I am not sure if this combination really matters. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFT] Major snd_hda rewrite
On 01/21/12 16:28, Alexander Motin wrote: On 01/21/12 15:17, Mickaël Maillot wrote: So i tried DTS-HDMA and Dolby TrueHD without success. when i play DTS-HDMA, my receiver display DTS-HR and seams to play dts core with lots of interruptions. and when i play TrueHD, my receiver display TrueHD but doesn't play anything. From that description I can conclude that you are passing through compressed DTS-HD and TrueHD streams to the receiver. What are the bitrates of streams you are playing? It looks like your receiver doesn't receives all data. If I understand right, to transfer with compressed bitrates above 6.144Mbps special High Bit Rate mode should be activated in CODEC, when data stream occupies all 8 HDMI channels instead of 2. I haven't implemented this feature yet as my receiver doesn't support such HD formats. I'll try to make a patch for it a bit later and send you to try. Until that time, is it possible to make your xbmc to decode those HD streams into different number of uncompressed LPCM channels to play it that way? It would be interesting to test 6.0, 6.1, 7.0 and 7.1 LPCM configurations with your receiver. Or at least normal definition 7.1 playback would be interesting to test (you can just set vchanformat to s16le:7.1 or s32le:7.1 and play anything). I mean "play anything uncompressed". and sysctl show: dev.pcm.4.play.vchanmode: passthrough dev.pcm.4.play.vchanrate: 192000 dev.pcm.4.play.vchanformat: ac3:2.0 i tried without vchan with same results. i can't set more than 2 channels for my hdmi output (dsp4), i want to set 8 channels like alsa does. What do you mean that you can't set more then 2 channels? I've never tried to set ac3 format with more then 2 channels, but s16le:7.1 and s32le:7.1 should work fine. At least s16le:5.1 and s32le:5.1 are working perfectly for me. For HDA 24bit samples stored in memory as 32bit, so setting s24le format only cause extra 24->32bit conversion. i never show things like PCMDIR_...: Stream setup in my messages, so may be i use oss wrongly. They are printed only when hw.snd.verbose set to 4. you can find the source code of xbmc used to play losseless file here: https://github.com/Fneufneu/xbmc/blob/freebsdAE/xbmc/cores/AudioEngine/Sinks/AESinkOSS.cpp and my dmesg: http://fneufn.eu/freebsd/dmesg.verb.htpc.20120121.txt -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFT] Major snd_hda rewrite
Hello, On 11/01/2012 20:33, Alexander Motin wrote: I would like request for testing of my work on further HDA sound driver improvement. ... Comments and tests results are welcome! I've been testing the first version of your patch on an HP 6510b, since the 12th of January. hdac0@pci0:0:27:0: class=0x040300 card=0x30c0103c chip=0x284b8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) HD Audio Controller' class = multimedia subclass = HDA mixer Mixer vol is currently set to 80:80 Mixer bass is currently set to 75:75 Mixer treble is currently set to 40:40 Mixer pcm is currently set to 100:100 Mixer speaker is currently set to 0:0 Mixer line is currently set to 0:0 Mixer mic is currently set to 0:0 Mixer rec is currently set to 50:50 Mixer igainis currently set to 0:0 Mixer ogainis currently set to 0:0 Mixer monitor is currently set to 0:0 Recording source: monitor So far I haven't encountered any regressions. There are however some small issues that also are present with the old driver. I have the following selection of recording devices: Mixer line is currently set to 0:0 Mixer mic is currently set to 0:0 Mixer monitor is currently set to 0:0 To record from the microphone, I have to use the monitor device: Recording source: monitor Physically neither the notebook nor the docking station have a line in socket. Of course such a thing might simply be on board and NC. Setting a volume for line, mic or monitor has no effect. To hear the microphone on my speakers/headphones I have to use igain instead. Igain sets the microphone volume independent of the recording source. There's also ogain, which doesn't seem to do anything either. What I expect is that the recording source for the microphone was mic and that the monitor recording source could be used to record the cumulative output of all channels. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFT] Major snd_hda rewrite
On 01/21/12 18:24, Dominic Fandrey wrote: Hello, On 11/01/2012 20:33, Alexander Motin wrote: I would like request for testing of my work on further HDA sound driver improvement. ... Comments and tests results are welcome! I've been testing the first version of your patch on an HP 6510b, since the 12th of January. hdac0@pci0:0:27:0: class=0x040300 card=0x30c0103c chip=0x284b8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) HD Audio Controller' class = multimedia subclass = HDA mixer Mixer vol is currently set to 80:80 Mixer bass is currently set to 75:75 Mixer treble is currently set to 40:40 Mixer pcm is currently set to 100:100 Mixer speaker is currently set to 0:0 Mixer line is currently set to 0:0 Mixer mic is currently set to 0:0 Mixer rec is currently set to 50:50 Mixer igain is currently set to 0:0 Mixer ogain is currently set to 0:0 Mixer monitor is currently set to 0:0 Recording source: monitor So far I haven't encountered any regressions. There are however some small issues that also are present with the old driver. I have the following selection of recording devices: Mixer line is currently set to 0:0 Mixer mic is currently set to 0:0 Mixer monitor is currently set to 0:0 To record from the microphone, I have to use the monitor device: Recording source: monitor monitor is a name used for the second (or built-in) microphone. List of names in OSS is quite limited, so I had to choose one and that fit best. Physically neither the notebook nor the docking station have a line in socket. Of course such a thing might simply be on board and NC. It is question to vendor, why it haven't disabled it in codec configuration if it is not implemented in hardware. If you like, you can do it with device hints. Setting a volume for line, mic or monitor has no effect. To hear the microphone on my speakers/headphones I have to use igain instead. Difficult to say something without knowing model of codec or having verbose dmesg output. Depending on codec model, line, mic and monitor input may have or not have much controls. There may be just mutters, or may be just their volume in input monitoring. Igain sets the microphone volume independent of the recording source. As written in man page, igain controls "input-to-output monitoring loopback level". It is not used for pre-amplification as you may think, because there usually more then one input that needs that control. There's also ogain, which doesn't seem to do anything either. ogain is used to control EAPD signal, that on some laptops used to control external power amplifier. It is impossible for driver to find whether this signal is used, so it is exposed always when present. What I expect is that the recording source for the microphone was mic and that the monitor recording source could be used to record the cumulative output of all channels. About mic, it is only question of terminology. What's about mixed recording, depending on codec it may be possible in two ways: either by recording from special device called mix, or by choosing several recording sources with `mixer =rec mic ; mixer +rec monitor; mixer +rec line`. Just now I am working on complete rewrite of the volumes control in the driver. Terminology will remain the same, but number of present controls and their functionality/quality should improve. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFT] Major snd_hda rewrite
On 01/21/12 18:48, Alexander Motin wrote: On 01/21/12 18:24, Dominic Fandrey wrote: On 11/01/2012 20:33, Alexander Motin wrote: I would like request for testing of my work on further HDA sound driver improvement. ... Comments and tests results are welcome! I've been testing the first version of your patch on an HP 6510b, since the 12th of January. hdac0@pci0:0:27:0: class=0x040300 card=0x30c0103c chip=0x284b8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) HD Audio Controller' class = multimedia subclass = HDA mixer Mixer vol is currently set to 80:80 Mixer bass is currently set to 75:75 Mixer treble is currently set to 40:40 Mixer pcm is currently set to 100:100 Mixer speaker is currently set to 0:0 Mixer line is currently set to 0:0 Mixer mic is currently set to 0:0 Mixer rec is currently set to 50:50 Mixer igain is currently set to 0:0 Mixer ogain is currently set to 0:0 Mixer monitor is currently set to 0:0 Recording source: monitor So far I haven't encountered any regressions. There are however some small issues that also are present with the old driver. I have the following selection of recording devices: Mixer line is currently set to 0:0 Mixer mic is currently set to 0:0 Mixer monitor is currently set to 0:0 To record from the microphone, I have to use the monitor device: Recording source: monitor monitor is a name used for the second (or built-in) microphone. List of names in OSS is quite limited, so I had to choose one and that fit best. Physically neither the notebook nor the docking station have a line in socket. Of course such a thing might simply be on board and NC. It is question to vendor, why it haven't disabled it in codec configuration if it is not implemented in hardware. If you like, you can do it with device hints. Setting a volume for line, mic or monitor has no effect. To hear the microphone on my speakers/headphones I have to use igain instead. Difficult to say something without knowing model of codec or having verbose dmesg output. Depending on codec model, line, mic and monitor input may have or not have much controls. There may be just mutters, or may be just their volume in input monitoring. Igain sets the microphone volume independent of the recording source. As written in man page, igain controls "input-to-output monitoring loopback level". It is not used for pre-amplification as you may think, because there usually more then one input that needs that control. There's also ogain, which doesn't seem to do anything either. ogain is used to control EAPD signal, that on some laptops used to control external power amplifier. It is impossible for driver to find whether this signal is used, so it is exposed always when present. What I expect is that the recording source for the microphone was mic and that the monitor recording source could be used to record the cumulative output of all channels. About mic, it is only question of terminology. What's about mixed recording, depending on codec it may be possible in two ways: either by recording from special device called mix, or by choosing several recording sources with `mixer =rec mic ; mixer +rec monitor; mixer +rec line`. Or it may be just technically impossible. If "record the cumulative output of all channels" means you want to record from playback, then on most codecs it is technically impossible. I've seen only one or two allowing it and it is not supported now. Just now I am working on complete rewrite of the volumes control in the driver. Terminology will remain the same, but number of present controls and their functionality/quality should improve. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: new panic in cpu_reset() with WITNESS
on 21/01/2012 15:38 Andriy Gapon said the following: > on 20/01/2012 17:41 Gleb Smirnoff said the following: >> >> On Tue, Jan 17, 2012 at 03:02:42PM +0400, Gleb Smirnoff wrote: >> T> New panic has been introduced somewhere between >> T> r229851 and r229932, that happens on shutdown if >> T> kernel has WITNESS and doesn't have WITNESS_SKIPSPIN. >> >> I've run through binary search and panic was introduced >> by r229854. >> > > Which means that it was introduced by one of the earlier commits (probably > mine). Thank you for this investigative work! > Although, to be frank and honest, I still don't see how the problem could be > a non-issue before. BTW, just to be sure, does the problem go away when kern.stop_scheduler_on_panic is set to zero? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: locks under printf(9) and WITNESS [Was: new panic in cpu_reset() with WITNESS]
on 21/01/2012 16:37 Andriy Gapon said the following:
>
> BTW, we have a quite strange situation with spin locks in console output path.
> cnputs_mtx is marked as MTX_NOWITNESS, supposedly because cnputs (printf) can
> be
> called in any locking context (even during normal operation). But there are a
> number of console-specific locks (scrlock, uart_hwmtx, "syscons video lock")
> which are acquired under cnputs_mtx, but which are *not* marked as
> MTX_NOWITNESS. More, they are specified in the witness order_lists as if we
> certainly know a correct order for them.
> I think that the msgbuf mutex also deserves mentioning in this context.
>
> I think that all of these spin locks should be marked as MTX_NOWITNESS (as
> long
> as they stay normal spinlocks), because printf(9) should be usable wherever I
> stick it in the code.
>
> P.S. The above only matters for WITNESS and !WITNESS_SKIPSPIN and I am not
> sure
> if this combination really matters.
>
Here's my take at it:
diff --git a/sys/kern/kern_cons.c b/sys/kern/kern_cons.c
index 5346bc3..97f0f16 100644
--- a/sys/kern/kern_cons.c
+++ b/sys/kern/kern_cons.c
@@ -586,7 +586,7 @@ static void
cn_drvinit(void *unused)
{
- mtx_init(&cnputs_mtx, "cnputs_mtx", NULL, MTX_SPIN | MTX_NOWITNESS);
+ mtx_init(&cnputs_mtx, "cnputs_mtx", NULL, MTX_SPIN);
use_cnputs_mtx = 1;
}
diff --git a/sys/kern/subr_witness.c b/sys/kern/subr_witness.c
index 55cb2d7..39dd94d 100644
--- a/sys/kern/subr_witness.c
+++ b/sys/kern/subr_witness.c
@@ -629,7 +629,6 @@ static struct witness_order_list_entry order_lists[] = {
#endif
{ "rm.mutex_mtx", &lock_class_mtx_spin },
{ "sio", &lock_class_mtx_spin },
- { "scrlock", &lock_class_mtx_spin },
#ifdef __i386__
{ "cy", &lock_class_mtx_spin },
#endif
@@ -638,7 +637,6 @@ static struct witness_order_list_entry order_lists[] = {
{ "rtc_mtx", &lock_class_mtx_spin },
#endif
{ "scc_hwmtx", &lock_class_mtx_spin },
- { "uart_hwmtx", &lock_class_mtx_spin },
{ "fast_taskqueue", &lock_class_mtx_spin },
{ "intr table", &lock_class_mtx_spin },
#ifdef HWPMC_HOOKS
@@ -653,8 +651,8 @@ static struct witness_order_list_entry order_lists[] = {
{ "sched lock", &lock_class_mtx_spin },
{ "td_contested", &lock_class_mtx_spin },
{ "callout", &lock_class_mtx_spin },
+ { "et_hw_mtx", &lock_class_mtx_spin },
{ "entropy harvest mutex", &lock_class_mtx_spin },
- { "syscons video lock", &lock_class_mtx_spin },
#ifdef SMP
{ "smp rendezvous", &lock_class_mtx_spin },
#endif
@@ -662,6 +660,13 @@ static struct witness_order_list_entry order_lists[] = {
{ "tlb0", &lock_class_mtx_spin },
#endif
/*
+* console locks
+*/
+ { "cnputs_mtx", &lock_class_mtx_spin },
+ { "scrlock", &lock_class_mtx_spin },
+ { "syscons video lock", &lock_class_mtx_spin },
+ { "uart_hwmtx", &lock_class_mtx_spin },
+ /*
* leaf locks
*/
{ "intrcnt", &lock_class_mtx_spin },
How does this look?
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD hangs on boot after kernel upgrade to 9.0-R
Hi, I've used freebsd-update to upgrade from 8.2-R to 9.0-R and all looked nice until the first reboot. Now my FreeBSD always hangs midway through the boot process and the last message output is: "uhub3: http://www.pipni.cz/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
