On Fri, Oct 26, 2012 at 3:13 AM, Stephane Grosjean <s.grosjean@xxxxxxxxxxxxxxx> wrote: > Hi Bjorn, > > Thanks for your answer. See my comments below... > > Le 26/10/2012 10:29, Bjorn Helgaas a écrit : >> >> On Wed, Sep 26, 2012 at 2:19 AM, Stephane Grosjean >> <s.grosjean@xxxxxxxxxxxxxxx> wrote: >> >>> I'm working on an issue with one of our PCI adapters. >>> This PCI adapter is a standard and well proven board, for many years: >>> >>> $ lspci -v >>> ... >>> 04:08.0 Network controller: PEAK-System Technik GmbH PCAN-PCI CAN-Bus >>> controller (rev 02) >>> Subsystem: PEAK-System Technik GmbH 2 Channel CAN Bus SJC1000 >>> Flags: medium devsel, IRQ 11 >>> Memory at f0410000 (32-bit, non-prefetchable) [size=64K] >>> Memory at f0400000 (32-bit, non-prefetchable) [size=64K] >>> Kernel driver in use: pcan >>> >>> >> Where's the source for the "pcan" driver? I see the pcan_usb driver >> in the tree, but that looks like something different from what you're >> looking at here. > > > The "pcan" driver is an out-ot-tree driver which offers a chardev interface, > not a mainline driver. The "pcan_usb" (as well as peak_pci...) are our > recent linux-can (only) drivers. > Since the "pcan" driver does exist since the old ages of 2.4 kernels, we > need to continue to support it. See also below for more information about > that... > >> Does the device work under any version of Linux? If so, please >> collect the complete dmesg log from the newest working version, and >> the same log from the broken version. > > > Yes it does! Anyway, you'll find the complete dmesg.txt attached to that > e-mail. Hoping this could help. Thanks. You attached the log for the broken version. Can you also attach a log from the newest working version of Linux? I assume the same driver works on the old version but fails on new versions. If so, it sounds like this might be a Linux regression, and finding the newest working and oldest broken versions will help identify it. >>> - why does the system not succeed to "derive" routing for INTA? And why >>> us? >> >> The derivation is based on ACPI _PRT tables. Regrettably, we don't >> dump the _PRT contents in dmesg, so we'd need an acpidump to look >> further into that. > > Well unfortunately, we are not able to provide this kind of information at > this moment. The acpidump isn't secret (it's not part of the BIOS source); it's just information extracted from the running system. See https://lesswatts.org/projects/acpi/utilities.php for details. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
