Thread: Re: playback-only code in snd-dice?
Brought to you by:
aeb,
bencollins
From: Takashi S. <o-t...@sa...> - 2014-10-10 07:09:27
|
On Oct 10 2014 16:06, Clemens Ladisch wrote: > Daniel Robbins wrote: >> With kernel 3.17.0, it now looks like firewire-ohci is misbehaving: >> >> [ 2.723177] firewire_ohci 0000:06:00.0: failed to allocate interrupt 20 >> [ 2.723206] firewire_ohci: probe of 0000:06:00.0 failed with error -5 >> >> 3.16.0 worked with your fixes... now that the fixes are in 3.17.0, firewire-ohci appears broken. > > This has nothing to do with the sound driver. Indeed. > Please show the "lspci -nnvv" entry of the controller, and the entire log. > Is there any other driver on IRQ 20? Output from /proc/interrupts will be our help, too. Regards Takashi Sakamoto o-t...@sa... |
From: Clemens L. <cl...@la...> - 2014-10-10 07:31:29
|
Daniel Robbins wrote: > With kernel 3.17.0, it now looks like firewire-ohci is misbehaving: > > [ 2.723177] firewire_ohci 0000:06:00.0: failed to allocate interrupt 20 > [ 2.723206] firewire_ohci: probe of 0000:06:00.0 failed with error -5 > > 3.16.0 worked with your fixes... now that the fixes are in 3.17.0, firewire-ohci appears broken. This has nothing to do with the sound driver. Please show the "lspci -nnvv" entry of the controller, and the entire log. Is there any other driver on IRQ 20? Regards, Clemens |
From: Clemens L. <cl...@la...> - 2014-10-16 17:48:54
|
Daniel Robbins wrote: > Okay, nothing else on IRQ 20, which is why it is so odd. Please show the entire boot log. Regards, Clemens |
From: Clemens L. <cl...@la...> - 2014-10-19 19:10:32
|
Daniel Robbins wrote: > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level) > [ 2.699224] firewire_ohci 0000:06:00.0: failed to allocate interrupt 20 Interrupt 20 is actually interrupt 9, which is already used for ACPI events. (At least this is what the kernel thinks what the BIOS tells it.) In theory, the controller's "20" is bus_irq, which should not conflict. Could you bisect the kernel? Is this a controller card which you could plug into a different slot? Or could you update the motherboard BIOS? Regards, Clemens |
From: Jiang L. <jia...@li...> - 2014-10-20 15:57:48
|
Hi Daniel, Thanks for bisecting and seems the regression is caused by the commit. But I can't find the full dmesg file posted by you through googling:(. So could you please help to send the full dmesg text with the failure kernel? Another dmesg with the working kernel (v3.16) is preferred too. Please also send me the output of "acpidump > acpi.bin". Regards! Gerry On 2014/10/20 5:59, Daniel Robbins wrote: > I have identified the bad commit: > > plex linux-git # git bisect good > 84245af7297ced9e8fe837dc0fc4782438771bd2 is the first bad commit > commit 84245af7297ced9e8fe837dc0fc4782438771bd2 > Author: Jiang Liu <jia...@li...> > Date: Tue Jun 10 14:14:47 2014 +0800 > > x86, irq, ACPI: Change __acpi_register_gsi to return IRQ number > instead of GSI > > Currently __acpi_register_gsi is defined to return GSI number and > may be set to acpi_register_gsi_pic(), acpi_register_gsi_ioapic(), > acpi_register_gsi_xen_hvm() and acpi_register_gsi_xen(). > > Among which, acpi_register_gsi_ioapic() returns GSI number, but > acpi_register_gsi_xen_hvm() and acpi_register_gsi_xen() actually > returns IRQ number instead of GSI. And for acpi_register_gsi_pic(), > GSI number equals to IRQ number. > > So change acpi_register_gsi_ioapic() to return IRQ number, it also > simplifies the code. > > Signed-off-by: Jiang Liu <jia...@li...> > Cc: Konrad Rzeszutek Wilk <kon...@or...> > Cc: Tony Luck <ton...@in...> > Cc: Joerg Roedel <jo...@8b...> > Cc: Paul Gortmaker <pau...@wi...> > Cc: Greg Kroah-Hartman <gr...@li...> > Cc: Benjamin Herrenschmidt <be...@ke...> > Cc: Grant Likely <gra...@li...> > Cc: Rafael J. Wysocki <rj...@rj...> > Cc: Bjorn Helgaas <bhe...@go...> > Cc: Randy Dunlap <rd...@in...> > Cc: Yinghai Lu <yi...@ke...> > Cc: Len Brown <len...@in...> > Cc: Pavel Machek <pa...@uc...> > Link: http://lkml.kernel.org/r/140...@li... > Signed-off-by: Thomas Gleixner <tg...@li...> > > :040000 040000 e2ffe2a09062cc3fd40f2367a3f5e47fe3852277 > 9b690563070c3d0de56a9c950e32cb2def10d08f M arch > > On Sun, Oct 19, 2014 at 1:40 PM, Daniel Robbins <dro...@fu...> wrote: >> And I will start a bisect between 3.16.0 and 3.17.0 and see what is causing >> this.... >> >> -Daniel >> >> On Sun, Oct 19, 2014 at 1:16 PM, Daniel Robbins <dro...@fu...> wrote: >>> >>> This board only has one PCI slot, and I believe it is using the latest >>> BIOS. >>> >>> I am attaching dmesg from 3.16.0, where the firewire card is handled just >>> fine (using it to listen to music right now :) I am curious why it works >>> fine with 3.16.0 and not with 3.17.0+. >>> >>> -Daniel >>> >>> On Sun, Oct 19, 2014 at 1:10 PM, Clemens Ladisch <cl...@la...> >>> wrote: >>>> >>>> Daniel Robbins wrote: >>>>> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low >>>>> level) >>>>> [ 2.699224] firewire_ohci 0000:06:00.0: failed to allocate interrupt >>>>> 20 >>>> >>>> Interrupt 20 is actually interrupt 9, which is already used for ACPI >>>> events. >>>> (At least this is what the kernel thinks what the BIOS tells it.) >>>> >>>> In theory, the controller's "20" is bus_irq, which should not conflict. >>>> Could you bisect the kernel? >>>> >>>> Is this a controller card which you could plug into a different slot? >>>> Or could you update the motherboard BIOS? >>>> >>>> >>>> Regards, >>>> Clemens >>> >>> >> |
From: Daniel R. <dro...@fu...> - 2014-10-22 18:25:54
|
All, Gerry resolved this issue. It was indeed a regression in the interrupt code affecting 3.17+. I happen to have a SuperMicro motherboard that has a weird interrupt setup. Gerry, thanks for your help! :) I am attaching the fix below for reference. I now have firewire audio working with 3.17.1. But I still have to hack the kernel sources to get this to work... the remaining problem with dice.c is the fact that it disables itself if it sees that the device has record capabilities, assuming you will use FFADO. Well, guess what? I would just like my firewire audio to just work in-kernel without modifying source code. I request that you remove this artificial limitation of the driver. My Mytek DSD DAC is used for playback only, so just because a device advertises record capability doesn't actually mean it is a record device in practice. The module should load and function, and if the user doesn't want to use it, they can blacklist it. My opinion of course, but what good reason is there to have snd-dice *not* function without hacking source code when it could by default? Regards, Daniel Gerry's IRQ fix patch for my SuperMicro X8SIL motherboard below: diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index b436fc735aa4..1cf3354845cf 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -396,8 +396,10 @@ static int mp_register_gsi(struct device *dev, u32 gsi, int trigger, return gsi; /* Don't set up the ACPI SCI because it's already set up */ - if (acpi_gbl_FADT.sci_interrupt == gsi) - return gsi; + if (acpi_gbl_FADT.sci_interrupt == gsi) { + pr_warn("irqdomain: shared GSI between SCI and PCI\n"); + return mp_map_gsi_to_irq(gsi, 0); + } trigger = trigger == ACPI_EDGE_SENSITIVE ? 0 : 1; polarity = polarity == ACPI_ACTIVE_HIGH ? 0 : 1; @@ -508,7 +510,7 @@ acpi_parse_int_src_ovr(struct acpi_subtable_header * On Mon, Oct 20, 2014 at 9:56 AM, Jiang Liu <jia...@li...> wrote: > Hi Daniel, > Thanks for bisecting and seems the regression is caused > by the commit. But I can't find the full dmesg file posted by you > through googling:(. So could you please help to send the full dmesg > text with the failure kernel? Another dmesg with the working kernel > (v3.16) is preferred too. > Please also send me the output of "acpidump > acpi.bin". > Regards! > Gerry > > On 2014/10/20 5:59, Daniel Robbins wrote: >> I have identified the bad commit: >> >> plex linux-git # git bisect good >> 84245af7297ced9e8fe837dc0fc4782438771bd2 is the first bad commit >> commit 84245af7297ced9e8fe837dc0fc4782438771bd2 >> Author: Jiang Liu <jia...@li...> >> Date: Tue Jun 10 14:14:47 2014 +0800 >> >> x86, irq, ACPI: Change __acpi_register_gsi to return IRQ number >> instead of GSI >> >> Currently __acpi_register_gsi is defined to return GSI number and >> may be set to acpi_register_gsi_pic(), acpi_register_gsi_ioapic(), >> acpi_register_gsi_xen_hvm() and acpi_register_gsi_xen(). >> >> Among which, acpi_register_gsi_ioapic() returns GSI number, but >> acpi_register_gsi_xen_hvm() and acpi_register_gsi_xen() actually >> returns IRQ number instead of GSI. And for acpi_register_gsi_pic(), >> GSI number equals to IRQ number. >> >> So change acpi_register_gsi_ioapic() to return IRQ number, it also >> simplifies the code. >> >> Signed-off-by: Jiang Liu <jia...@li...> >> Cc: Konrad Rzeszutek Wilk <kon...@or...> >> Cc: Tony Luck <ton...@in...> >> Cc: Joerg Roedel <jo...@8b...> >> Cc: Paul Gortmaker <pau...@wi...> >> Cc: Greg Kroah-Hartman <gr...@li...> >> Cc: Benjamin Herrenschmidt <be...@ke...> >> Cc: Grant Likely <gra...@li...> >> Cc: Rafael J. Wysocki <rj...@rj...> >> Cc: Bjorn Helgaas <bhe...@go...> >> Cc: Randy Dunlap <rd...@in...> >> Cc: Yinghai Lu <yi...@ke...> >> Cc: Len Brown <len...@in...> >> Cc: Pavel Machek <pa...@uc...> >> Link: http://lkml.kernel.org/r/140...@li... >> Signed-off-by: Thomas Gleixner <tg...@li...> >> >> :040000 040000 e2ffe2a09062cc3fd40f2367a3f5e47fe3852277 >> 9b690563070c3d0de56a9c950e32cb2def10d08f M arch >> >> On Sun, Oct 19, 2014 at 1:40 PM, Daniel Robbins <dro...@fu...> wrote: >>> And I will start a bisect between 3.16.0 and 3.17.0 and see what is causing >>> this.... >>> >>> -Daniel >>> >>> On Sun, Oct 19, 2014 at 1:16 PM, Daniel Robbins <dro...@fu...> wrote: >>>> >>>> This board only has one PCI slot, and I believe it is using the latest >>>> BIOS. >>>> >>>> I am attaching dmesg from 3.16.0, where the firewire card is handled just >>>> fine (using it to listen to music right now :) I am curious why it works >>>> fine with 3.16.0 and not with 3.17.0+. >>>> >>>> -Daniel >>>> >>>> On Sun, Oct 19, 2014 at 1:10 PM, Clemens Ladisch <cl...@la...> >>>> wrote: >>>>> >>>>> Daniel Robbins wrote: >>>>>> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low >>>>>> level) >>>>>> [ 2.699224] firewire_ohci 0000:06:00.0: failed to allocate interrupt >>>>>> 20 >>>>> >>>>> Interrupt 20 is actually interrupt 9, which is already used for ACPI >>>>> events. >>>>> (At least this is what the kernel thinks what the BIOS tells it.) >>>>> >>>>> In theory, the controller's "20" is bus_irq, which should not conflict. >>>>> Could you bisect the kernel? >>>>> >>>>> Is this a controller card which you could plug into a different slot? >>>>> Or could you update the motherboard BIOS? >>>>> >>>>> >>>>> Regards, >>>>> Clemens >>>> >>>> >>> |
From: Stefan R. <st...@s5...> - 2014-10-22 20:33:12
|
On Oct 22 Daniel Robbins wrote: > I now have firewire audio working with 3.17.1. But I still have to > hack the kernel sources to get this to work... the remaining problem > with dice.c is the fact that it disables itself if it sees that the > device has record capabilities, assuming you will use FFADO. With a little bit more patching than that, you could even modify the driver to support capture: https://github.com/takaswie/snd-firewire-improve . (I haven't tested this myself yet.) > Well, guess what? I would just like my firewire audio to just work > in-kernel without modifying source code. I request that you remove this > artificial limitation of the driver. I too would be in favor of this limitation being lifted (unless Sakamoto-san's work goes into the mainline sooner, of course), but with a qualification; see below. > My Mytek DSD DAC is used for playback only, so just because a device > advertises record capability doesn't actually mean it is a record > device in practice. The module should load and function, and if the > user doesn't want to use it, they can blacklist it. My opinion of > course, but what good reason is there to have snd-dice *not* function > without hacking source code when it could by default? For users of DICE devices for recording, it would currently be a regression if the kernel prevented FFADO from accessing the device. There would be two alternative solutions: Either recording users would need to add a module blacklist rule on their systems. Or the playback-only driver would be extended by a module parameter that tells it to bind to bidi devices too, and that parameter would be off by default. With the second approach, users who only require playback through their bidi device would have to add a module parameter config on their systems, while users who want to record do not need to reconfigure anything. -- Stefan Richter -=====-====- =-=- =-==- http://arcgraph.de/sr/ |
From: Daniel R. <dro...@fu...> - 2014-10-22 22:34:29
|
I consider audio playback a more general function of the kernel that is used much more often and something that should "just work". For finding the best solution for Linux users, it is often a good idea to consider potential use cases. So let's look at both: If you are doing audio recording, you are performing additional setup (including recording app, drivers, microphones) and blacklisting a module as part of this already more involved process is not unreasonable. You are not likely to be inconvenienced significantly by performing this step as it is a small part of a larger and more ambitious goal. It requires a slight change in user behavior but is not what I would consider a regression. Now consider the person using dice just for playback, maybe just to listen to music through their stereo with their fancy new DAC, and hoping to use Linux, but with access to maybe Windows or MacOS systems, so they are not willing to invest a ton of time in making this work on Linux (I am more the exception than the rule.) If they are using a pre-built kernel, they are currently stuck with no audio. Not a good situation. Specifying a kernel boot option for audio playback to work requires an additional step that most users will not perform since they will not be aware that it is required. They will just not have audio, and will not look at the kernel sources to see why, and think it is broken. So they will abandon Linux for streaming music to their DAC. Also not a good situation. So, I think it's clear what option provides the optimal user experience that is most likely to allow people to benefit from Linux support for this hardware. I consider the current behavior to be a regression in _behavior_ for a module, which is almost always: "if I am 'modprobe'd, and I find a device that I support, then I will function as expected with no additional kernel-related configuration options.' This is the norm that users expect. So when there is deviation from this norm, that is something that is more of a true regression, in my opinon. Thanks to everyone who has helped to provide such high-quality firewire sound drivers for Linux. -Daniel On Wed, Oct 22, 2014 at 2:32 PM, Stefan Richter <st...@s5...> wrote: > On Oct 22 Daniel Robbins wrote: >> I now have firewire audio working with 3.17.1. But I still have to >> hack the kernel sources to get this to work... the remaining problem >> with dice.c is the fact that it disables itself if it sees that the >> device has record capabilities, assuming you will use FFADO. > > With a little bit more patching than that, you could even modify the > driver to support capture: > https://github.com/takaswie/snd-firewire-improve . > (I haven't tested this myself yet.) > >> Well, guess what? I would just like my firewire audio to just work >> in-kernel without modifying source code. I request that you remove this >> artificial limitation of the driver. > > I too would be in favor of this limitation being lifted (unless > Sakamoto-san's work goes into the mainline sooner, of course), but with a > qualification; see below. > >> My Mytek DSD DAC is used for playback only, so just because a device >> advertises record capability doesn't actually mean it is a record >> device in practice. The module should load and function, and if the >> user doesn't want to use it, they can blacklist it. My opinion of >> course, but what good reason is there to have snd-dice *not* function >> without hacking source code when it could by default? > > For users of DICE devices for recording, it would currently be a regression > if the kernel prevented FFADO from accessing the device. There would be > two alternative solutions: Either recording users would need to add a > module blacklist rule on their systems. Or the playback-only driver > would be extended by a module parameter that tells it to bind to bidi > devices too, and that parameter would be off by default. With the > second approach, users who only require playback through their bidi device > would have to add a module parameter config on their systems, while users > who want to record do not need to reconfigure anything. > -- > Stefan Richter > -=====-====- =-=- =-==- > http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2014-10-23 07:54:20
|
On Oct 22 Daniel Robbins wrote: > I consider audio playback a more general function of the kernel that > is used much more often and something that should "just work". For > finding the best solution for Linux users, it is often a good idea to > consider potential use cases. So let's look at both: > > If you are doing audio recording, you are performing additional setup > (including recording app, drivers, microphones) and blacklisting a > module as part of this already more involved process is not > unreasonable. You are not likely to be inconvenienced significantly by > performing this step as it is a small part of a larger and more > ambitious goal. It requires a slight change in user behavior but is > not what I would consider a regression. (We did in fact already inconvenience many FFADO users when we replaced the ieee1394 driver family by the firewire driver family, and discovered several driver bugs/ libraw1394 bugs/ previously hidden hardware quirks that had to be resolved. And we will somewhat inconvenience FFADO users again, but hopefully create less trouble than before, while Sakamoto-san's bidirectional FireWire ALSA drivers are being merged into the mainline kernel.) > Now consider the person using dice just for playback, maybe just to > listen to music through their stereo with their fancy new DAC, and > hoping to use Linux, but with access to maybe Windows or MacOS > systems, so they are not willing to invest a ton of time in making > this work on Linux (I am more the exception than the rule.) If they > are using a pre-built kernel, they are currently stuck with no audio. > Not a good situation. Specifying a kernel boot option for audio > playback to work requires an additional step that most users will not > perform since they will not be aware that it is required. They will > just not have audio, and will not look at the kernel sources to see > why, and think it is broken. So they will abandon Linux for streaming > music to their DAC. Also not a good situation. > > So, I think it's clear what option provides the optimal user > experience that is most likely to allow people to benefit from Linux > support for this hardware. I consider the current behavior to be a > regression in _behavior_ for a module, which is almost always: "if I > am 'modprobe'd, and I find a device that I support, then I will > function as expected with no additional kernel-related configuration > options.' This is the norm that users expect. So when there is > deviation from this norm, that is something that is more of a true > regression, in my opinon. You are raising valid points; on the other hand consider this: - kernels 3.12 and older: - support bidirectional DICE devices via FFADO out of the box (the limitation to bidi is FFADO's, not the kernel's) - do not support support DICE via ALSA - kernels 3.13...3.18: - still support bidi DICE via FFADO out of the box - newly support unidi DICE via ALSA out of the box - still do not support bidi DICE via ALSA So there is currently a other-OS-to-Linux regression, but no Linux-to-Linux regression. > Thanks to everyone who has helped to provide such high-quality > firewire sound drivers for Linux. > > -Daniel -- Stefan Richter -=====-====- =-=- =-=== http://arcgraph.de/sr/ |
From: Daniel R. <dro...@fu...> - 2014-10-10 14:51:38
|
Okay, nothing else on IRQ 20, which is why it is so odd. Yes, and essentially no change to the firewire code since 3.16.0. Hmmm. 06:00.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB82AA2 IEEE-1394b Link Layer Controller [104c:8025] (rev 01) (prog-if 1 0 [OHCI]) Subsystem: Texas Instruments TSB82AA2 IEEE-1394b Link Layer Controller [104c:8025] Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 20 Region 0: Memory at fbffb800 (32-bit, non-prefetchable) [size=2K] Region 1: Memory at fbffc000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel modules: firewire_ohci plex drobbins # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 126 0 0 0 IO-APIC-edge timer 1: 1 0 0 2 IO-APIC-edge i8042 8: 0 0 0 66 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 0 0 4 IO-APIC-edge i8042 18: 0 0 0 0 IO-APIC 18-fasteoi i801_smbus 21: 0 72 0 0 IO-APIC 21-fasteoi ehci_hcd:usb1 23: 0 0 34 0 IO-APIC 23-fasteoi ehci_hcd:usb2 24: 38508094 0 0 0 HPET_MSI-edge hpet2 25: 0 36516288 0 0 HPET_MSI-edge hpet3 26: 0 0 36180322 0 HPET_MSI-edge hpet4 27: 0 0 0 34039186 HPET_MSI-edge hpet5 29: 0 0 0 0 DMAR_MSI-edge dmar0 30: 0 0 0 0 PCI-MSI-edge aerdrv 31: 0 0 0 0 PCI-MSI-edge aerdrv 35: 308716 0 0 0 PCI-MSI-edge ahci 36: 499296 0 0 0 PCI-MSI-edge eth0-rx-0 37: 0 472843 0 0 PCI-MSI-edge eth0-tx-0 38: 0 0 2 0 PCI-MSI-edge eth0 NMI: 0 0 0 0 Non-maskable interrupts LOC: 87 76 62 50 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts IWI: 0 0 0 0 IRQ work interrupts RTR: 3 0 0 0 APIC ICR read retries RES: 23366853 23172156 22929406 21895431 Rescheduling interrupts CAL: 11038985 10976238 10966038 10848531 Function call interrupts TLB: 453 1144 929 937 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 209 209 209 209 Machine check polls ERR: 0 MIS: 0 On Fri, Oct 10, 2014 at 1:09 AM, Takashi Sakamoto <o-t...@sa...> wrote: > On Oct 10 2014 16:06, Clemens Ladisch wrote: >> >> Daniel Robbins wrote: >>> >>> With kernel 3.17.0, it now looks like firewire-ohci is misbehaving: >>> >>> [ 2.723177] firewire_ohci 0000:06:00.0: failed to allocate interrupt >>> 20 >>> [ 2.723206] firewire_ohci: probe of 0000:06:00.0 failed with error -5 >>> >>> 3.16.0 worked with your fixes... now that the fixes are in 3.17.0, >>> firewire-ohci appears broken. >> >> >> This has nothing to do with the sound driver. > > > Indeed. > >> Please show the "lspci -nnvv" entry of the controller, and the entire log. >> Is there any other driver on IRQ 20? > > > Output from /proc/interrupts will be our help, too. > > > Regards > > Takashi Sakamoto > o-t...@sa... |