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 > 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. > Does this adapter work in some systems but not others? Under Windows > but not under Linux? You refer to the "good old" driver, so I infer > that it works *somewhere* and I'm trying to figure out what's > different about the case where it doesn't work. This adapter works under Windows and Linux systems since several years ago. But in case you want to check some things that could help: 1. you could find pieces of information into drivers/net/can/sja1000/peak_pci.c: this mainline driver handles things almost like the oot "pcan" driver does 2. you can also have a look to the sources of the "pcan" driver, by downloading the tarball from our website: http://www.peak-system.com/fileadmin/media/linux/files/peak-linux-driver-7.7.tar.gz In any cases, thanks for your help! >> My questions are: >> >> - 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. > Bjorn Stephane. -- PEAK-System Technik GmbH, Otto-Roehm-Strasse 69, D-64293 Darmstadt Geschaeftsleitung: A.Gach/U.Wilhelm,St.Nr.:007/241/13586 FA Darmstadt HRB-9183 Darmstadt, Ust.IdNr.:DE 202220078, WEE-Reg.-Nr.: DE39305391 Tel.+49 (0)6151-817320 / Fax:+49 (0)6151-817329, info@peak-system.com --