>> On 09/15/2012 08:04 AM, peter@xxxxxxxxxxxxxx wrote:
>>>> i've just switched over to jack1... it fails as well, with a different
>>>> error message (don't know if this sheds any more light on the
>>>> situation!):
>>>>
>>>> plutek@palnote:~$ jackd 0.122.0
>>>> Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben
>>>> Hohn
>>>> and others.
>>>> jackd comes with ABSOLUTELY NO WARRANTY
>>>> This is free software, and you are welcome to redistribute it
>>>> under certain conditions; see the file COPYING for details
>>>>
>>>> JACK compiled with System V SHM support.
>>>> loading driver ..
>>>> apparent rate = 44100
>>>> creating alsa driver ...
>>>> hw:0,0|hw:0,0|256|2|44100|0|0|nomon|swmeter|-|32bit
>>>> control device hw:0
>>>> configuring for 44100Hz, period = 256 frames (5.8 ms), buffer = 2
>>>> periods
>>>> ALSA: final selected sample format for capture: 32bit integer
>>>> little-endian
>>>> ALSA: use 2 periods for capture
>>>> ALSA: final selected sample format for playback: 32bit integer
>>>> little-endian
>>>> ALSA: use 2 periods for playback
>>>> ALSA: prepare error for playback on "hw:0,0" (Input/output error)
>>>> DRIVER NT: could not run driver cycle
>>>>
>>>> **** alsa_pcm: xrun of at least 0.013 msecs
>>>>
>>>> thanks again for any help on this!
>>>
>>> ooops... getting rid of the extra -p flag, and going with -p1024, i get
>>> this:
>>>
>>> plutek@palnote:~$ jackd -dalsa -r44100 -p1024 -n2 -D -Chw:0,0 -Phw:0,0&
>>> [1] 3580
>>> plutek@palnote:~$ jackd 0.122.0
>>> Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben
>>> Hohn
>>> and others.
>>> jackd comes with ABSOLUTELY NO WARRANTY
>>> This is free software, and you are welcome to redistribute it
>>> under certain conditions; see the file COPYING for details
>>>
>>> JACK compiled with System V SHM support.
>>> loading driver ..
>>> apparent rate = 44100
>>> creating alsa driver ...
>>> hw:0,0|hw:0,0|1024|2|44100|0|0|nomon|swmeter|-|32bit
>>> control device hw:0
>>> configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 2
>>> periods
>>> ALSA: final selected sample format for capture: 32bit integer
>>> little-endian
>>> ALSA: use 2 periods for capture
>>> ALSA: final selected sample format for playback: 32bit integer
>>> little-endian
>>> ALSA: use 2 periods for playback
>>> jackd watchdog: timeout - killing jackd
>>
>> All errors seem to point to a problem with interrupts. Somehow the
>> kernel is not handling interrupts from the soundcard, or the soundcard
>> is not generating them. Jack's driver waits for them and they never
>> arrive and as a result eventually the watchdog kills the whole thing in
>> the case of jack1.
>>
>> Anything in /var/log/messages?
>
> maybe, if i knew what to look for! ;-)
>
> comparing a 3.2.0 (jack fails) boot with a 3.1-6 (jack is ok) boot, i
> noticed two things:
>
> 3.2.0: NMI watchdog is active (disabling it via kernel params didn't fix
> jack)
>
> BOTH show this:
> Sep 15 10:52:17 palnote kernel: [ 0.810792] pci 0000:00:1c.3: PCI INT D
> -> GSI 19 (level, low) -> IRQ 19
> Sep 15 10:52:17 palnote kernel: [ 1.391566] firewire_ohci 0000:0d:00.3:
> PCI INT D -> GSI 19 (level, low) -> IRQ 19
> Sep 15 10:52:17 palnote kernel: [ 1.567717] ahci 0000:00:1f.2: PCI INT
> B -> GSI 19 (level, low) -> IRQ 19
> Sep 15 10:52:17 palnote kernel: [ 11.827204] snd_hdsp 0000:05:00.0: PCI
> INT A -> GSI 19 (level, low) -> IRQ 19
>
> so, perhaps the hdsp sharing IRQ 19 with ohci and ahci is not a good
> thing?? but that's the same in BOTH boots, so i dunno....
>
> anything else i should look for, or any other info you might be interested
> in seeing?
>
> big thanks for any help on this, fernando!!
>
> cheers!
> .pltk.
>
here's rtirq status from the running system:
----------3.2 kernel (jack bad)-------------
root@palnote:/home/plutek# /etc/init.d/rtirq status
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
44 FF 90 - 130 0.0 S irq/8-rtc0
649 FF 85 - 125 0.0 S irq/42-snd_hda_
658 FF 85 - 125 0.0 S irq/19-snd_hdsp
197 FF 80 - 120 0.0 S irq/16-ehci_hcd
209 FF 79 - 119 0.1 S irq/23-ehci_hcd
43 FF 75 - 115 0.0 S irq/1-i8042
42 FF 74 - 114 0.0 S irq/12-i8042
33 FF 50 - 90 0.0 S irq/9-acpi
154 FF 50 - 90 0.0 S irq/16-mmc0
194 FF 50 - 90 0.0 S irq/19-firewire
198 FF 50 - 90 0.0 S irq/41-ahci
676 FF 50 - 90 0.0 S irq/17-rtlwifi
731 FF 50 - 90 0.0 S irq/43-i915
2351 FF 50 - 90 0.0 S irq/40-eth0
3 FF 1 - 41 0.1 S ksoftirqd/0
12 FF 1 - 41 0.0 S ksoftirqd/1
18 FF 1 - 41 0.1 S ksoftirqd/2
23 FF 1 - 41 0.0 S ksoftirqd/3
-----------3.1 kernel (jack good)----------------
root@palnote:/home/plutek# /etc/init.d/rtirq status
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
45 FF 90 - 130 0.0 S irq/8-rtc0
611 FF 85 - 125 0.0 S irq/19-snd_hdsp
615 FF 85 - 125 0.0 S irq/43-snd_hda_
179 FF 80 - 120 0.0 S irq/16-ehci_hcd
180 FF 79 - 119 0.0 S irq/23-ehci_hcd
43 FF 75 - 115 0.0 S irq/1-i8042
42 FF 74 - 114 0.0 S irq/12-i8042
33 FF 50 - 90 0.0 S irq/9-acpi
174 FF 50 - 90 0.0 S irq/41-firewire
177 FF 50 - 90 0.0 S irq/16-mmc0
182 FF 50 - 90 0.2 S irq/42-ahci
614 FF 50 - 90 0.0 S irq/16-mei
643 FF 50 - 90 0.0 S irq/17-rtlwifi
688 FF 50 - 90 0.0 S irq/44-i915
2081 FF 50 - 90 0.0 S irq/40-eth0
3 TS - 0 19 0.1 S ksoftirqd/0
15 TS - 0 19 0.1 R ksoftirqd/1
20 TS - 0 19 0.0 S ksoftirqd/2
24 TS - 0 19 0.0 S ksoftirqd/3
i usually run a script which kills snd_hda_* anyways, so snd_hdsp is on
it's own in rtprio. however, i do notice that (contrary to the msgs in
/var/log/messages) irq/19 is NOT shared under the 3.1 kernel, but it IS
shared under the 3.2 kernel.
is this possibly a critical factor?
can it be fixed by changing the rtirq config:
CHANGE THIS: RTIRQ_NAME_LIST="rtc snd usb i8042
TO: RTIRQ_NAME_LIST="rtc snd_hdsp snd usb i8042
(or REPLACE snd with snd_hdsp ?????)
perhaps i'll go experiment........
cheers!
.pltk.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
