Re: pcmcia: ti: regression cannot get IRQ

[Corentin Labbe]

Le Mon, Jan 02, 2023 at 09:30:07AM +0100, Arnd Bergmann a écrit :
> On Sun, Jan 1, 2023, at 19:10, Corentin Labbe wrote:
> > Hello
> >
> > I was trying to boot again my old compaq armada 7400 laptop and the 
> > network card is unusable.
> >
> > Last known working kernel is 4.16.18.
> > First known bad kernel is 4.17.19
> >
> > The interesting log is:
> > [    3.503348] yenta_cardbus 0000:00:0c.0: ISA IRQ mask 0x0698, PCI irq 
> > 0
> > [    3.503442] yenta_cardbus 0000:00:0c.0: Socket status: 30000006
> > [    3.505250] yenta_cardbus 0000:00:0c.1: CardBus bridge found 
> > [0e11:b048]
> > [    3.505370] yenta_cardbus 0000:00:0c.1: adjusting diagnostic: 60 -> 
> > 00
> > [    3.505457] yenta_cardbus 0000:00:0c.1: Using INTVAL to route CSC 
> > interrupts to PCI
> > [    3.505554] yenta_cardbus 0000:00:0c.1: Routing CardBus interrupts 
> > to ISA
> > [    3.505556] yenta_cardbus 0000:00:0c.1: TI: mfunc 0x00000000, devctl 
> > 0x64
> > [    3.505556] yenta_cardbus 0000:00:0c.1: TI: no PCI interrupts. Fish. 
> > Please report.
> > [    3.505556] yenta_cardbus 0000:00:0c.1: no PCI IRQ, CardBus support 
> > disabled for this socket.
> > [    3.505556] yenta_cardbus 0000:00:0c.1: check your BIOS CardBus, 
> > BIOS IRQ or ACPI settings.
> > [    3.632323] yenta_cardbus 0000:00:0c.1: ISA IRQ mask 0x0698, PCI irq 
> > 0
> > [    3.632416] yenta_cardbus 0000:00:0c.1: Socket status: 30000020
> >
> > Full 4.16.18 log is availlable at: 
> > http://kernel.montjoie.ovh/zoo/armada/dmesg-4.16.18.txt
> > Since 4.17 (and 4.18) is stuck sarting init, I have log for 5.0.29
> > Full 5.0.29 log is availlable at: 
> > http://kernel.montjoie.ovh/zoo/armada/dmesg-5.0.21.txt
> 
> I see you hit this code path:
> 
>         if (!socket->cb_irq || request_irq(socket->cb_irq, yenta_interrupt, IRQF_SHARED, "yenta", socket)) {
>                 /* No IRQ or request_irq failed. Poll */
>                 socket->cb_irq = 0; /* But zero is a valid IRQ number. */
>                 timer_setup(&socket->poll_timer, yenta_interrupt_wrapper, 0);
>                 mod_timer(&socket->poll_timer, jiffies + HZ);
>                 dev_info(&dev->dev,
>                          "no PCI IRQ, CardBus support disabled for this socket.\n");
>                 dev_info(&dev->dev,
>                          "check your BIOS CardBus, BIOS IRQ or ACPI settings.\n");
>         } else {
> 
> 
> The "socket->cb_irq" is just the device IRQ, which is originally
> set to "11", and this one appears to be shared with all the other
> PCI devices:
> 
> [    2.402035] ACPI: PCI Interrupt Link [C168] (IRQs *11)
> [    2.403507] ACPI: PCI Interrupt Link [C16C] (IRQs *11)
> [    2.405461] ACPI: Blank _CRS EXT IRQ resource
> [    2.405546] ACPI: PCI Interrupt Link [C16D] (IRQs 11) *0, disabled.
> [    2.407578] ACPI: Blank _CRS EXT IRQ resource
> [    2.407663] ACPI: PCI Interrupt Link [C16E] (IRQs 11) *0, disabled.
> [    2.409610] ACPI: Blank _CRS EXT IRQ resource
> [    2.409695] ACPI: PCI Interrupt Link [C16F] (IRQs 11) *0, disabled.
> [    2.411647] ACPI: Blank _CRS EXT IRQ resource
> [    2.411733] ACPI: PCI Interrupt Link [C170] (IRQs 11) *0, disabled.
> [    2.413690] ACPI: Blank _CRS EXT IRQ resource
> [    2.413775] ACPI: PCI Interrupt Link [C171] (IRQs 11) *0, disabled.
> [    2.416055] ACPI: Blank _CRS EXT IRQ resource
> [    2.416140] ACPI: PCI Interrupt Link [C172] (IRQs 11) *0, disabled.
> 
> If any of them try to get the IRQ as non-shared, then the cardbus
> one would fail. Do you see anything suspicious in /proc/interrupts?
> 

Hello

On 4.16.18 /proc/interrupts:
           CPU0       
  0:      55783    XT-PIC      timer
  1:          9    XT-PIC      i8042
  2:          0    XT-PIC      cascade
  8:          0    XT-PIC      rtc0
 11:        684    XT-PIC      acpi, yenta, yenta, eth2
 12:        136    XT-PIC      i8042
 14:       1526    XT-PIC      pata_triflex
 15:          0    XT-PIC      pata_triflex
NMI:          0   Non-maskable interrupts
LOC:          0   Local timer interrupts
SPU:          0   Spurious interrupts
PMI:          0   Performance monitoring interrupts
IWI:          0   IRQ work interrupts
RTR:          0   APIC ICR read retries
TRM:          0   Thermal event interrupts
THR:          0   Threshold APIC interrupts
MCE:          0   Machine check exceptions
MCP:          1   Machine check polls
ERR:          0
MIS:          0
PIN:          0   Posted-interrupt notification event
NPI:          0   Nested posted-interrupt event
PIW:          0   Posted-interrupt wakeup event

On 5.0.21 /proc/interrupts give:
           CPU0       
  0:       4736    XT-PIC      timer
  1:          9    XT-PIC      i8042
  2:          0    XT-PIC      cascade
  4:        438    XT-PIC      ttyS0
  8:          0    XT-PIC      rtc0
 11:          0    XT-PIC      acpi
 12:        136    XT-PIC      i8042
 14:       1224    XT-PIC      pata_triflex
 15:          0    XT-PIC      pata_triflex
NMI:          0   Non-maskable interrupts
LOC:          0   Local timer interrupts
SPU:          0   Spurious interrupts
PMI:          0   Performance monitoring interrupts
IWI:          0   IRQ work interrupts
RTR:          0   APIC ICR read retries
TRM:          0   Thermal event interrupts
THR:          0   Threshold APIC interrupts
MCE:          0   Machine check exceptions
MCP:          1   Machine check polls
ERR:        227
MIS:          0
PIN:          0   Posted-interrupt notification event
NPI:          0   Nested posted-interrupt event
PIW:          0   Posted-interrupt wakeup event


I have bisected this to:
first bad commit: [5a8361f7ecceaed64b4064000d16cb703462be49] ACPICA: Integrate package handling with module-level code
So I added ACPI people.

Regards