Hi, I have a Sony VAIO (PCG-R505TFP) which has an interrupts related problem (this problem was previous posted elsewhere as "Weird as* sound problem"). This problem has been confirmed on at least one other Sony VAIO model (I forget which). They're both Intel i830M chipset based. Basically, the LNKB interrupt configuration register is not being initialised, so the interrupt never gets routed, and so the interrupt never gets to the CPU. Result: Sound doesn't work. A really hacky solution to this is to run the command: pciconf -w -b pci0:31:0 0x61 9 which sets the i830's PCI routing register for LNKB to IRQ 9. I did a bit of digging and found the following bits of information: 1. When the ACPI PCI bus starts up, it calls all the LNKx.CRS methods to get the current resources. LNKB (amongst others) returns 0. 2. The PCI configuration space register for IRQ contains the value 9. 3. If somebody calls the LNKB.SRS method, it would all work because that writes the PCI interrupt routing register thingy like pciconf does above. But the acpi_pcib_route_interrupt() function is not being called because in pci_alloc_resource() there is a test that checks if the PCI config space register that contains the interrupt contains a valid number (which it does - 9). So, basically I think there is something wrong here, which I think is that ACPI and the generic PCI code (in pci_alloc_resource()) don't agree when it comes to interrupt management. Other than saying "the BIOS is broken" (which it is, providing mislead information and all), is it a fair statement to say that the ACPI CRS method should be trusted more than the PCI configuration space registers? If so, then if the PCI conf space register disagrees with the ACPI result, should the PCI conf space register be updated to show what the ACPI stuff shows? I'm happy to muddle up a patch that might do this, but I was hoping for a bit of a guide as to how to do it. I thought initially that I could update the PCI config space register at the time the LNKs CRS method was called, but quickly gave up on that because I don't know which device to update... Could I instead perhaps implement the pci_alloc_resource() method in acpi_pcib_pci.c which inspects the existing PCI configuration and the ACPI LNK information and if they differ, put the ACPI value into the PCI configuration register, then call the pci_alloc_resource() function to finish off. Then pci_alloc_resource() will see a bad value for the PCI config space IRQ, and call the PCIB_ROUTE_INTERRUPT method to do the routing. Or is there a better place (or way) to do this. (Can I even legally call pci_alloc_resource() from acpi_pcib_pci_alloc_resource()?). For extra information, here is a rather verbose dmesg and AML dump: http://starbug.ugh.net.au/~iaint/vaio/dmesg.txt http://starbug.ugh.net.au/~iaint/vaio/ruri.aml Oh yeah, not using ACPI is not an option (panics in either PCI or PnP BIOS), also I think the same problem would exist then since it would still not try to route interrupts, but I could be wrong. IainReceived on Wed Jun 04 2003 - 01:51:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:10 UTC