* Re: PCI device driver broken between 4.2 and 4.3 @ 2016-01-28 19:28 Мороз Олег 2016-01-29 16:31 ` Bjorn Helgaas 0 siblings, 1 reply; 19+ messages in thread From: Мороз Олег @ 2016-01-28 19:28 UTC (permalink / raw) To: Bjorn Helgaas Cc: linux-kernel@vger.kernel.org, Bjorn Helgaas, Jiang Liu, linux-pci@vger.kernel.org V2hhdCBpIG5lZWQgdG8gcHJpbnQgb3V0IGF0IGZpcnN0IG9yZGVyPyAyNyDRj9C90LIuIDIwMTYg 0LMuIDE2OjIyINC/0L7Qu9GM0LfQvtCy0LDRgtC10LvRjCBCam9ybiBIZWxnYWFzIDxoZWxnYWFz QGtlcm5lbC5vcmc+INC90LDQv9C40YHQsNC7Ogo+Cj4gT24gV2VkLCBKYW4gMjcsIDIwMTYgYXQg MTI6Mzg6MDZQTSArMDMwMCwg0JzQvtGA0L7QtyDQntC70LXQsyB3cm90ZTogCj4gPiBBbHNvLCBt eSBkcml2ZSBoYXMgbm8gCj4gPiAKPiA+IHBjaWJpb3NfZW5hYmxlX2RldmljZSgpIAo+ID4gcGNp Ymlvc19hbGxvY19pcnEoKSAKPiA+IAo+ID4gY2FsbHMuIAo+Cj4gVGhvc2UgYXJlIGludGVybmFs IGludGVyZmFjZXMgdXNlZCBieSB0aGUgUENJIGNvcmUuwqAgRHJpdmVycyBzaG91bGRuJ3QgCj4g Y2FsbCB0aGVtIGRpcmVjdGx5LsKgIERyaXZlcnMgbm9ybWFsbHkgY2FsbCBwY2lfZW5hYmxlX2Rl dmljZSgpLCBhbmQgCj4gdGhvc2UgaW50ZXJuYWwgaW50ZXJmYWNlcyBhcmUgdXNlZCBpbiB0aGF0 IHBhdGguIAo+Cj4gPiAyNi4wMS4yMDE2IDIyOjA1LCDQntC70LXQsyDQnNC+0YDQvtC3INC/0LjR iNC10YI6IAo+ID4gPkkgY29uZmlybWVkIGl0IHdvcmtzIGluIAo+ID4gPiAKPiA+ID44OTBlNDg0 NzU4N2YgCj4gPiA+IAo+ID4gPmFuZCBkbyBub3Qgd29ya3MgaW4gCj4gPiA+IAo+ID4gPjk5MWRl MmU1OTA5MCAKPiA+ID4gCj4gPiA+MjYuMDEuMjAxNiAxODozMiwgQmpvcm4gSGVsZ2FhcyDQv9C4 0YjQtdGCOiAKPiA+ID4+WytjYyBKaWFuZ10gCj4gPiA+PiAKPiA+ID4+T24gTW9uLCBKYW4gMjUs IDIwMTYgYXQgMDM6NTI6NTFQTSAtMDYwMCwgQmpvcm4gSGVsZ2FhcyB3cm90ZTogCj4gPiA+Pj5I aSDQntC70LXQsywgCj4gPiA+Pj4gCj4gPiA+Pj5PbiBTdW4sIEphbiAyNCwgMjAxNiBhdCAwNDo1 MDowOFBNICswMzAwLCDQntC70LXQsyDQnNC+0YDQvtC3IHdyb3RlOiAKPiA+ID4+Pj5Pa2F5LiBJ J3ZlIHNlbnQgbG9ncyAoZG1lc2cgYW5kIGxzcGNpKSBmcm9tIGJvdGggNC4yIGFuZCA0LjMgCj4g PiA+Pj4+dG8gYnVnemlsbGEgCj4gPiA+Pj5JIGRvbid0IHNlZSBhbnl0aGluZyB3cm9uZyBpbiBl aXRoZXIgbG9nLsKgIEJvdGggdjQuMiBhbmQgdjQuMyAKPiA+ID4+PmVudW1lcmF0ZSB0aGUgZGV2 aWNlIHRoZSBzYW1lIHdheSwgYW5kIHRoZSBkcml2ZXIgc2VlbXMgdG8gY2xhaW0gaXQgCj4gPiA+ Pj50aGUgc2FtZSB3YXk6IAo+ID4gPj4+IAo+ID4gPj4+wqDCoCBwY2kgMDAwMDowZDowMC4wOiBb MTBiNTo5MDMwXSB0eXBlIDAwIGNsYXNzIDB4MDc4MDAwIAo+ID4gPj4+wqDCoCBwY2kgMDAwMDow ZDowMC4wOiByZWcgMHgxNDogW2lvwqAgMHgyMTAwLTB4MjE3Zl0gCj4gPiA+Pj7CoMKgIHBjaSAw MDAwOjBkOjAwLjA6IHJlZyAweDE4OiBbaW/CoCAweDIzODAtMHgyMzlmXSAKPiA+ID4+PsKgwqAg cGNpIDAwMDA6MGQ6MDAuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCAKPiA+ID4+PsKg wqAgcGNpIDAwMDA6MGQ6MDEuMDogWzEwYjU6OTAzMF0gdHlwZSAwMCBjbGFzcyAweDA3ODAwMCAK PiA+ID4+PsKgwqAgcGNpIDAwMDA6MGQ6MDEuMDogcmVnIDB4MTQ6IFtpb8KgIDB4MjE4MC0weDIx ZmZdIAo+ID4gPj4+wqDCoCBwY2kgMDAwMDowZDowMS4wOiByZWcgMHgxODogW2lvwqAgMHgyM2Ew LTB4MjNiZl0gCj4gPiA+Pj7CoMKgIHBjaSAwMDAwOjBkOjAxLjA6IFBNRSMgc3VwcG9ydGVkIGZy b20gRDAgRDNob3QgCj4gPiA+Pj7CoMKgIHBjaSAwMDAwOjBkOjAyLjA6IFsxMGI1OjkwMzBdIHR5 cGUgMDAgY2xhc3MgMHgwNzgwMDAgCj4gPiA+Pj7CoMKgIHBjaSAwMDAwOjBkOjAyLjA6IHJlZyAw eDE0OiBbaW/CoCAweDIyMDAtMHgyMjdmXSAKPiA+ID4+PsKgwqAgcGNpIDAwMDA6MGQ6MDIuMDog cmVnIDB4MTg6IFtpb8KgIDB4MjI4MC0weDIyZmZdIAo+ID4gPj4+wqDCoCBwY2kgMDAwMDowZDow Mi4wOiByZWcgMHgxYzogW2lvwqAgMHgyMzAwLTB4MjM3Zl0gCj4gPiA+Pj7CoMKgIHBjaSAwMDAw OjBkOjAyLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgCj4gPiA+Pj4gCj4gPiA+Pj7C oMKgIHNqYTEwMDBfcGx4X3BjaSAwMDAwOjBkOjAyLjA6IERldGVjdGVkICJFY2x1cyBDQU4tMjAw LVBDSSIgCj4gPiA+Pj5jYXJkIGF0IHNsb3QgIzIgCj4gPiA+Pj7CoMKgIHNqYTEwMDBfcGx4X3Bj aSAwMDAwOjBkOjAyLjA6IENoYW5uZWwgIzEgYXQgCj4gPiA+Pj4weDAwMDAwMDAwMDAwMTIyODAs IGlycSAyMiByZWdpc3RlcmVkIGFzIGNhbjAgCj4gPiA+Pj7CoMKgIHNqYTEwMDBfcGx4X3BjaSAw MDAwOjBkOjAyLjA6IENoYW5uZWwgIzIgYXQgCj4gPiA+Pj4weDAwMDAwMDAwMDAwMTIzMDAsIGly cSAyMiByZWdpc3RlcmVkIGFzIGNhbjEgCj4gPiA+Pj7CoMKgIHNqYTEwMDBfcGx4X3BjaSAwMDAw OjBkOjAyLjAgY2FuMDogc2V0dGluZyBCVFIwPTB4MDMgQlRSMT0weDM3IAo+ID4gPj4+IAo+ID4g Pj4+T25lIG9wdGlvbiBpcyBhbHdheXMgdG8gYmlzZWN0IGJldHdlZW4gdjQuMiBhbmQgdjQuMyB0 byBzZWUgd2hpY2ggCj4gPiA+Pj5jb21taXQgbWFkZSBpdCBzdG9wIHdvcmtpbmcuwqAgU2VlIGh0 dHBzOi8vZ2l0LXNjbS5jb20vZG9jcy9naXQtYmlzZWN0IAo+ID4gPj5KaWFuZywg0J7Qu9C10LMg YmlzZWN0ZWQgdGhpcyB0byA5OTFkZTJlNTkwOTAgKCJQQ0ksIHg4NjogSW1wbGVtZW50IAo+ID4g Pj5wY2liaW9zX2FsbG9jX2lycSgpIGFuZCBwY2liaW9zX2ZyZWVfaXJxKCkiKS4gCj4gPiA+PiAK PiA+ID4+0J7Qu9C10LMsIHBsZWFzZSBkb3VibGUtY2hlY2sgYW5kIGNvbmZpcm0gdGhhdCA4OTBl NDg0NzU4N2Ygd29ya3MgYW5kIAo+ID4gPj45OTFkZTJlNTkwOTAgZmFpbHMuIAo+ID4gPj4gCj4g PiA+PlRoZW4gcGxlYXNlIGFkZCBzb21lIHByaW50a3MgaW4gdGhlIHBjaWJpb3NfZW5hYmxlX2Rl dmljZSgpIGFuZCAKPiA+ID4+cGNpYmlvc19hbGxvY19pcnEoKSBwYXRocyBhbmQgaW4geW91ciBk cml2ZXIgdG8gc2VlIGV4YWN0bHkgd2hhdCBjaGFuZ2VkIAo+ID4gPj5iZXR3ZWVuIDg5MGU0ODQ3 NTg3ZiBhbmQgOTkxZGUyZTU5MDkwIAo+ID4gPj4gCj4gPiA+PkJqb3JuIAo+ID4gPj4gCj4gPiA+ Pj4+MjMuMDEuMjAxNiAxNzo1NCwgQmpvcm4gSGVsZ2FhcyDQv9C40YjQtdGCOiAKPiA+ID4+Pj4+ WytjYyBsaW51eC1rZXJuZWxdIAo+ID4gPj4+Pj4gCj4gPiA+Pj4+PkhpINCe0LvQtdCzLCAKPiA+ ID4+Pj4+IAo+ID4gPj4+Pj5PbiBTYXQsIEphbiAyMywgMjAxNiBhdCAxOjA4IEFNLCDQntC70LXQ syDQnNC+0YDQvtC3IAo+ID4gPj4+Pj48b2xlZy5tb3JvekBtY2Mudm5paWVtLnJ1PiB3cm90ZTog Cj4gPiA+Pj4+Pj5IZWxsby4gSSd2ZSBnb3QgYSBkZXZpY2UgZHJpdmVyIGZvciBNSUwtMTU1M2Ig Y2FyZCAKPiA+ID4+Pj4+PmNhbGxlZCBUQTEtUENJLCB3aGljaCAKPiA+ID4+Pj4+PmNvdWxkIGJl IGZvdW5kIGF0IAo+ID4gPj4+Pj4+aHR0cHM6Ly9naXRodWIuY29tL3Ftb3IvZWxjdXMtMTU1My1k cml2ZXItbGludXggCj4gPiA+Pj4+Pj5DYXJkIGlzIHVzaW5nIFBMWF9QQ0k5MDMwIFBDSSBjb250 cm9sbGVyLiAKPiA+ID4+Pj4+PlRvZGF5IGkndmUgZm91bmQgdGhhdCB0aGlzIGRyaXZlciBjb21w aWxlcywgaW5zdGFsbGVzLCAKPiA+ID4+Pj4+PmJ1dCBpcyBub3Qgd29ya2luZyBhcyAKPiA+ID4+ Pj4+Pml0IHNob3VsZC4gCj4gPiA+Pj4+Pj5Mb29rcyBsaWtlIGl0IG5vdCByZWNlaXZlcyBhbnkg aW50ZXJydXB0cyBmcm9tIFBDSS4gSSd2ZSAKPiA+ID4+Pj4+PnRlc3QgaXQgYWdhaW4gd2l0aCAK PiA+ID4+Pj4+Pmtlcm5lbCAKPiA+ID4+Pj4+PjQuMiBhbmQgaXQgd29ya3Mgb2theS4gV2hhdCBj aGFuZ2VzIHdhcyBtYWRlIGluIFBDSSAKPiA+ID4+Pj4+PnN1YnN5c3RlbSBmcm9tIDQuMiB0byAK PiA+ID4+Pj4+PjQuMyAKPiA+ID4+Pj4+PndoaWNoIGNvdWxkIGhhdmUgaW1wYWN0IHRoaXMgZHJp dmVyIHdvcmsuIAo+ID4gPj4+Pj5UaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGlzIHByb2JsZW0g cmVwb3J0LsKgIFRoZXJlIHdlcmUgbWFueSBQQ0kgCj4gPiA+Pj4+PmNoYW5nZXMgYmV0d2VlbiB2 NC4yIGFuZCB2NC4zLCBhbmQgd2l0aG91dCBtb3JlIGluZm9ybWF0aW9uLCBJIGNhbid0IAo+ID4g Pj4+Pj5ndWVzcyB3aGF0IG1pZ2h0IGJlIGNhdXNpbmcgdGhpcyBwcm9ibGVtLiAKPiA+ID4+Pj4+ IAo+ID4gPj4+Pj5JIG9wZW5lZCBhIGJ1ZyByZXBvcnQgYXQgCj4gPiA+Pj4+Pmh0dHBzOi8vYnVn emlsbGEua2VybmVsLm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTExMjExIAo+ID4gPj4+Pj4gCj4gPiA+ Pj4+PlBsZWFzZSBhdHRhY2ggY29tcGxldGUgZG1lc2cgbG9ncyBmb3IgYm90aCB2NC4yIGFuZCB2 NC4zIHRvIHRoYXQgYnVnIAo+ID4gPj4+Pj5yZXBvcnQuwqAgQWxzbywgcGxlYXNlIGF0dGFjaCB0 aGUgY29tcGxldGUgImxzcGNpIC12diIgb3V0cHV0IChhcyAKPiA+ID4+Pj4+cm9vdCkuIAo+ID4g Pj4+Pj4gCj4gPiA+Pj4+PlRoYW5rcyEgCj4gPiA+Pj4+PiAKPiA+ID4+Pj4+Qmpvcm4gCj4gPiA+ Pj4+LS0gCj4gPiA+Pj4+VG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxp bmUgInVuc3Vic2NyaWJlIAo+ID4gPj4+PmxpbnV4LXBjaSIgaW4gCj4gPiA+Pj4+dGhlIGJvZHkg b2YgYSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2VyLmtlcm5lbC5vcmcgCj4gPiA+Pj4+TW9yZSBt YWpvcmRvbW8gaW5mbyBhdCBodHRwOi8vdmdlci5rZXJuZWwub3JnL21ham9yZG9tby1pbmZvLmh0 bWwgCj4gPiA+Pj4tLSAKPiA+ID4+PlRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBsaXN0OiBzZW5k IHRoZSBsaW5lICJ1bnN1YnNjcmliZSBsaW51eC1wY2kiIGluIAo+ID4gPj4+dGhlIGJvZHkgb2Yg YSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2VyLmtlcm5lbC5vcmcgCj4gPiA+Pj5Nb3JlIG1ham9y ZG9tbyBpbmZvIGF0IGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbCAK PiA+ID4gCj4gPiAKPiA+IC0tIAo+ID4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNl bmQgdGhlIGxpbmUgInVuc3Vic2NyaWJlIGxpbnV4LXBjaSIgaW4gCj4gPiB0aGUgYm9keSBvZiBh IG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9yZyAKPiA+IE1vcmUgbWFqb3Jkb21v IGluZm8gYXTCoCBodHRwOi8vdmdlci5rZXJuZWwub3JnL21ham9yZG9tby1pbmZvLmh0bWwgCg== ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: PCI device driver broken between 4.2 and 4.3 2016-01-28 19:28 PCI device driver broken between 4.2 and 4.3 Мороз Олег @ 2016-01-29 16:31 ` Bjorn Helgaas 2016-01-30 6:15 ` Yinghai Lu 2016-02-01 5:18 ` Олег Мороз 0 siblings, 2 replies; 19+ messages in thread From: Bjorn Helgaas @ 2016-01-29 16:31 UTC (permalink / raw) To: Мороз Олег Cc: linux-kernel, Bjorn Helgaas, Jiang Liu, linux-pci On Thu, Jan 28, 2016 at 10:28:14PM +0300, Мороз Олег wrote: > What i need to print out at first order? Jiang, can you chime in here? 991de2e59090 is related to IRQs, so I'd start by printing dev->irq in your driver before and after you call pci_enable_device(). Add some printks in pcibios_alloc_irq() and pcibios_enable_device() just to confirm that we got there and when, e.g., add lines like this: dev_info(&dev->dev, "%s\n", __func__); Bjorn > 27 янв. 2016 г. 16:22 пользователь Bjorn Helgaas <helgaas@kernel.org> написал: > > > > On Wed, Jan 27, 2016 at 12:38:06PM +0300, Мороз Олег wrote: > > > Also, my drive has no > > > > > > pcibios_enable_device() > > > pcibios_alloc_irq() > > > > > > calls. > > > > Those are internal interfaces used by the PCI core. Drivers shouldn't > > call them directly. Drivers normally call pci_enable_device(), and > > those internal interfaces are used in that path. > > > > > 26.01.2016 22:05, Олег Мороз пишет: > > > >I confirmed it works in > > > > > > > >890e4847587f > > > > > > > >and do not works in > > > > > > > >991de2e59090 > > > > > > > >26.01.2016 18:32, Bjorn Helgaas пишет: > > > >>[+cc Jiang] > > > >> > > > >>On Mon, Jan 25, 2016 at 03:52:51PM -0600, Bjorn Helgaas wrote: > > > >>>Hi Олег, > > > >>> > > > >>>On Sun, Jan 24, 2016 at 04:50:08PM +0300, Олег Мороз wrote: > > > >>>>Okay. I've sent logs (dmesg and lspci) from both 4.2 and 4.3 > > > >>>>to bugzilla > > > >>>I don't see anything wrong in either log. Both v4.2 and v4.3 > > > >>>enumerate the device the same way, and the driver seems to claim it > > > >>>the same way: > > > >>> > > > >>> pci 0000:0d:00.0: [10b5:9030] type 00 class 0x078000 > > > >>> pci 0000:0d:00.0: reg 0x14: [io 0x2100-0x217f] > > > >>> pci 0000:0d:00.0: reg 0x18: [io 0x2380-0x239f] > > > >>> pci 0000:0d:00.0: PME# supported from D0 D3hot > > > >>> pci 0000:0d:01.0: [10b5:9030] type 00 class 0x078000 > > > >>> pci 0000:0d:01.0: reg 0x14: [io 0x2180-0x21ff] > > > >>> pci 0000:0d:01.0: reg 0x18: [io 0x23a0-0x23bf] > > > >>> pci 0000:0d:01.0: PME# supported from D0 D3hot > > > >>> pci 0000:0d:02.0: [10b5:9030] type 00 class 0x078000 > > > >>> pci 0000:0d:02.0: reg 0x14: [io 0x2200-0x227f] > > > >>> pci 0000:0d:02.0: reg 0x18: [io 0x2280-0x22ff] > > > >>> pci 0000:0d:02.0: reg 0x1c: [io 0x2300-0x237f] > > > >>> pci 0000:0d:02.0: PME# supported from D0 D3hot > > > >>> > > > >>> sja1000_plx_pci 0000:0d:02.0: Detected "Eclus CAN-200-PCI" > > > >>>card at slot #2 > > > >>> sja1000_plx_pci 0000:0d:02.0: Channel #1 at > > > >>>0x0000000000012280, irq 22 registered as can0 > > > >>> sja1000_plx_pci 0000:0d:02.0: Channel #2 at > > > >>>0x0000000000012300, irq 22 registered as can1 > > > >>> sja1000_plx_pci 0000:0d:02.0 can0: setting BTR0=0x03 BTR1=0x37 > > > >>> > > > >>>One option is always to bisect between v4.2 and v4.3 to see which > > > >>>commit made it stop working. See https://git-scm.com/docs/git-bisect > > > >>Jiang, Олег bisected this to 991de2e59090 ("PCI, x86: Implement > > > >>pcibios_alloc_irq() and pcibios_free_irq()"). > > > >> > > > >>Олег, please double-check and confirm that 890e4847587f works and > > > >>991de2e59090 fails. > > > >> > > > >>Then please add some printks in the pcibios_enable_device() and > > > >>pcibios_alloc_irq() paths and in your driver to see exactly what changed > > > >>between 890e4847587f and 991de2e59090 > > > >> > > > >>Bjorn > > > >> > > > >>>>23.01.2016 17:54, Bjorn Helgaas пишет: > > > >>>>>[+cc linux-kernel] > > > >>>>> > > > >>>>>Hi Олег, > > > >>>>> > > > >>>>>On Sat, Jan 23, 2016 at 1:08 AM, Олег Мороз > > > >>>>><oleg.moroz@mcc.vniiem.ru> wrote: > > > >>>>>>Hello. I've got a device driver for MIL-1553b card > > > >>>>>>called TA1-PCI, which > > > >>>>>>could be found at > > > >>>>>>https://github.com/qmor/elcus-1553-driver-linux > > > >>>>>>Card is using PLX_PCI9030 PCI controller. > > > >>>>>>Today i've found that this driver compiles, installes, > > > >>>>>>but is not working as > > > >>>>>>it should. > > > >>>>>>Looks like it not receives any interrupts from PCI. I've > > > >>>>>>test it again with > > > >>>>>>kernel > > > >>>>>>4.2 and it works okay. What changes was made in PCI > > > >>>>>>subsystem from 4.2 to > > > >>>>>>4.3 > > > >>>>>>which could have impact this driver work. > > > >>>>>Thank you very much for this problem report. There were many PCI > > > >>>>>changes between v4.2 and v4.3, and without more information, I can't > > > >>>>>guess what might be causing this problem. > > > >>>>> > > > >>>>>I opened a bug report at > > > >>>>>https://bugzilla.kernel.org/show_bug.cgi?id=111211 > > > >>>>> > > > >>>>>Please attach complete dmesg logs for both v4.2 and v4.3 to that bug > > > >>>>>report. Also, please attach the complete "lspci -vv" output (as > > > >>>>>root). > > > >>>>> > > > >>>>>Thanks! > > > >>>>> > > > >>>>>Bjorn > > > >>>>-- > > > >>>>To unsubscribe from this list: send the line "unsubscribe > > > >>>>linux-pci" in > > > >>>>the body of a message to majordomo@vger.kernel.org > > > >>>>More majordomo info at http://vger.kernel.org/majordomo-info.html > > > >>>-- > > > >>>To unsubscribe from this list: send the line "unsubscribe linux-pci" in > > > >>>the body of a message to majordomo@vger.kernel.org > > > >>>More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > > > > > > -- > > > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > > > the body of a message to majordomo@vger.kernel.org > > > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: PCI device driver broken between 4.2 and 4.3 2016-01-29 16:31 ` Bjorn Helgaas @ 2016-01-30 6:15 ` Yinghai Lu 2016-02-01 5:18 ` Олег Мороз 1 sibling, 0 replies; 19+ messages in thread From: Yinghai Lu @ 2016-01-30 6:15 UTC (permalink / raw) To: Bjorn Helgaas Cc: Мороз Олег, Linux Kernel Mailing List, Bjorn Helgaas, Jiang Liu, linux-pci@vger.kernel.org On Fri, Jan 29, 2016 at 8:31 AM, Bjorn Helgaas <helgaas@kernel.org> wrote: > > 991de2e59090 is related to IRQs, so I'd start by printing dev->irq in your > driver before and after you call pci_enable_device(). Add some printks in > pcibios_alloc_irq() and pcibios_enable_device() just to confirm that we got > there and when, e.g., add lines like this: looks like that commit removed pcibios_enable_irq for parent bridge. pci_enable_device==>pci_enable_bridge==>pci_enable_device==>pcibios_enable_device ==>pcibios_enable_irq without msi enabled. so pci=routeirq may workaround the problem. Thanks Yinghai ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: PCI device driver broken between 4.2 and 4.3 2016-01-29 16:31 ` Bjorn Helgaas 2016-01-30 6:15 ` Yinghai Lu @ 2016-02-01 5:18 ` Олег Мороз 2016-02-01 21:08 ` Bjorn Helgaas 1 sibling, 1 reply; 19+ messages in thread From: Олег Мороз @ 2016-02-01 5:18 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: linux-kernel, Bjorn Helgaas, Jiang Liu, linux-pci Okay. I've started from driver level printk results are: On 4.2 [414006.575989] Before pci_enable_device IRQ 20 [414006.575991] After pci_enable_device IRQ 20 [414006.575997] Before pci_enable_device IRQ 21 [414006.575999] After pci_enable_device IRQ 21 on 4.3 [ 114.862289] Before pci_enable_device IRQ 5 [ 114.862303] After pci_enable_device IRQ 5 [ 114.862316] Before pci_enable_device IRQ 5 [ 114.862326] After pci_enable_device IRQ 5 I've got two cards, because of that pci_enable_device() calls twice. On Friday 29 of January 2016 10:31:59 Bjorn Helgaas wrote: > On Thu, Jan 28, 2016 at 10:28:14PM +0300, Мороз Олег wrote: > > What i need to print out at first order? > > Jiang, can you chime in here? > > 991de2e59090 is related to IRQs, so I'd start by printing dev->irq in your > driver before and after you call pci_enable_device(). Add some printks in > pcibios_alloc_irq() and pcibios_enable_device() just to confirm that we got > there and when, e.g., add lines like this: > > dev_info(&dev->dev, "%s\n", __func__); > > Bjorn > > > 27 янв. 2016 г. 16:22 пользователь Bjorn Helgaas <helgaas@kernel.org> написал: > > > On Wed, Jan 27, 2016 at 12:38:06PM +0300, Мороз Олег wrote: > > > > Also, my drive has no > > > > > > > > pcibios_enable_device() > > > > pcibios_alloc_irq() > > > > > > > > calls. > > > > > > Those are internal interfaces used by the PCI core. Drivers shouldn't > > > call them directly. Drivers normally call pci_enable_device(), and > > > those internal interfaces are used in that path. > > > > > > > 26.01.2016 22:05, Олег Мороз пишет: > > > > >I confirmed it works in > > > > > > > > > >890e4847587f > > > > > > > > > >and do not works in > > > > > > > > > >991de2e59090 > > > > > > > > > >26.01.2016 18:32, Bjorn Helgaas пишет: > > > > >>[+cc Jiang] > > > > >> > > > > >>On Mon, Jan 25, 2016 at 03:52:51PM -0600, Bjorn Helgaas wrote: > > > > >>>Hi Олег, > > > > >>> > > > > >>>On Sun, Jan 24, 2016 at 04:50:08PM +0300, Олег Мороз wrote: > > > > >>>>Okay. I've sent logs (dmesg and lspci) from both 4.2 and 4.3 > > > > >>>>to bugzilla > > > > >>> > > > > >>>I don't see anything wrong in either log. Both v4.2 and v4.3 > > > > >>>enumerate the device the same way, and the driver seems to claim it > > > > >>>the same way: > > > > >>> > > > > >>> pci 0000:0d:00.0: [10b5:9030] type 00 class 0x078000 > > > > >>> pci 0000:0d:00.0: reg 0x14: [io 0x2100-0x217f] > > > > >>> pci 0000:0d:00.0: reg 0x18: [io 0x2380-0x239f] > > > > >>> pci 0000:0d:00.0: PME# supported from D0 D3hot > > > > >>> pci 0000:0d:01.0: [10b5:9030] type 00 class 0x078000 > > > > >>> pci 0000:0d:01.0: reg 0x14: [io 0x2180-0x21ff] > > > > >>> pci 0000:0d:01.0: reg 0x18: [io 0x23a0-0x23bf] > > > > >>> pci 0000:0d:01.0: PME# supported from D0 D3hot > > > > >>> pci 0000:0d:02.0: [10b5:9030] type 00 class 0x078000 > > > > >>> pci 0000:0d:02.0: reg 0x14: [io 0x2200-0x227f] > > > > >>> pci 0000:0d:02.0: reg 0x18: [io 0x2280-0x22ff] > > > > >>> pci 0000:0d:02.0: reg 0x1c: [io 0x2300-0x237f] > > > > >>> pci 0000:0d:02.0: PME# supported from D0 D3hot > > > > >>> > > > > >>> sja1000_plx_pci 0000:0d:02.0: Detected "Eclus CAN-200-PCI" > > > > >>>card at slot #2 > > > > >>> sja1000_plx_pci 0000:0d:02.0: Channel #1 at > > > > >>>0x0000000000012280, irq 22 registered as can0 > > > > >>> sja1000_plx_pci 0000:0d:02.0: Channel #2 at > > > > >>>0x0000000000012300, irq 22 registered as can1 > > > > >>> sja1000_plx_pci 0000:0d:02.0 can0: setting BTR0=0x03 BTR1=0x37 > > > > >>> > > > > >>>One option is always to bisect between v4.2 and v4.3 to see which > > > > >>>commit made it stop working. See > > > > >>>https://git-scm.com/docs/git-bisect > > > > >> > > > > >>Jiang, Олег bisected this to 991de2e59090 ("PCI, x86: Implement > > > > >>pcibios_alloc_irq() and pcibios_free_irq()"). > > > > >> > > > > >>Олег, please double-check and confirm that 890e4847587f works and > > > > >>991de2e59090 fails. > > > > >> > > > > >>Then please add some printks in the pcibios_enable_device() and > > > > >>pcibios_alloc_irq() paths and in your driver to see exactly what > > > > >>changed > > > > >>between 890e4847587f and 991de2e59090 > > > > >> > > > > >>Bjorn > > > > >> > > > > >>>>23.01.2016 17:54, Bjorn Helgaas пишет: > > > > >>>>>[+cc linux-kernel] > > > > >>>>> > > > > >>>>>Hi Олег, > > > > >>>>> > > > > >>>>>On Sat, Jan 23, 2016 at 1:08 AM, Олег Мороз > > > > >>>>> > > > > >>>>><oleg.moroz@mcc.vniiem.ru> wrote: > > > > >>>>>>Hello. I've got a device driver for MIL-1553b card > > > > >>>>>>called TA1-PCI, which > > > > >>>>>>could be found at > > > > >>>>>>https://github.com/qmor/elcus-1553-driver-linux > > > > >>>>>>Card is using PLX_PCI9030 PCI controller. > > > > >>>>>>Today i've found that this driver compiles, installes, > > > > >>>>>>but is not working as > > > > >>>>>>it should. > > > > >>>>>>Looks like it not receives any interrupts from PCI. I've > > > > >>>>>>test it again with > > > > >>>>>>kernel > > > > >>>>>>4.2 and it works okay. What changes was made in PCI > > > > >>>>>>subsystem from 4.2 to > > > > >>>>>>4.3 > > > > >>>>>>which could have impact this driver work. > > > > >>>>> > > > > >>>>>Thank you very much for this problem report. There were many PCI > > > > >>>>>changes between v4.2 and v4.3, and without more information, I > > > > >>>>>can't > > > > >>>>>guess what might be causing this problem. > > > > >>>>> > > > > >>>>>I opened a bug report at > > > > >>>>>https://bugzilla.kernel.org/show_bug.cgi?id=111211 > > > > >>>>> > > > > >>>>>Please attach complete dmesg logs for both v4.2 and v4.3 to that > > > > >>>>>bug > > > > >>>>>report. Also, please attach the complete "lspci -vv" output (as > > > > >>>>>root). > > > > >>>>> > > > > >>>>>Thanks! > > > > >>>>> > > > > >>>>>Bjorn ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: PCI device driver broken between 4.2 and 4.3 2016-02-01 5:18 ` Олег Мороз @ 2016-02-01 21:08 ` Bjorn Helgaas 2016-02-02 5:04 ` Олег Мороз 0 siblings, 1 reply; 19+ messages in thread From: Bjorn Helgaas @ 2016-02-01 21:08 UTC (permalink / raw) To: Олег Мороз Cc: linux-kernel, Bjorn Helgaas, Jiang Liu, linux-pci [+cc Yinghai] On Mon, Feb 01, 2016 at 08:18:35AM +0300, Олег Мороз wrote: > Okay. I've started from driver level printk > results are: > > On 4.2 > > [414006.575989] Before pci_enable_device IRQ 20 > > [414006.575991] After pci_enable_device IRQ 20 > > [414006.575997] Before pci_enable_device IRQ 21 > > [414006.575999] After pci_enable_device IRQ 21 > > on 4.3 > > [ 114.862289] Before pci_enable_device IRQ 5 > > [ 114.862303] After pci_enable_device IRQ 5 > > [ 114.862316] Before pci_enable_device IRQ 5 > > [ 114.862326] After pci_enable_device IRQ 5 > > I've got two cards, because of that pci_enable_device() calls twice. Did you try booting with pci=routeirq as Yinghai suggested? That's not a fix, but if it does make things work, it may give us an idea for how to fix it correctly. > On Friday 29 of January 2016 10:31:59 Bjorn Helgaas wrote: > > On Thu, Jan 28, 2016 at 10:28:14PM +0300, Мороз Олег wrote: > > > What i need to print out at first order? > > > > Jiang, can you chime in here? > > > > 991de2e59090 is related to IRQs, so I'd start by printing dev->irq in your > > driver before and after you call pci_enable_device(). Add some printks in > > pcibios_alloc_irq() and pcibios_enable_device() just to confirm that we got > > there and when, e.g., add lines like this: > > > > dev_info(&dev->dev, "%s\n", __func__); > > > > Bjorn > > > > > 27 янв. 2016 г. 16:22 пользователь Bjorn Helgaas <helgaas@kernel.org> > написал: > > > > On Wed, Jan 27, 2016 at 12:38:06PM +0300, Мороз Олег wrote: > > > > > Also, my drive has no > > > > > > > > > > pcibios_enable_device() > > > > > pcibios_alloc_irq() > > > > > > > > > > calls. > > > > > > > > Those are internal interfaces used by the PCI core. Drivers shouldn't > > > > call them directly. Drivers normally call pci_enable_device(), and > > > > those internal interfaces are used in that path. > > > > > > > > > 26.01.2016 22:05, Олег Мороз пишет: > > > > > >I confirmed it works in > > > > > > > > > > > >890e4847587f > > > > > > > > > > > >and do not works in > > > > > > > > > > > >991de2e59090 > > > > > > > > > > > >26.01.2016 18:32, Bjorn Helgaas пишет: > > > > > >>[+cc Jiang] > > > > > >> > > > > > >>On Mon, Jan 25, 2016 at 03:52:51PM -0600, Bjorn Helgaas wrote: > > > > > >>>Hi Олег, > > > > > >>> > > > > > >>>On Sun, Jan 24, 2016 at 04:50:08PM +0300, Олег Мороз wrote: > > > > > >>>>Okay. I've sent logs (dmesg and lspci) from both 4.2 and 4.3 > > > > > >>>>to bugzilla > > > > > >>> > > > > > >>>I don't see anything wrong in either log. Both v4.2 and v4.3 > > > > > >>>enumerate the device the same way, and the driver seems to claim it > > > > > >>>the same way: > > > > > >>> > > > > > >>> pci 0000:0d:00.0: [10b5:9030] type 00 class 0x078000 > > > > > >>> pci 0000:0d:00.0: reg 0x14: [io 0x2100-0x217f] > > > > > >>> pci 0000:0d:00.0: reg 0x18: [io 0x2380-0x239f] > > > > > >>> pci 0000:0d:00.0: PME# supported from D0 D3hot > > > > > >>> pci 0000:0d:01.0: [10b5:9030] type 00 class 0x078000 > > > > > >>> pci 0000:0d:01.0: reg 0x14: [io 0x2180-0x21ff] > > > > > >>> pci 0000:0d:01.0: reg 0x18: [io 0x23a0-0x23bf] > > > > > >>> pci 0000:0d:01.0: PME# supported from D0 D3hot > > > > > >>> pci 0000:0d:02.0: [10b5:9030] type 00 class 0x078000 > > > > > >>> pci 0000:0d:02.0: reg 0x14: [io 0x2200-0x227f] > > > > > >>> pci 0000:0d:02.0: reg 0x18: [io 0x2280-0x22ff] > > > > > >>> pci 0000:0d:02.0: reg 0x1c: [io 0x2300-0x237f] > > > > > >>> pci 0000:0d:02.0: PME# supported from D0 D3hot > > > > > >>> > > > > > >>> sja1000_plx_pci 0000:0d:02.0: Detected "Eclus CAN-200-PCI" > > > > > >>>card at slot #2 > > > > > >>> sja1000_plx_pci 0000:0d:02.0: Channel #1 at > > > > > >>>0x0000000000012280, irq 22 registered as can0 > > > > > >>> sja1000_plx_pci 0000:0d:02.0: Channel #2 at > > > > > >>>0x0000000000012300, irq 22 registered as can1 > > > > > >>> sja1000_plx_pci 0000:0d:02.0 can0: setting BTR0=0x03 BTR1=0x37 > > > > > >>> > > > > > >>>One option is always to bisect between v4.2 and v4.3 to see which > > > > > >>>commit made it stop working. See > > > > > >>>https://git-scm.com/docs/git-bisect > > > > > >> > > > > > >>Jiang, Олег bisected this to 991de2e59090 ("PCI, x86: Implement > > > > > >>pcibios_alloc_irq() and pcibios_free_irq()"). > > > > > >> > > > > > >>Олег, please double-check and confirm that 890e4847587f works and > > > > > >>991de2e59090 fails. > > > > > >> > > > > > >>Then please add some printks in the pcibios_enable_device() and > > > > > >>pcibios_alloc_irq() paths and in your driver to see exactly what > > > > > >>changed > > > > > >>between 890e4847587f and 991de2e59090 > > > > > >> > > > > > >>Bjorn > > > > > >> > > > > > >>>>23.01.2016 17:54, Bjorn Helgaas пишет: > > > > > >>>>>[+cc linux-kernel] > > > > > >>>>> > > > > > >>>>>Hi Олег, > > > > > >>>>> > > > > > >>>>>On Sat, Jan 23, 2016 at 1:08 AM, Олег Мороз > > > > > >>>>> > > > > > >>>>><oleg.moroz@mcc.vniiem.ru> wrote: > > > > > >>>>>>Hello. I've got a device driver for MIL-1553b card > > > > > >>>>>>called TA1-PCI, which > > > > > >>>>>>could be found at > > > > > >>>>>>https://github.com/qmor/elcus-1553-driver-linux > > > > > >>>>>>Card is using PLX_PCI9030 PCI controller. > > > > > >>>>>>Today i've found that this driver compiles, installes, > > > > > >>>>>>but is not working as > > > > > >>>>>>it should. > > > > > >>>>>>Looks like it not receives any interrupts from PCI. I've > > > > > >>>>>>test it again with > > > > > >>>>>>kernel > > > > > >>>>>>4.2 and it works okay. What changes was made in PCI > > > > > >>>>>>subsystem from 4.2 to > > > > > >>>>>>4.3 > > > > > >>>>>>which could have impact this driver work. > > > > > >>>>> > > > > > >>>>>Thank you very much for this problem report. There were many PCI > > > > > >>>>>changes between v4.2 and v4.3, and without more information, I > > > > > >>>>>can't > > > > > >>>>>guess what might be causing this problem. > > > > > >>>>> > > > > > >>>>>I opened a bug report at > > > > > >>>>>https://bugzilla.kernel.org/show_bug.cgi?id=111211 > > > > > >>>>> > > > > > >>>>>Please attach complete dmesg logs for both v4.2 and v4.3 to that > > > > > >>>>>bug > > > > > >>>>>report. Also, please attach the complete "lspci -vv" output (as > > > > > >>>>>root). > > > > > >>>>> > > > > > >>>>>Thanks! > > > > > >>>>> > > > > > >>>>>Bjorn > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: PCI device driver broken between 4.2 and 4.3 2016-02-01 21:08 ` Bjorn Helgaas @ 2016-02-02 5:04 ` Олег Мороз 2016-02-02 16:13 ` Bjorn Helgaas 0 siblings, 1 reply; 19+ messages in thread From: Олег Мороз @ 2016-02-02 5:04 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: linux-kernel, Bjorn Helgaas, Jiang Liu, linux-pci it looks much better with pci=routeirq [ 100.896723] *Before pci_enable_device IRQ 20* [ 100.896735] *After pci_enable_device IRQ 20* [ 100.896745] *Before pci_enable_device IRQ 21* [ 100.896752] *After pci_enable_device IRQ 21* On Monday 01 of February 2016 15:08:23 Bjorn Helgaas wrote: > [+cc Yinghai] > > On Mon, Feb 01, 2016 at 08:18:35AM +0300, Олег Мороз wrote: > > Okay. I've started from driver level printk > > results are: > > > > On 4.2 > > > > [414006.575989] Before pci_enable_device IRQ 20 > > > > [414006.575991] After pci_enable_device IRQ 20 > > > > [414006.575997] Before pci_enable_device IRQ 21 > > > > [414006.575999] After pci_enable_device IRQ 21 > > > > on 4.3 > > > > [ 114.862289] Before pci_enable_device IRQ 5 > > > > [ 114.862303] After pci_enable_device IRQ 5 > > > > [ 114.862316] Before pci_enable_device IRQ 5 > > > > [ 114.862326] After pci_enable_device IRQ 5 > > > > I've got two cards, because of that pci_enable_device() calls twice. > > Did you try booting with pci=routeirq as Yinghai suggested? That's > not a fix, but if it does make things work, it may give us an idea for > how to fix it correctly. > > > On Friday 29 of January 2016 10:31:59 Bjorn Helgaas wrote: > > > On Thu, Jan 28, 2016 at 10:28:14PM +0300, Мороз Олег wrote: > > > > What i need to print out at first order? > > > > > > Jiang, can you chime in here? > > > > > > 991de2e59090 is related to IRQs, so I'd start by printing dev->irq in > > > your > > > driver before and after you call pci_enable_device(). Add some printks > > > in > > > pcibios_alloc_irq() and pcibios_enable_device() just to confirm that we > > > got > > > > > > there and when, e.g., add lines like this: > > > dev_info(&dev->dev, "%s\n", __func__); > > > > > > Bjorn > > > > > > > 27 янв. 2016 г. 16:22 пользователь Bjorn Helgaas <helgaas@kernel.org> > > > > написал: > > > > > On Wed, Jan 27, 2016 at 12:38:06PM +0300, Мороз Олег wrote: > > > > > > Also, my drive has no > > > > > > > > > > > > pcibios_enable_device() > > > > > > pcibios_alloc_irq() > > > > > > > > > > > > calls. > > > > > > > > > > Those are internal interfaces used by the PCI core. Drivers > > > > > shouldn't > > > > > call them directly. Drivers normally call pci_enable_device(), and > > > > > those internal interfaces are used in that path. > > > > > > > > > > > 26.01.2016 22:05, Олег Мороз пишет: > > > > > > >I confirmed it works in > > > > > > > > > > > > > >890e4847587f > > > > > > > > > > > > > >and do not works in > > > > > > > > > > > > > >991de2e59090 > > > > > > > > > > > > > >26.01.2016 18:32, Bjorn Helgaas пишет: > > > > > > >>[+cc Jiang] > > > > > > >> > > > > > > >>On Mon, Jan 25, 2016 at 03:52:51PM -0600, Bjorn Helgaas wrote: > > > > > > >>>Hi Олег, > > > > > > >>> > > > > > > >>>On Sun, Jan 24, 2016 at 04:50:08PM +0300, Олег Мороз wrote: > > > > > > >>>>Okay. I've sent logs (dmesg and lspci) from both 4.2 and 4.3 > > > > > > >>>>to bugzilla > > > > > > >>> > > > > > > >>>I don't see anything wrong in either log. Both v4.2 and v4.3 > > > > > > >>>enumerate the device the same way, and the driver seems to > > > > > > >>>claim it > > > > > > >>> > > > > > > >>>the same way: > > > > > > >>> pci 0000:0d:00.0: [10b5:9030] type 00 class 0x078000 > > > > > > >>> pci 0000:0d:00.0: reg 0x14: [io 0x2100-0x217f] > > > > > > >>> pci 0000:0d:00.0: reg 0x18: [io 0x2380-0x239f] > > > > > > >>> pci 0000:0d:00.0: PME# supported from D0 D3hot > > > > > > >>> pci 0000:0d:01.0: [10b5:9030] type 00 class 0x078000 > > > > > > >>> pci 0000:0d:01.0: reg 0x14: [io 0x2180-0x21ff] > > > > > > >>> pci 0000:0d:01.0: reg 0x18: [io 0x23a0-0x23bf] > > > > > > >>> pci 0000:0d:01.0: PME# supported from D0 D3hot > > > > > > >>> pci 0000:0d:02.0: [10b5:9030] type 00 class 0x078000 > > > > > > >>> pci 0000:0d:02.0: reg 0x14: [io 0x2200-0x227f] > > > > > > >>> pci 0000:0d:02.0: reg 0x18: [io 0x2280-0x22ff] > > > > > > >>> pci 0000:0d:02.0: reg 0x1c: [io 0x2300-0x237f] > > > > > > >>> pci 0000:0d:02.0: PME# supported from D0 D3hot > > > > > > >>> > > > > > > >>> sja1000_plx_pci 0000:0d:02.0: Detected "Eclus CAN-200-PCI" > > > > > > >>> > > > > > > >>>card at slot #2 > > > > > > >>> > > > > > > >>> sja1000_plx_pci 0000:0d:02.0: Channel #1 at > > > > > > >>> > > > > > > >>>0x0000000000012280, irq 22 registered as can0 > > > > > > >>> > > > > > > >>> sja1000_plx_pci 0000:0d:02.0: Channel #2 at > > > > > > >>> > > > > > > >>>0x0000000000012300, irq 22 registered as can1 > > > > > > >>> > > > > > > >>> sja1000_plx_pci 0000:0d:02.0 can0: setting BTR0=0x03 > > > > > > >>> BTR1=0x37 > > > > > > >>> > > > > > > >>>One option is always to bisect between v4.2 and v4.3 to see > > > > > > >>>which > > > > > > >>>commit made it stop working. See > > > > > > >>>https://git-scm.com/docs/git-bisect > > > > > > >> > > > > > > >>Jiang, Олег bisected this to 991de2e59090 ("PCI, x86: Implement > > > > > > >>pcibios_alloc_irq() and pcibios_free_irq()"). > > > > > > >> > > > > > > >>Олег, please double-check and confirm that 890e4847587f works > > > > > > >>and > > > > > > >>991de2e59090 fails. > > > > > > >> > > > > > > >>Then please add some printks in the pcibios_enable_device() and > > > > > > >>pcibios_alloc_irq() paths and in your driver to see exactly what > > > > > > >>changed > > > > > > >>between 890e4847587f and 991de2e59090 > > > > > > >> > > > > > > >>Bjorn > > > > > > >> > > > > > > >>>>23.01.2016 17:54, Bjorn Helgaas пишет: > > > > > > >>>>>[+cc linux-kernel] > > > > > > >>>>> > > > > > > >>>>>Hi Олег, > > > > > > >>>>> > > > > > > >>>>>On Sat, Jan 23, 2016 at 1:08 AM, Олег Мороз > > > > > > >>>>> > > > > > > >>>>><oleg.moroz@mcc.vniiem.ru> wrote: > > > > > > >>>>>>Hello. I've got a device driver for MIL-1553b card > > > > > > >>>>>>called TA1-PCI, which > > > > > > >>>>>>could be found at > > > > > > >>>>>>https://github.com/qmor/elcus-1553-driver-linux > > > > > > >>>>>>Card is using PLX_PCI9030 PCI controller. > > > > > > >>>>>>Today i've found that this driver compiles, installes, > > > > > > >>>>>>but is not working as > > > > > > >>>>>>it should. > > > > > > >>>>>>Looks like it not receives any interrupts from PCI. I've > > > > > > >>>>>>test it again with > > > > > > >>>>>>kernel > > > > > > >>>>>>4.2 and it works okay. What changes was made in PCI > > > > > > >>>>>>subsystem from 4.2 to > > > > > > >>>>>>4.3 > > > > > > >>>>>>which could have impact this driver work. > > > > > > >>>>> > > > > > > >>>>>Thank you very much for this problem report. There were many > > > > > > >>>>>PCI > > > > > > >>>>>changes between v4.2 and v4.3, and without more information, > > > > > > >>>>>I > > > > > > >>>>>can't > > > > > > >>>>>guess what might be causing this problem. > > > > > > >>>>> > > > > > > >>>>>I opened a bug report at > > > > > > >>>>>https://bugzilla.kernel.org/show_bug.cgi?id=111211 > > > > > > >>>>> > > > > > > >>>>>Please attach complete dmesg logs for both v4.2 and v4.3 to > > > > > > >>>>>that > > > > > > >>>>>bug > > > > > > >>>>>report. Also, please attach the complete "lspci -vv" output > > > > > > >>>>>(as > > > > > > >>>>>root). > > > > > > >>>>> > > > > > > >>>>>Thanks! > > > > > > >>>>> > > > > > > >>>>>Bjorn > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html -- С уважением, Олег Мороз Заместитель начальника отдела разработки ПО БВС КА ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: PCI device driver broken between 4.2 and 4.3 2016-02-02 5:04 ` Олег Мороз @ 2016-02-02 16:13 ` Bjorn Helgaas 2016-02-02 16:17 ` Олег Мороз 0 siblings, 1 reply; 19+ messages in thread From: Bjorn Helgaas @ 2016-02-02 16:13 UTC (permalink / raw) To: Олег Мороз Cc: linux-kernel, Bjorn Helgaas, Jiang Liu, linux-pci On Tue, Feb 02, 2016 at 08:04:39AM +0300, Олег Мороз wrote: > it looks much better with pci=routeirq > > [ 100.896723] *Before pci_enable_device IRQ 20* > [ 100.896735] *After pci_enable_device IRQ 20* > [ 100.896745] *Before pci_enable_device IRQ 21* > [ 100.896752] *After pci_enable_device IRQ 21* If pci=routeirq makes a difference, it usually means your driver is looking at dev->irq before it calls pci_enable_device(). I looked at what I think is your driver (https://github.com/qmor/elcus-1553-driver-linux/blob/master/driver/tmk1553.c), but I didn't *see* that problem. It does use a highly unconventional strategy of calling pci_get_device() to locate devices, instead of using pci_register_driver() like normal drivers do. You should not have to use pci=routeirq, and I've even considered removing the option. > On Monday 01 of February 2016 15:08:23 Bjorn Helgaas wrote: > > [+cc Yinghai] > > > > On Mon, Feb 01, 2016 at 08:18:35AM +0300, Олег Мороз wrote: > > > Okay. I've started from driver level printk > > > results are: > > > > > > On 4.2 > > > > > > [414006.575989] Before pci_enable_device IRQ 20 > > > > > > [414006.575991] After pci_enable_device IRQ 20 > > > > > > [414006.575997] Before pci_enable_device IRQ 21 > > > > > > [414006.575999] After pci_enable_device IRQ 21 > > > > > > on 4.3 > > > > > > [ 114.862289] Before pci_enable_device IRQ 5 > > > > > > [ 114.862303] After pci_enable_device IRQ 5 > > > > > > [ 114.862316] Before pci_enable_device IRQ 5 > > > > > > [ 114.862326] After pci_enable_device IRQ 5 > > > > > > I've got two cards, because of that pci_enable_device() calls twice. > > > > Did you try booting with pci=routeirq as Yinghai suggested? That's > > not a fix, but if it does make things work, it may give us an idea for > > how to fix it correctly. > > > > > On Friday 29 of January 2016 10:31:59 Bjorn Helgaas wrote: > > > > On Thu, Jan 28, 2016 at 10:28:14PM +0300, Мороз Олег wrote: > > > > > What i need to print out at first order? > > > > > > > > Jiang, can you chime in here? > > > > > > > > 991de2e59090 is related to IRQs, so I'd start by printing dev->irq in > > > > your > > > > driver before and after you call pci_enable_device(). Add some printks > > > > in > > > > pcibios_alloc_irq() and pcibios_enable_device() just to confirm that we > > > > got > > > > > > > > there and when, e.g., add lines like this: > > > > dev_info(&dev->dev, "%s\n", __func__); > > > > > > > > Bjorn > > > > > > > > > 27 янв. 2016 г. 16:22 пользователь Bjorn Helgaas <helgaas@kernel.org> > > > > > > написал: > > > > > > On Wed, Jan 27, 2016 at 12:38:06PM +0300, Мороз Олег wrote: > > > > > > > Also, my drive has no > > > > > > > > > > > > > > pcibios_enable_device() > > > > > > > pcibios_alloc_irq() > > > > > > > > > > > > > > calls. > > > > > > > > > > > > Those are internal interfaces used by the PCI core. Drivers > > > > > > shouldn't > > > > > > call them directly. Drivers normally call pci_enable_device(), and > > > > > > those internal interfaces are used in that path. > > > > > > > > > > > > > 26.01.2016 22:05, Олег Мороз пишет: > > > > > > > >I confirmed it works in > > > > > > > > > > > > > > > >890e4847587f > > > > > > > > > > > > > > > >and do not works in > > > > > > > > > > > > > > > >991de2e59090 > > > > > > > > > > > > > > > >26.01.2016 18:32, Bjorn Helgaas пишет: > > > > > > > >>[+cc Jiang] > > > > > > > >> > > > > > > > >>On Mon, Jan 25, 2016 at 03:52:51PM -0600, Bjorn Helgaas wrote: > > > > > > > >>>Hi Олег, > > > > > > > >>> > > > > > > > >>>On Sun, Jan 24, 2016 at 04:50:08PM +0300, Олег Мороз wrote: > > > > > > > >>>>Okay. I've sent logs (dmesg and lspci) from both 4.2 and 4.3 > > > > > > > >>>>to bugzilla > > > > > > > >>> > > > > > > > >>>I don't see anything wrong in either log. Both v4.2 and v4.3 > > > > > > > >>>enumerate the device the same way, and the driver seems to > > > > > > > >>>claim it > > > > > > > >>> > > > > > > > >>>the same way: > > > > > > > >>> pci 0000:0d:00.0: [10b5:9030] type 00 class 0x078000 > > > > > > > >>> pci 0000:0d:00.0: reg 0x14: [io 0x2100-0x217f] > > > > > > > >>> pci 0000:0d:00.0: reg 0x18: [io 0x2380-0x239f] > > > > > > > >>> pci 0000:0d:00.0: PME# supported from D0 D3hot > > > > > > > >>> pci 0000:0d:01.0: [10b5:9030] type 00 class 0x078000 > > > > > > > >>> pci 0000:0d:01.0: reg 0x14: [io 0x2180-0x21ff] > > > > > > > >>> pci 0000:0d:01.0: reg 0x18: [io 0x23a0-0x23bf] > > > > > > > >>> pci 0000:0d:01.0: PME# supported from D0 D3hot > > > > > > > >>> pci 0000:0d:02.0: [10b5:9030] type 00 class 0x078000 > > > > > > > >>> pci 0000:0d:02.0: reg 0x14: [io 0x2200-0x227f] > > > > > > > >>> pci 0000:0d:02.0: reg 0x18: [io 0x2280-0x22ff] > > > > > > > >>> pci 0000:0d:02.0: reg 0x1c: [io 0x2300-0x237f] > > > > > > > >>> pci 0000:0d:02.0: PME# supported from D0 D3hot > > > > > > > >>> > > > > > > > >>> sja1000_plx_pci 0000:0d:02.0: Detected "Eclus CAN-200-PCI" > > > > > > > >>> > > > > > > > >>>card at slot #2 > > > > > > > >>> > > > > > > > >>> sja1000_plx_pci 0000:0d:02.0: Channel #1 at > > > > > > > >>> > > > > > > > >>>0x0000000000012280, irq 22 registered as can0 > > > > > > > >>> > > > > > > > >>> sja1000_plx_pci 0000:0d:02.0: Channel #2 at > > > > > > > >>> > > > > > > > >>>0x0000000000012300, irq 22 registered as can1 > > > > > > > >>> > > > > > > > >>> sja1000_plx_pci 0000:0d:02.0 can0: setting BTR0=0x03 > > > > > > > >>> BTR1=0x37 > > > > > > > >>> > > > > > > > >>>One option is always to bisect between v4.2 and v4.3 to see > > > > > > > >>>which > > > > > > > >>>commit made it stop working. See > > > > > > > >>>https://git-scm.com/docs/git-bisect > > > > > > > >> > > > > > > > >>Jiang, Олег bisected this to 991de2e59090 ("PCI, x86: Implement > > > > > > > >>pcibios_alloc_irq() and pcibios_free_irq()"). > > > > > > > >> > > > > > > > >>Олег, please double-check and confirm that 890e4847587f works > > > > > > > >>and > > > > > > > >>991de2e59090 fails. > > > > > > > >> > > > > > > > >>Then please add some printks in the pcibios_enable_device() and > > > > > > > >>pcibios_alloc_irq() paths and in your driver to see exactly what > > > > > > > >>changed > > > > > > > >>between 890e4847587f and 991de2e59090 > > > > > > > >> > > > > > > > >>Bjorn > > > > > > > >> > > > > > > > >>>>23.01.2016 17:54, Bjorn Helgaas пишет: > > > > > > > >>>>>[+cc linux-kernel] > > > > > > > >>>>> > > > > > > > >>>>>Hi Олег, > > > > > > > >>>>> > > > > > > > >>>>>On Sat, Jan 23, 2016 at 1:08 AM, Олег Мороз > > > > > > > >>>>> > > > > > > > >>>>><oleg.moroz@mcc.vniiem.ru> wrote: > > > > > > > >>>>>>Hello. I've got a device driver for MIL-1553b card > > > > > > > >>>>>>called TA1-PCI, which > > > > > > > >>>>>>could be found at > > > > > > > >>>>>>https://github.com/qmor/elcus-1553-driver-linux > > > > > > > >>>>>>Card is using PLX_PCI9030 PCI controller. > > > > > > > >>>>>>Today i've found that this driver compiles, installes, > > > > > > > >>>>>>but is not working as > > > > > > > >>>>>>it should. > > > > > > > >>>>>>Looks like it not receives any interrupts from PCI. I've > > > > > > > >>>>>>test it again with > > > > > > > >>>>>>kernel > > > > > > > >>>>>>4.2 and it works okay. What changes was made in PCI > > > > > > > >>>>>>subsystem from 4.2 to > > > > > > > >>>>>>4.3 > > > > > > > >>>>>>which could have impact this driver work. > > > > > > > >>>>> > > > > > > > >>>>>Thank you very much for this problem report. There were many > > > > > > > >>>>>PCI > > > > > > > >>>>>changes between v4.2 and v4.3, and without more information, > > > > > > > >>>>>I > > > > > > > >>>>>can't > > > > > > > >>>>>guess what might be causing this problem. > > > > > > > >>>>> > > > > > > > >>>>>I opened a bug report at > > > > > > > >>>>>https://bugzilla.kernel.org/show_bug.cgi?id=111211 > > > > > > > >>>>> > > > > > > > >>>>>Please attach complete dmesg logs for both v4.2 and v4.3 to > > > > > > > >>>>>that > > > > > > > >>>>>bug > > > > > > > >>>>>report. Also, please attach the complete "lspci -vv" output > > > > > > > >>>>>(as > > > > > > > >>>>>root). > > > > > > > >>>>> > > > > > > > >>>>>Thanks! > > > > > > > >>>>> > > > > > > > >>>>>Bjorn > > > > > > -- > > > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > > > the body of a message to majordomo@vger.kernel.org > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > С уважением, > Олег Мороз > Заместитель начальника отдела разработки ПО БВС КА > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: PCI device driver broken between 4.2 and 4.3 2016-02-02 16:13 ` Bjorn Helgaas @ 2016-02-02 16:17 ` Олег Мороз 2016-02-05 14:29 ` Bjorn Helgaas 0 siblings, 1 reply; 19+ messages in thread From: Олег Мороз @ 2016-02-02 16:17 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: linux-kernel, Bjorn Helgaas, Jiang Liu, linux-pci Ohhh. It's not my driver from scratch. I'm just trying to maintain it in working state. Could you please advice me some correct and small and simple (I know I ask a lot) PCI driver as example. Maybe it will be not so hard to fix this 1553b driver. 02.02.2016 19:13, Bjorn Helgaas пишет: > On Tue, Feb 02, 2016 at 08:04:39AM +0300, Олег Мороз wrote: >> it looks much better with pci=routeirq >> >> [ 100.896723] *Before pci_enable_device IRQ 20* >> [ 100.896735] *After pci_enable_device IRQ 20* >> [ 100.896745] *Before pci_enable_device IRQ 21* >> [ 100.896752] *After pci_enable_device IRQ 21* > If pci=routeirq makes a difference, it usually means your driver is > looking at dev->irq before it calls pci_enable_device(). I looked at > what I think is your driver > (https://github.com/qmor/elcus-1553-driver-linux/blob/master/driver/tmk1553.c), > but I didn't *see* that problem. It does use a highly unconventional > strategy of calling pci_get_device() to locate devices, instead of > using pci_register_driver() like normal drivers do. > > You should not have to use pci=routeirq, and I've even considered > removing the option. > >> On Monday 01 of February 2016 15:08:23 Bjorn Helgaas wrote: >>> [+cc Yinghai] >>> >>> On Mon, Feb 01, 2016 at 08:18:35AM +0300, Олег Мороз wrote: >>>> Okay. I've started from driver level printk >>>> results are: >>>> >>>> On 4.2 >>>> >>>> [414006.575989] Before pci_enable_device IRQ 20 >>>> >>>> [414006.575991] After pci_enable_device IRQ 20 >>>> >>>> [414006.575997] Before pci_enable_device IRQ 21 >>>> >>>> [414006.575999] After pci_enable_device IRQ 21 >>>> >>>> on 4.3 >>>> >>>> [ 114.862289] Before pci_enable_device IRQ 5 >>>> >>>> [ 114.862303] After pci_enable_device IRQ 5 >>>> >>>> [ 114.862316] Before pci_enable_device IRQ 5 >>>> >>>> [ 114.862326] After pci_enable_device IRQ 5 >>>> >>>> I've got two cards, because of that pci_enable_device() calls twice. >>> Did you try booting with pci=routeirq as Yinghai suggested? That's >>> not a fix, but if it does make things work, it may give us an idea for >>> how to fix it correctly. >>> >>>> On Friday 29 of January 2016 10:31:59 Bjorn Helgaas wrote: >>>>> On Thu, Jan 28, 2016 at 10:28:14PM +0300, Мороз Олег wrote: >>>>>> What i need to print out at first order? >>>>> Jiang, can you chime in here? >>>>> >>>>> 991de2e59090 is related to IRQs, so I'd start by printing dev->irq in >>>>> your >>>>> driver before and after you call pci_enable_device(). Add some printks >>>>> in >>>>> pcibios_alloc_irq() and pcibios_enable_device() just to confirm that we >>>>> got >>>>> >>>>> there and when, e.g., add lines like this: >>>>> dev_info(&dev->dev, "%s\n", __func__); >>>>> >>>>> Bjorn >>>>> >>>>>> 27 янв. 2016 г. 16:22 пользователь Bjorn Helgaas <helgaas@kernel.org> >>>> написал: >>>>>>> On Wed, Jan 27, 2016 at 12:38:06PM +0300, Мороз Олег wrote: >>>>>>>> Also, my drive has no >>>>>>>> >>>>>>>> pcibios_enable_device() >>>>>>>> pcibios_alloc_irq() >>>>>>>> >>>>>>>> calls. >>>>>>> Those are internal interfaces used by the PCI core. Drivers >>>>>>> shouldn't >>>>>>> call them directly. Drivers normally call pci_enable_device(), and >>>>>>> those internal interfaces are used in that path. >>>>>>> >>>>>>>> 26.01.2016 22:05, Олег Мороз пишет: >>>>>>>>> I confirmed it works in >>>>>>>>> >>>>>>>>> 890e4847587f >>>>>>>>> >>>>>>>>> and do not works in >>>>>>>>> >>>>>>>>> 991de2e59090 >>>>>>>>> >>>>>>>>> 26.01.2016 18:32, Bjorn Helgaas пишет: >>>>>>>>>> [+cc Jiang] >>>>>>>>>> >>>>>>>>>> On Mon, Jan 25, 2016 at 03:52:51PM -0600, Bjorn Helgaas wrote: >>>>>>>>>>> Hi Олег, >>>>>>>>>>> >>>>>>>>>>> On Sun, Jan 24, 2016 at 04:50:08PM +0300, Олег Мороз wrote: >>>>>>>>>>>> Okay. I've sent logs (dmesg and lspci) from both 4.2 and 4.3 >>>>>>>>>>>> to bugzilla >>>>>>>>>>> I don't see anything wrong in either log. Both v4.2 and v4.3 >>>>>>>>>>> enumerate the device the same way, and the driver seems to >>>>>>>>>>> claim it >>>>>>>>>>> >>>>>>>>>>> the same way: >>>>>>>>>>> pci 0000:0d:00.0: [10b5:9030] type 00 class 0x078000 >>>>>>>>>>> pci 0000:0d:00.0: reg 0x14: [io 0x2100-0x217f] >>>>>>>>>>> pci 0000:0d:00.0: reg 0x18: [io 0x2380-0x239f] >>>>>>>>>>> pci 0000:0d:00.0: PME# supported from D0 D3hot >>>>>>>>>>> pci 0000:0d:01.0: [10b5:9030] type 00 class 0x078000 >>>>>>>>>>> pci 0000:0d:01.0: reg 0x14: [io 0x2180-0x21ff] >>>>>>>>>>> pci 0000:0d:01.0: reg 0x18: [io 0x23a0-0x23bf] >>>>>>>>>>> pci 0000:0d:01.0: PME# supported from D0 D3hot >>>>>>>>>>> pci 0000:0d:02.0: [10b5:9030] type 00 class 0x078000 >>>>>>>>>>> pci 0000:0d:02.0: reg 0x14: [io 0x2200-0x227f] >>>>>>>>>>> pci 0000:0d:02.0: reg 0x18: [io 0x2280-0x22ff] >>>>>>>>>>> pci 0000:0d:02.0: reg 0x1c: [io 0x2300-0x237f] >>>>>>>>>>> pci 0000:0d:02.0: PME# supported from D0 D3hot >>>>>>>>>>> >>>>>>>>>>> sja1000_plx_pci 0000:0d:02.0: Detected "Eclus CAN-200-PCI" >>>>>>>>>>> >>>>>>>>>>> card at slot #2 >>>>>>>>>>> >>>>>>>>>>> sja1000_plx_pci 0000:0d:02.0: Channel #1 at >>>>>>>>>>> >>>>>>>>>>> 0x0000000000012280, irq 22 registered as can0 >>>>>>>>>>> >>>>>>>>>>> sja1000_plx_pci 0000:0d:02.0: Channel #2 at >>>>>>>>>>> >>>>>>>>>>> 0x0000000000012300, irq 22 registered as can1 >>>>>>>>>>> >>>>>>>>>>> sja1000_plx_pci 0000:0d:02.0 can0: setting BTR0=0x03 >>>>>>>>>>> BTR1=0x37 >>>>>>>>>>> >>>>>>>>>>> One option is always to bisect between v4.2 and v4.3 to see >>>>>>>>>>> which >>>>>>>>>>> commit made it stop working. See >>>>>>>>>>> https://git-scm.com/docs/git-bisect >>>>>>>>>> Jiang, Олег bisected this to 991de2e59090 ("PCI, x86: Implement >>>>>>>>>> pcibios_alloc_irq() and pcibios_free_irq()"). >>>>>>>>>> >>>>>>>>>> Олег, please double-check and confirm that 890e4847587f works >>>>>>>>>> and >>>>>>>>>> 991de2e59090 fails. >>>>>>>>>> >>>>>>>>>> Then please add some printks in the pcibios_enable_device() and >>>>>>>>>> pcibios_alloc_irq() paths and in your driver to see exactly what >>>>>>>>>> changed >>>>>>>>>> between 890e4847587f and 991de2e59090 >>>>>>>>>> >>>>>>>>>> Bjorn >>>>>>>>>> >>>>>>>>>>>> 23.01.2016 17:54, Bjorn Helgaas пишет: >>>>>>>>>>>>> [+cc linux-kernel] >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Олег, >>>>>>>>>>>>> >>>>>>>>>>>>> On Sat, Jan 23, 2016 at 1:08 AM, Олег Мороз >>>>>>>>>>>>> >>>>>>>>>>>>> <oleg.moroz@mcc.vniiem.ru> wrote: >>>>>>>>>>>>>> Hello. I've got a device driver for MIL-1553b card >>>>>>>>>>>>>> called TA1-PCI, which >>>>>>>>>>>>>> could be found at >>>>>>>>>>>>>> https://github.com/qmor/elcus-1553-driver-linux >>>>>>>>>>>>>> Card is using PLX_PCI9030 PCI controller. >>>>>>>>>>>>>> Today i've found that this driver compiles, installes, >>>>>>>>>>>>>> but is not working as >>>>>>>>>>>>>> it should. >>>>>>>>>>>>>> Looks like it not receives any interrupts from PCI. I've >>>>>>>>>>>>>> test it again with >>>>>>>>>>>>>> kernel >>>>>>>>>>>>>> 4.2 and it works okay. What changes was made in PCI >>>>>>>>>>>>>> subsystem from 4.2 to >>>>>>>>>>>>>> 4.3 >>>>>>>>>>>>>> which could have impact this driver work. >>>>>>>>>>>>> Thank you very much for this problem report. There were many >>>>>>>>>>>>> PCI >>>>>>>>>>>>> changes between v4.2 and v4.3, and without more information, >>>>>>>>>>>>> I >>>>>>>>>>>>> can't >>>>>>>>>>>>> guess what might be causing this problem. >>>>>>>>>>>>> >>>>>>>>>>>>> I opened a bug report at >>>>>>>>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=111211 >>>>>>>>>>>>> >>>>>>>>>>>>> Please attach complete dmesg logs for both v4.2 and v4.3 to >>>>>>>>>>>>> that >>>>>>>>>>>>> bug >>>>>>>>>>>>> report. Also, please attach the complete "lspci -vv" output >>>>>>>>>>>>> (as >>>>>>>>>>>>> root). >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> >>>>>>>>>>>>> Bjorn >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in >>>> the body of a message to majordomo@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> -- >> С уважением, >> Олег Мороз >> Заместитель начальника отдела разработки ПО БВС КА >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-pci" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: PCI device driver broken between 4.2 and 4.3 2016-02-02 16:17 ` Олег Мороз @ 2016-02-05 14:29 ` Bjorn Helgaas 0 siblings, 0 replies; 19+ messages in thread From: Bjorn Helgaas @ 2016-02-05 14:29 UTC (permalink / raw) To: Олег Мороз Cc: linux-kernel, Bjorn Helgaas, Jiang Liu, linux-pci On Tue, Feb 02, 2016 at 07:17:02PM +0300, Олег Мороз wrote: > Ohhh. It's not my driver from scratch. I'm just trying to maintain > it in working state. > Could you please advice me some correct and small and simple (I know > I ask a lot) PCI driver as example. Maybe it will be not so hard to > fix this 1553b driver. The best thing is to get that driver included in the Linux kernel source. Then we can avoid a lot of problems because we will update it to match kernel updates, and when problems do occur, they're a lot easier to debug and fix. This book: https://lwn.net/Kernel/LDD3/ contains examples. drivers/nvme/host/pci.c is a relatively new, clean driver, but probably not very simple. > 02.02.2016 19:13, Bjorn Helgaas пишет: > >On Tue, Feb 02, 2016 at 08:04:39AM +0300, Олег Мороз wrote: > >>it looks much better with pci=routeirq > >> > >>[ 100.896723] *Before pci_enable_device IRQ 20* > >>[ 100.896735] *After pci_enable_device IRQ 20* > >>[ 100.896745] *Before pci_enable_device IRQ 21* > >>[ 100.896752] *After pci_enable_device IRQ 21* > >If pci=routeirq makes a difference, it usually means your driver is > >looking at dev->irq before it calls pci_enable_device(). I looked at > >what I think is your driver > >(https://github.com/qmor/elcus-1553-driver-linux/blob/master/driver/tmk1553.c), > >but I didn't *see* that problem. It does use a highly unconventional > >strategy of calling pci_get_device() to locate devices, instead of > >using pci_register_driver() like normal drivers do. > > > >You should not have to use pci=routeirq, and I've even considered > >removing the option. > > > >>On Monday 01 of February 2016 15:08:23 Bjorn Helgaas wrote: > >>>[+cc Yinghai] > >>> > >>>On Mon, Feb 01, 2016 at 08:18:35AM +0300, Олег Мороз wrote: > >>>>Okay. I've started from driver level printk > >>>>results are: > >>>> > >>>>On 4.2 > >>>> > >>>>[414006.575989] Before pci_enable_device IRQ 20 > >>>> > >>>>[414006.575991] After pci_enable_device IRQ 20 > >>>> > >>>>[414006.575997] Before pci_enable_device IRQ 21 > >>>> > >>>>[414006.575999] After pci_enable_device IRQ 21 > >>>> > >>>>on 4.3 > >>>> > >>>>[ 114.862289] Before pci_enable_device IRQ 5 > >>>> > >>>>[ 114.862303] After pci_enable_device IRQ 5 > >>>> > >>>>[ 114.862316] Before pci_enable_device IRQ 5 > >>>> > >>>>[ 114.862326] After pci_enable_device IRQ 5 > >>>> > >>>>I've got two cards, because of that pci_enable_device() calls twice. > >>>Did you try booting with pci=routeirq as Yinghai suggested? That's > >>>not a fix, but if it does make things work, it may give us an idea for > >>>how to fix it correctly. > >>> > >>>>On Friday 29 of January 2016 10:31:59 Bjorn Helgaas wrote: > >>>>>On Thu, Jan 28, 2016 at 10:28:14PM +0300, Мороз Олег wrote: > >>>>>>What i need to print out at first order? > >>>>>Jiang, can you chime in here? > >>>>> > >>>>>991de2e59090 is related to IRQs, so I'd start by printing dev->irq in > >>>>>your > >>>>>driver before and after you call pci_enable_device(). Add some printks > >>>>>in > >>>>>pcibios_alloc_irq() and pcibios_enable_device() just to confirm that we > >>>>>got > >>>>> > >>>>>there and when, e.g., add lines like this: > >>>>> dev_info(&dev->dev, "%s\n", __func__); > >>>>> > >>>>>Bjorn > >>>>> > >>>>>>27 янв. 2016 г. 16:22 пользователь Bjorn Helgaas <helgaas@kernel.org> > >>>>написал: > >>>>>>>On Wed, Jan 27, 2016 at 12:38:06PM +0300, Мороз Олег wrote: > >>>>>>>>Also, my drive has no > >>>>>>>> > >>>>>>>>pcibios_enable_device() > >>>>>>>>pcibios_alloc_irq() > >>>>>>>> > >>>>>>>>calls. > >>>>>>>Those are internal interfaces used by the PCI core. Drivers > >>>>>>>shouldn't > >>>>>>>call them directly. Drivers normally call pci_enable_device(), and > >>>>>>>those internal interfaces are used in that path. > >>>>>>> > >>>>>>>>26.01.2016 22:05, Олег Мороз пишет: > >>>>>>>>>I confirmed it works in > >>>>>>>>> > >>>>>>>>>890e4847587f > >>>>>>>>> > >>>>>>>>>and do not works in > >>>>>>>>> > >>>>>>>>>991de2e59090 > >>>>>>>>> > >>>>>>>>>26.01.2016 18:32, Bjorn Helgaas пишет: > >>>>>>>>>>[+cc Jiang] > >>>>>>>>>> > >>>>>>>>>>On Mon, Jan 25, 2016 at 03:52:51PM -0600, Bjorn Helgaas wrote: > >>>>>>>>>>>Hi Олег, > >>>>>>>>>>> > >>>>>>>>>>>On Sun, Jan 24, 2016 at 04:50:08PM +0300, Олег Мороз wrote: > >>>>>>>>>>>>Okay. I've sent logs (dmesg and lspci) from both 4.2 and 4.3 > >>>>>>>>>>>>to bugzilla > >>>>>>>>>>>I don't see anything wrong in either log. Both v4.2 and v4.3 > >>>>>>>>>>>enumerate the device the same way, and the driver seems to > >>>>>>>>>>>claim it > >>>>>>>>>>> > >>>>>>>>>>>the same way: > >>>>>>>>>>> pci 0000:0d:00.0: [10b5:9030] type 00 class 0x078000 > >>>>>>>>>>> pci 0000:0d:00.0: reg 0x14: [io 0x2100-0x217f] > >>>>>>>>>>> pci 0000:0d:00.0: reg 0x18: [io 0x2380-0x239f] > >>>>>>>>>>> pci 0000:0d:00.0: PME# supported from D0 D3hot > >>>>>>>>>>> pci 0000:0d:01.0: [10b5:9030] type 00 class 0x078000 > >>>>>>>>>>> pci 0000:0d:01.0: reg 0x14: [io 0x2180-0x21ff] > >>>>>>>>>>> pci 0000:0d:01.0: reg 0x18: [io 0x23a0-0x23bf] > >>>>>>>>>>> pci 0000:0d:01.0: PME# supported from D0 D3hot > >>>>>>>>>>> pci 0000:0d:02.0: [10b5:9030] type 00 class 0x078000 > >>>>>>>>>>> pci 0000:0d:02.0: reg 0x14: [io 0x2200-0x227f] > >>>>>>>>>>> pci 0000:0d:02.0: reg 0x18: [io 0x2280-0x22ff] > >>>>>>>>>>> pci 0000:0d:02.0: reg 0x1c: [io 0x2300-0x237f] > >>>>>>>>>>> pci 0000:0d:02.0: PME# supported from D0 D3hot > >>>>>>>>>>> sja1000_plx_pci 0000:0d:02.0: Detected "Eclus CAN-200-PCI" > >>>>>>>>>>> > >>>>>>>>>>>card at slot #2 > >>>>>>>>>>> > >>>>>>>>>>> sja1000_plx_pci 0000:0d:02.0: Channel #1 at > >>>>>>>>>>> > >>>>>>>>>>>0x0000000000012280, irq 22 registered as can0 > >>>>>>>>>>> > >>>>>>>>>>> sja1000_plx_pci 0000:0d:02.0: Channel #2 at > >>>>>>>>>>> > >>>>>>>>>>>0x0000000000012300, irq 22 registered as can1 > >>>>>>>>>>> > >>>>>>>>>>> sja1000_plx_pci 0000:0d:02.0 can0: setting BTR0=0x03 > >>>>>>>>>>> BTR1=0x37 > >>>>>>>>>>> > >>>>>>>>>>>One option is always to bisect between v4.2 and v4.3 to see > >>>>>>>>>>>which > >>>>>>>>>>>commit made it stop working. See > >>>>>>>>>>>https://git-scm.com/docs/git-bisect > >>>>>>>>>>Jiang, Олег bisected this to 991de2e59090 ("PCI, x86: Implement > >>>>>>>>>>pcibios_alloc_irq() and pcibios_free_irq()"). > >>>>>>>>>> > >>>>>>>>>>Олег, please double-check and confirm that 890e4847587f works > >>>>>>>>>>and > >>>>>>>>>>991de2e59090 fails. > >>>>>>>>>> > >>>>>>>>>>Then please add some printks in the pcibios_enable_device() and > >>>>>>>>>>pcibios_alloc_irq() paths and in your driver to see exactly what > >>>>>>>>>>changed > >>>>>>>>>>between 890e4847587f and 991de2e59090 > >>>>>>>>>> > >>>>>>>>>>Bjorn > >>>>>>>>>> > >>>>>>>>>>>>23.01.2016 17:54, Bjorn Helgaas пишет: > >>>>>>>>>>>>>[+cc linux-kernel] > >>>>>>>>>>>>> > >>>>>>>>>>>>>Hi Олег, > >>>>>>>>>>>>> > >>>>>>>>>>>>>On Sat, Jan 23, 2016 at 1:08 AM, Олег Мороз > >>>>>>>>>>>>> > >>>>>>>>>>>>><oleg.moroz@mcc.vniiem.ru> wrote: > >>>>>>>>>>>>>>Hello. I've got a device driver for MIL-1553b card > >>>>>>>>>>>>>>called TA1-PCI, which > >>>>>>>>>>>>>>could be found at > >>>>>>>>>>>>>>https://github.com/qmor/elcus-1553-driver-linux > >>>>>>>>>>>>>>Card is using PLX_PCI9030 PCI controller. > >>>>>>>>>>>>>>Today i've found that this driver compiles, installes, > >>>>>>>>>>>>>>but is not working as > >>>>>>>>>>>>>>it should. > >>>>>>>>>>>>>>Looks like it not receives any interrupts from PCI. I've > >>>>>>>>>>>>>>test it again with > >>>>>>>>>>>>>>kernel > >>>>>>>>>>>>>>4.2 and it works okay. What changes was made in PCI > >>>>>>>>>>>>>>subsystem from 4.2 to > >>>>>>>>>>>>>>4.3 > >>>>>>>>>>>>>>which could have impact this driver work. > >>>>>>>>>>>>>Thank you very much for this problem report. There were many > >>>>>>>>>>>>>PCI > >>>>>>>>>>>>>changes between v4.2 and v4.3, and without more information, > >>>>>>>>>>>>>I > >>>>>>>>>>>>>can't > >>>>>>>>>>>>>guess what might be causing this problem. > >>>>>>>>>>>>> > >>>>>>>>>>>>>I opened a bug report at > >>>>>>>>>>>>>https://bugzilla.kernel.org/show_bug.cgi?id=111211 > >>>>>>>>>>>>> > >>>>>>>>>>>>>Please attach complete dmesg logs for both v4.2 and v4.3 to > >>>>>>>>>>>>>that > >>>>>>>>>>>>>bug > >>>>>>>>>>>>>report. Also, please attach the complete "lspci -vv" output > >>>>>>>>>>>>>(as > >>>>>>>>>>>>>root). > >>>>>>>>>>>>> > >>>>>>>>>>>>>Thanks! > >>>>>>>>>>>>> > >>>>>>>>>>>>>Bjorn > >>>>-- > >>>>To unsubscribe from this list: send the line "unsubscribe linux-pci" in > >>>>the body of a message to majordomo@vger.kernel.org > >>>>More majordomo info at http://vger.kernel.org/majordomo-info.html > >>-- > >>С уважением, > >>Олег Мороз > >>Заместитель начальника отдела разработки ПО БВС КА > >>-- > >>To unsubscribe from this list: send the line "unsubscribe linux-pci" in > >>the body of a message to majordomo@vger.kernel.org > >>More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: PCI device driver broken between 4.2 and 4.3 @ 2016-01-28 19:28 Мороз Олег 0 siblings, 0 replies; 19+ messages in thread From: Мороз Олег @ 2016-01-28 19:28 UTC (permalink / raw) To: Bjorn Helgaas Cc: linux-kernel@vger.kernel.org, Bjorn Helgaas, Jiang Liu, linux-pci@vger.kernel.org V2hhdCBpIG5lZWQgdG8gcHJpbnQgb3V0IGF0IGZpcnN0IG9yZGVyPyAyNyDRj9C90LIuIDIwMTYg 0LMuIDE2OjIyINC/0L7Qu9GM0LfQvtCy0LDRgtC10LvRjCBCam9ybiBIZWxnYWFzIDxoZWxnYWFz QGtlcm5lbC5vcmc+INC90LDQv9C40YHQsNC7Ogo+Cj4gT24gV2VkLCBKYW4gMjcsIDIwMTYgYXQg MTI6Mzg6MDZQTSArMDMwMCwg0JzQvtGA0L7QtyDQntC70LXQsyB3cm90ZTogCj4gPiBBbHNvLCBt eSBkcml2ZSBoYXMgbm8gCj4gPiAKPiA+IHBjaWJpb3NfZW5hYmxlX2RldmljZSgpIAo+ID4gcGNp Ymlvc19hbGxvY19pcnEoKSAKPiA+IAo+ID4gY2FsbHMuIAo+Cj4gVGhvc2UgYXJlIGludGVybmFs IGludGVyZmFjZXMgdXNlZCBieSB0aGUgUENJIGNvcmUuwqAgRHJpdmVycyBzaG91bGRuJ3QgCj4g Y2FsbCB0aGVtIGRpcmVjdGx5LsKgIERyaXZlcnMgbm9ybWFsbHkgY2FsbCBwY2lfZW5hYmxlX2Rl dmljZSgpLCBhbmQgCj4gdGhvc2UgaW50ZXJuYWwgaW50ZXJmYWNlcyBhcmUgdXNlZCBpbiB0aGF0 IHBhdGguIAo+Cj4gPiAyNi4wMS4yMDE2IDIyOjA1LCDQntC70LXQsyDQnNC+0YDQvtC3INC/0LjR iNC10YI6IAo+ID4gPkkgY29uZmlybWVkIGl0IHdvcmtzIGluIAo+ID4gPiAKPiA+ID44OTBlNDg0 NzU4N2YgCj4gPiA+IAo+ID4gPmFuZCBkbyBub3Qgd29ya3MgaW4gCj4gPiA+IAo+ID4gPjk5MWRl MmU1OTA5MCAKPiA+ID4gCj4gPiA+MjYuMDEuMjAxNiAxODozMiwgQmpvcm4gSGVsZ2FhcyDQv9C4 0YjQtdGCOiAKPiA+ID4+WytjYyBKaWFuZ10gCj4gPiA+PiAKPiA+ID4+T24gTW9uLCBKYW4gMjUs IDIwMTYgYXQgMDM6NTI6NTFQTSAtMDYwMCwgQmpvcm4gSGVsZ2FhcyB3cm90ZTogCj4gPiA+Pj5I aSDQntC70LXQsywgCj4gPiA+Pj4gCj4gPiA+Pj5PbiBTdW4sIEphbiAyNCwgMjAxNiBhdCAwNDo1 MDowOFBNICswMzAwLCDQntC70LXQsyDQnNC+0YDQvtC3IHdyb3RlOiAKPiA+ID4+Pj5Pa2F5LiBJ J3ZlIHNlbnQgbG9ncyAoZG1lc2cgYW5kIGxzcGNpKSBmcm9tIGJvdGggNC4yIGFuZCA0LjMgCj4g PiA+Pj4+dG8gYnVnemlsbGEgCj4gPiA+Pj5JIGRvbid0IHNlZSBhbnl0aGluZyB3cm9uZyBpbiBl aXRoZXIgbG9nLsKgIEJvdGggdjQuMiBhbmQgdjQuMyAKPiA+ID4+PmVudW1lcmF0ZSB0aGUgZGV2 aWNlIHRoZSBzYW1lIHdheSwgYW5kIHRoZSBkcml2ZXIgc2VlbXMgdG8gY2xhaW0gaXQgCj4gPiA+ Pj50aGUgc2FtZSB3YXk6IAo+ID4gPj4+IAo+ID4gPj4+wqDCoCBwY2kgMDAwMDowZDowMC4wOiBb MTBiNTo5MDMwXSB0eXBlIDAwIGNsYXNzIDB4MDc4MDAwIAo+ID4gPj4+wqDCoCBwY2kgMDAwMDow ZDowMC4wOiByZWcgMHgxNDogW2lvwqAgMHgyMTAwLTB4MjE3Zl0gCj4gPiA+Pj7CoMKgIHBjaSAw MDAwOjBkOjAwLjA6IHJlZyAweDE4OiBbaW/CoCAweDIzODAtMHgyMzlmXSAKPiA+ID4+PsKgwqAg cGNpIDAwMDA6MGQ6MDAuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCAKPiA+ID4+PsKg wqAgcGNpIDAwMDA6MGQ6MDEuMDogWzEwYjU6OTAzMF0gdHlwZSAwMCBjbGFzcyAweDA3ODAwMCAK PiA+ID4+PsKgwqAgcGNpIDAwMDA6MGQ6MDEuMDogcmVnIDB4MTQ6IFtpb8KgIDB4MjE4MC0weDIx ZmZdIAo+ID4gPj4+wqDCoCBwY2kgMDAwMDowZDowMS4wOiByZWcgMHgxODogW2lvwqAgMHgyM2Ew LTB4MjNiZl0gCj4gPiA+Pj7CoMKgIHBjaSAwMDAwOjBkOjAxLjA6IFBNRSMgc3VwcG9ydGVkIGZy b20gRDAgRDNob3QgCj4gPiA+Pj7CoMKgIHBjaSAwMDAwOjBkOjAyLjA6IFsxMGI1OjkwMzBdIHR5 cGUgMDAgY2xhc3MgMHgwNzgwMDAgCj4gPiA+Pj7CoMKgIHBjaSAwMDAwOjBkOjAyLjA6IHJlZyAw eDE0OiBbaW/CoCAweDIyMDAtMHgyMjdmXSAKPiA+ID4+PsKgwqAgcGNpIDAwMDA6MGQ6MDIuMDog cmVnIDB4MTg6IFtpb8KgIDB4MjI4MC0weDIyZmZdIAo+ID4gPj4+wqDCoCBwY2kgMDAwMDowZDow Mi4wOiByZWcgMHgxYzogW2lvwqAgMHgyMzAwLTB4MjM3Zl0gCj4gPiA+Pj7CoMKgIHBjaSAwMDAw OjBkOjAyLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgCj4gPiA+Pj4gCj4gPiA+Pj7C oMKgIHNqYTEwMDBfcGx4X3BjaSAwMDAwOjBkOjAyLjA6IERldGVjdGVkICJFY2x1cyBDQU4tMjAw LVBDSSIgCj4gPiA+Pj5jYXJkIGF0IHNsb3QgIzIgCj4gPiA+Pj7CoMKgIHNqYTEwMDBfcGx4X3Bj aSAwMDAwOjBkOjAyLjA6IENoYW5uZWwgIzEgYXQgCj4gPiA+Pj4weDAwMDAwMDAwMDAwMTIyODAs IGlycSAyMiByZWdpc3RlcmVkIGFzIGNhbjAgCj4gPiA+Pj7CoMKgIHNqYTEwMDBfcGx4X3BjaSAw MDAwOjBkOjAyLjA6IENoYW5uZWwgIzIgYXQgCj4gPiA+Pj4weDAwMDAwMDAwMDAwMTIzMDAsIGly cSAyMiByZWdpc3RlcmVkIGFzIGNhbjEgCj4gPiA+Pj7CoMKgIHNqYTEwMDBfcGx4X3BjaSAwMDAw OjBkOjAyLjAgY2FuMDogc2V0dGluZyBCVFIwPTB4MDMgQlRSMT0weDM3IAo+ID4gPj4+IAo+ID4g Pj4+T25lIG9wdGlvbiBpcyBhbHdheXMgdG8gYmlzZWN0IGJldHdlZW4gdjQuMiBhbmQgdjQuMyB0 byBzZWUgd2hpY2ggCj4gPiA+Pj5jb21taXQgbWFkZSBpdCBzdG9wIHdvcmtpbmcuwqAgU2VlIGh0 dHBzOi8vZ2l0LXNjbS5jb20vZG9jcy9naXQtYmlzZWN0IAo+ID4gPj5KaWFuZywg0J7Qu9C10LMg YmlzZWN0ZWQgdGhpcyB0byA5OTFkZTJlNTkwOTAgKCJQQ0ksIHg4NjogSW1wbGVtZW50IAo+ID4g Pj5wY2liaW9zX2FsbG9jX2lycSgpIGFuZCBwY2liaW9zX2ZyZWVfaXJxKCkiKS4gCj4gPiA+PiAK PiA+ID4+0J7Qu9C10LMsIHBsZWFzZSBkb3VibGUtY2hlY2sgYW5kIGNvbmZpcm0gdGhhdCA4OTBl NDg0NzU4N2Ygd29ya3MgYW5kIAo+ID4gPj45OTFkZTJlNTkwOTAgZmFpbHMuIAo+ID4gPj4gCj4g PiA+PlRoZW4gcGxlYXNlIGFkZCBzb21lIHByaW50a3MgaW4gdGhlIHBjaWJpb3NfZW5hYmxlX2Rl dmljZSgpIGFuZCAKPiA+ID4+cGNpYmlvc19hbGxvY19pcnEoKSBwYXRocyBhbmQgaW4geW91ciBk cml2ZXIgdG8gc2VlIGV4YWN0bHkgd2hhdCBjaGFuZ2VkIAo+ID4gPj5iZXR3ZWVuIDg5MGU0ODQ3 NTg3ZiBhbmQgOTkxZGUyZTU5MDkwIAo+ID4gPj4gCj4gPiA+PkJqb3JuIAo+ID4gPj4gCj4gPiA+ Pj4+MjMuMDEuMjAxNiAxNzo1NCwgQmpvcm4gSGVsZ2FhcyDQv9C40YjQtdGCOiAKPiA+ID4+Pj4+ WytjYyBsaW51eC1rZXJuZWxdIAo+ID4gPj4+Pj4gCj4gPiA+Pj4+PkhpINCe0LvQtdCzLCAKPiA+ ID4+Pj4+IAo+ID4gPj4+Pj5PbiBTYXQsIEphbiAyMywgMjAxNiBhdCAxOjA4IEFNLCDQntC70LXQ syDQnNC+0YDQvtC3IAo+ID4gPj4+Pj48b2xlZy5tb3JvekBtY2Mudm5paWVtLnJ1PiB3cm90ZTog Cj4gPiA+Pj4+Pj5IZWxsby4gSSd2ZSBnb3QgYSBkZXZpY2UgZHJpdmVyIGZvciBNSUwtMTU1M2Ig Y2FyZCAKPiA+ID4+Pj4+PmNhbGxlZCBUQTEtUENJLCB3aGljaCAKPiA+ID4+Pj4+PmNvdWxkIGJl IGZvdW5kIGF0IAo+ID4gPj4+Pj4+aHR0cHM6Ly9naXRodWIuY29tL3Ftb3IvZWxjdXMtMTU1My1k cml2ZXItbGludXggCj4gPiA+Pj4+Pj5DYXJkIGlzIHVzaW5nIFBMWF9QQ0k5MDMwIFBDSSBjb250 cm9sbGVyLiAKPiA+ID4+Pj4+PlRvZGF5IGkndmUgZm91bmQgdGhhdCB0aGlzIGRyaXZlciBjb21w aWxlcywgaW5zdGFsbGVzLCAKPiA+ID4+Pj4+PmJ1dCBpcyBub3Qgd29ya2luZyBhcyAKPiA+ID4+ Pj4+Pml0IHNob3VsZC4gCj4gPiA+Pj4+Pj5Mb29rcyBsaWtlIGl0IG5vdCByZWNlaXZlcyBhbnkg aW50ZXJydXB0cyBmcm9tIFBDSS4gSSd2ZSAKPiA+ID4+Pj4+PnRlc3QgaXQgYWdhaW4gd2l0aCAK PiA+ID4+Pj4+Pmtlcm5lbCAKPiA+ID4+Pj4+PjQuMiBhbmQgaXQgd29ya3Mgb2theS4gV2hhdCBj aGFuZ2VzIHdhcyBtYWRlIGluIFBDSSAKPiA+ID4+Pj4+PnN1YnN5c3RlbSBmcm9tIDQuMiB0byAK PiA+ID4+Pj4+PjQuMyAKPiA+ID4+Pj4+PndoaWNoIGNvdWxkIGhhdmUgaW1wYWN0IHRoaXMgZHJp dmVyIHdvcmsuIAo+ID4gPj4+Pj5UaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGlzIHByb2JsZW0g cmVwb3J0LsKgIFRoZXJlIHdlcmUgbWFueSBQQ0kgCj4gPiA+Pj4+PmNoYW5nZXMgYmV0d2VlbiB2 NC4yIGFuZCB2NC4zLCBhbmQgd2l0aG91dCBtb3JlIGluZm9ybWF0aW9uLCBJIGNhbid0IAo+ID4g Pj4+Pj5ndWVzcyB3aGF0IG1pZ2h0IGJlIGNhdXNpbmcgdGhpcyBwcm9ibGVtLiAKPiA+ID4+Pj4+ IAo+ID4gPj4+Pj5JIG9wZW5lZCBhIGJ1ZyByZXBvcnQgYXQgCj4gPiA+Pj4+Pmh0dHBzOi8vYnVn emlsbGEua2VybmVsLm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTExMjExIAo+ID4gPj4+Pj4gCj4gPiA+ Pj4+PlBsZWFzZSBhdHRhY2ggY29tcGxldGUgZG1lc2cgbG9ncyBmb3IgYm90aCB2NC4yIGFuZCB2 NC4zIHRvIHRoYXQgYnVnIAo+ID4gPj4+Pj5yZXBvcnQuwqAgQWxzbywgcGxlYXNlIGF0dGFjaCB0 aGUgY29tcGxldGUgImxzcGNpIC12diIgb3V0cHV0IChhcyAKPiA+ID4+Pj4+cm9vdCkuIAo+ID4g Pj4+Pj4gCj4gPiA+Pj4+PlRoYW5rcyEgCj4gPiA+Pj4+PiAKPiA+ID4+Pj4+Qmpvcm4gCj4gPiA+ Pj4+LS0gCj4gPiA+Pj4+VG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxp bmUgInVuc3Vic2NyaWJlIAo+ID4gPj4+PmxpbnV4LXBjaSIgaW4gCj4gPiA+Pj4+dGhlIGJvZHkg b2YgYSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2VyLmtlcm5lbC5vcmcgCj4gPiA+Pj4+TW9yZSBt YWpvcmRvbW8gaW5mbyBhdCBodHRwOi8vdmdlci5rZXJuZWwub3JnL21ham9yZG9tby1pbmZvLmh0 bWwgCj4gPiA+Pj4tLSAKPiA+ID4+PlRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBsaXN0OiBzZW5k IHRoZSBsaW5lICJ1bnN1YnNjcmliZSBsaW51eC1wY2kiIGluIAo+ID4gPj4+dGhlIGJvZHkgb2Yg YSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2VyLmtlcm5lbC5vcmcgCj4gPiA+Pj5Nb3JlIG1ham9y ZG9tbyBpbmZvIGF0IGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbCAK PiA+ID4gCj4gPiAKPiA+IC0tIAo+ID4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNl bmQgdGhlIGxpbmUgInVuc3Vic2NyaWJlIGxpbnV4LXBjaSIgaW4gCj4gPiB0aGUgYm9keSBvZiBh IG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9yZyAKPiA+IE1vcmUgbWFqb3Jkb21v IGluZm8gYXTCoCBodHRwOi8vdmdlci5rZXJuZWwub3JnL21ham9yZG9tby1pbmZvLmh0bWwgCg== ^ permalink raw reply [flat|nested] 19+ messages in thread
* PCI device driver broken between 4.2 and 4.3 @ 2016-01-23 7:08 Олег Мороз 2016-01-23 14:54 ` Bjorn Helgaas 2016-02-05 17:40 ` Bjorn Helgaas 0 siblings, 2 replies; 19+ messages in thread From: Олег Мороз @ 2016-01-23 7:08 UTC (permalink / raw) To: linux-pci; +Cc: oleg.moroz Hello. I've got a device driver for MIL-1553b card called TA1-PCI, which could be found at https://github.com/qmor/elcus-1553-driver-linux Card is using PLX_PCI9030 PCI controller. Today i've found that this driver compiles, installes, but is not working as it should. Looks like it not receives any interrupts from PCI. I've test it again with kernel 4.2 and it works okay. What changes was made in PCI subsystem from 4.2 to 4.3 which could have impact this driver work. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: PCI device driver broken between 4.2 and 4.3 2016-01-23 7:08 Олег Мороз @ 2016-01-23 14:54 ` Bjorn Helgaas 2016-01-24 13:50 ` Олег Мороз 2016-02-05 17:40 ` Bjorn Helgaas 1 sibling, 1 reply; 19+ messages in thread From: Bjorn Helgaas @ 2016-01-23 14:54 UTC (permalink / raw) To: Олег Мороз Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org [+cc linux-kernel] Hi Олег, On Sat, Jan 23, 2016 at 1:08 AM, Олег Мороз <oleg.moroz@mcc.vniiem.ru> wrote: > Hello. I've got a device driver for MIL-1553b card called TA1-PCI, which > could be found at > https://github.com/qmor/elcus-1553-driver-linux > Card is using PLX_PCI9030 PCI controller. > Today i've found that this driver compiles, installes, but is not working as > it should. > Looks like it not receives any interrupts from PCI. I've test it again with > kernel > 4.2 and it works okay. What changes was made in PCI subsystem from 4.2 to > 4.3 > which could have impact this driver work. Thank you very much for this problem report. There were many PCI changes between v4.2 and v4.3, and without more information, I can't guess what might be causing this problem. I opened a bug report at https://bugzilla.kernel.org/show_bug.cgi?id=111211 Please attach complete dmesg logs for both v4.2 and v4.3 to that bug report. Also, please attach the complete "lspci -vv" output (as root). Thanks! Bjorn ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: PCI device driver broken between 4.2 and 4.3 2016-01-23 14:54 ` Bjorn Helgaas @ 2016-01-24 13:50 ` Олег Мороз 2016-01-25 21:52 ` Bjorn Helgaas 0 siblings, 1 reply; 19+ messages in thread From: Олег Мороз @ 2016-01-24 13:50 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Okay. I've sent logs (dmesg and lspci) from both 4.2 and 4.3 to bugzilla 23.01.2016 17:54, Bjorn Helgaas пишет: > [+cc linux-kernel] > > Hi Олег, > > On Sat, Jan 23, 2016 at 1:08 AM, Олег Мороз <oleg.moroz@mcc.vniiem.ru> wrote: >> Hello. I've got a device driver for MIL-1553b card called TA1-PCI, which >> could be found at >> https://github.com/qmor/elcus-1553-driver-linux >> Card is using PLX_PCI9030 PCI controller. >> Today i've found that this driver compiles, installes, but is not working as >> it should. >> Looks like it not receives any interrupts from PCI. I've test it again with >> kernel >> 4.2 and it works okay. What changes was made in PCI subsystem from 4.2 to >> 4.3 >> which could have impact this driver work. > Thank you very much for this problem report. There were many PCI > changes between v4.2 and v4.3, and without more information, I can't > guess what might be causing this problem. > > I opened a bug report at https://bugzilla.kernel.org/show_bug.cgi?id=111211 > > Please attach complete dmesg logs for both v4.2 and v4.3 to that bug > report. Also, please attach the complete "lspci -vv" output (as > root). > > Thanks! > > Bjorn ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: PCI device driver broken between 4.2 and 4.3 2016-01-24 13:50 ` Олег Мороз @ 2016-01-25 21:52 ` Bjorn Helgaas 2016-01-26 15:32 ` Bjorn Helgaas 0 siblings, 1 reply; 19+ messages in thread From: Bjorn Helgaas @ 2016-01-25 21:52 UTC (permalink / raw) To: Олег Мороз Cc: Bjorn Helgaas, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Hi Олег, On Sun, Jan 24, 2016 at 04:50:08PM +0300, Олег Мороз wrote: > Okay. I've sent logs (dmesg and lspci) from both 4.2 and 4.3 to bugzilla I don't see anything wrong in either log. Both v4.2 and v4.3 enumerate the device the same way, and the driver seems to claim it the same way: pci 0000:0d:00.0: [10b5:9030] type 00 class 0x078000 pci 0000:0d:00.0: reg 0x14: [io 0x2100-0x217f] pci 0000:0d:00.0: reg 0x18: [io 0x2380-0x239f] pci 0000:0d:00.0: PME# supported from D0 D3hot pci 0000:0d:01.0: [10b5:9030] type 00 class 0x078000 pci 0000:0d:01.0: reg 0x14: [io 0x2180-0x21ff] pci 0000:0d:01.0: reg 0x18: [io 0x23a0-0x23bf] pci 0000:0d:01.0: PME# supported from D0 D3hot pci 0000:0d:02.0: [10b5:9030] type 00 class 0x078000 pci 0000:0d:02.0: reg 0x14: [io 0x2200-0x227f] pci 0000:0d:02.0: reg 0x18: [io 0x2280-0x22ff] pci 0000:0d:02.0: reg 0x1c: [io 0x2300-0x237f] pci 0000:0d:02.0: PME# supported from D0 D3hot sja1000_plx_pci 0000:0d:02.0: Detected "Eclus CAN-200-PCI" card at slot #2 sja1000_plx_pci 0000:0d:02.0: Channel #1 at 0x0000000000012280, irq 22 registered as can0 sja1000_plx_pci 0000:0d:02.0: Channel #2 at 0x0000000000012300, irq 22 registered as can1 sja1000_plx_pci 0000:0d:02.0 can0: setting BTR0=0x03 BTR1=0x37 One option is always to bisect between v4.2 and v4.3 to see which commit made it stop working. See https://git-scm.com/docs/git-bisect > 23.01.2016 17:54, Bjorn Helgaas пишет: > >[+cc linux-kernel] > > > >Hi Олег, > > > >On Sat, Jan 23, 2016 at 1:08 AM, Олег Мороз <oleg.moroz@mcc.vniiem.ru> wrote: > >>Hello. I've got a device driver for MIL-1553b card called TA1-PCI, which > >>could be found at > >>https://github.com/qmor/elcus-1553-driver-linux > >>Card is using PLX_PCI9030 PCI controller. > >>Today i've found that this driver compiles, installes, but is not working as > >>it should. > >>Looks like it not receives any interrupts from PCI. I've test it again with > >>kernel > >>4.2 and it works okay. What changes was made in PCI subsystem from 4.2 to > >>4.3 > >>which could have impact this driver work. > >Thank you very much for this problem report. There were many PCI > >changes between v4.2 and v4.3, and without more information, I can't > >guess what might be causing this problem. > > > >I opened a bug report at https://bugzilla.kernel.org/show_bug.cgi?id=111211 > > > >Please attach complete dmesg logs for both v4.2 and v4.3 to that bug > >report. Also, please attach the complete "lspci -vv" output (as > >root). > > > >Thanks! > > > >Bjorn > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: PCI device driver broken between 4.2 and 4.3 2016-01-25 21:52 ` Bjorn Helgaas @ 2016-01-26 15:32 ` Bjorn Helgaas 2016-01-26 19:05 ` Олег Мороз 0 siblings, 1 reply; 19+ messages in thread From: Bjorn Helgaas @ 2016-01-26 15:32 UTC (permalink / raw) To: Олег Мороз Cc: Bjorn Helgaas, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Jiang Liu [+cc Jiang] On Mon, Jan 25, 2016 at 03:52:51PM -0600, Bjorn Helgaas wrote: > Hi Олег, > > On Sun, Jan 24, 2016 at 04:50:08PM +0300, Олег Мороз wrote: > > Okay. I've sent logs (dmesg and lspci) from both 4.2 and 4.3 to bugzilla > > I don't see anything wrong in either log. Both v4.2 and v4.3 > enumerate the device the same way, and the driver seems to claim it > the same way: > > pci 0000:0d:00.0: [10b5:9030] type 00 class 0x078000 > pci 0000:0d:00.0: reg 0x14: [io 0x2100-0x217f] > pci 0000:0d:00.0: reg 0x18: [io 0x2380-0x239f] > pci 0000:0d:00.0: PME# supported from D0 D3hot > pci 0000:0d:01.0: [10b5:9030] type 00 class 0x078000 > pci 0000:0d:01.0: reg 0x14: [io 0x2180-0x21ff] > pci 0000:0d:01.0: reg 0x18: [io 0x23a0-0x23bf] > pci 0000:0d:01.0: PME# supported from D0 D3hot > pci 0000:0d:02.0: [10b5:9030] type 00 class 0x078000 > pci 0000:0d:02.0: reg 0x14: [io 0x2200-0x227f] > pci 0000:0d:02.0: reg 0x18: [io 0x2280-0x22ff] > pci 0000:0d:02.0: reg 0x1c: [io 0x2300-0x237f] > pci 0000:0d:02.0: PME# supported from D0 D3hot > > sja1000_plx_pci 0000:0d:02.0: Detected "Eclus CAN-200-PCI" card at slot #2 > sja1000_plx_pci 0000:0d:02.0: Channel #1 at 0x0000000000012280, irq 22 registered as can0 > sja1000_plx_pci 0000:0d:02.0: Channel #2 at 0x0000000000012300, irq 22 registered as can1 > sja1000_plx_pci 0000:0d:02.0 can0: setting BTR0=0x03 BTR1=0x37 > > One option is always to bisect between v4.2 and v4.3 to see which > commit made it stop working. See https://git-scm.com/docs/git-bisect Jiang, Олег bisected this to 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()"). Олег, please double-check and confirm that 890e4847587f works and 991de2e59090 fails. Then please add some printks in the pcibios_enable_device() and pcibios_alloc_irq() paths and in your driver to see exactly what changed between 890e4847587f and 991de2e59090 Bjorn > > 23.01.2016 17:54, Bjorn Helgaas пишет: > > >[+cc linux-kernel] > > > > > >Hi Олег, > > > > > >On Sat, Jan 23, 2016 at 1:08 AM, Олег Мороз <oleg.moroz@mcc.vniiem.ru> wrote: > > >>Hello. I've got a device driver for MIL-1553b card called TA1-PCI, which > > >>could be found at > > >>https://github.com/qmor/elcus-1553-driver-linux > > >>Card is using PLX_PCI9030 PCI controller. > > >>Today i've found that this driver compiles, installes, but is not working as > > >>it should. > > >>Looks like it not receives any interrupts from PCI. I've test it again with > > >>kernel > > >>4.2 and it works okay. What changes was made in PCI subsystem from 4.2 to > > >>4.3 > > >>which could have impact this driver work. > > >Thank you very much for this problem report. There were many PCI > > >changes between v4.2 and v4.3, and without more information, I can't > > >guess what might be causing this problem. > > > > > >I opened a bug report at https://bugzilla.kernel.org/show_bug.cgi?id=111211 > > > > > >Please attach complete dmesg logs for both v4.2 and v4.3 to that bug > > >report. Also, please attach the complete "lspci -vv" output (as > > >root). > > > > > >Thanks! > > > > > >Bjorn > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: PCI device driver broken between 4.2 and 4.3 2016-01-26 15:32 ` Bjorn Helgaas @ 2016-01-26 19:05 ` Олег Мороз 2016-01-27 9:38 ` Мороз Олег 0 siblings, 1 reply; 19+ messages in thread From: Олег Мороз @ 2016-01-26 19:05 UTC (permalink / raw) To: Bjorn Helgaas Cc: Bjorn Helgaas, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Jiang Liu I confirmed it works in 890e4847587f and do not works in 991de2e59090 26.01.2016 18:32, Bjorn Helgaas пишет: > [+cc Jiang] > > On Mon, Jan 25, 2016 at 03:52:51PM -0600, Bjorn Helgaas wrote: >> Hi Олег, >> >> On Sun, Jan 24, 2016 at 04:50:08PM +0300, Олег Мороз wrote: >>> Okay. I've sent logs (dmesg and lspci) from both 4.2 and 4.3 to bugzilla >> I don't see anything wrong in either log. Both v4.2 and v4.3 >> enumerate the device the same way, and the driver seems to claim it >> the same way: >> >> pci 0000:0d:00.0: [10b5:9030] type 00 class 0x078000 >> pci 0000:0d:00.0: reg 0x14: [io 0x2100-0x217f] >> pci 0000:0d:00.0: reg 0x18: [io 0x2380-0x239f] >> pci 0000:0d:00.0: PME# supported from D0 D3hot >> pci 0000:0d:01.0: [10b5:9030] type 00 class 0x078000 >> pci 0000:0d:01.0: reg 0x14: [io 0x2180-0x21ff] >> pci 0000:0d:01.0: reg 0x18: [io 0x23a0-0x23bf] >> pci 0000:0d:01.0: PME# supported from D0 D3hot >> pci 0000:0d:02.0: [10b5:9030] type 00 class 0x078000 >> pci 0000:0d:02.0: reg 0x14: [io 0x2200-0x227f] >> pci 0000:0d:02.0: reg 0x18: [io 0x2280-0x22ff] >> pci 0000:0d:02.0: reg 0x1c: [io 0x2300-0x237f] >> pci 0000:0d:02.0: PME# supported from D0 D3hot >> >> sja1000_plx_pci 0000:0d:02.0: Detected "Eclus CAN-200-PCI" card at slot #2 >> sja1000_plx_pci 0000:0d:02.0: Channel #1 at 0x0000000000012280, irq 22 registered as can0 >> sja1000_plx_pci 0000:0d:02.0: Channel #2 at 0x0000000000012300, irq 22 registered as can1 >> sja1000_plx_pci 0000:0d:02.0 can0: setting BTR0=0x03 BTR1=0x37 >> >> One option is always to bisect between v4.2 and v4.3 to see which >> commit made it stop working. See https://git-scm.com/docs/git-bisect > Jiang, Олег bisected this to 991de2e59090 ("PCI, x86: Implement > pcibios_alloc_irq() and pcibios_free_irq()"). > > Олег, please double-check and confirm that 890e4847587f works and > 991de2e59090 fails. > > Then please add some printks in the pcibios_enable_device() and > pcibios_alloc_irq() paths and in your driver to see exactly what changed > between 890e4847587f and 991de2e59090 > > Bjorn > >>> 23.01.2016 17:54, Bjorn Helgaas пишет: >>>> [+cc linux-kernel] >>>> >>>> Hi Олег, >>>> >>>> On Sat, Jan 23, 2016 at 1:08 AM, Олег Мороз <oleg.moroz@mcc.vniiem.ru> wrote: >>>>> Hello. I've got a device driver for MIL-1553b card called TA1-PCI, which >>>>> could be found at >>>>> https://github.com/qmor/elcus-1553-driver-linux >>>>> Card is using PLX_PCI9030 PCI controller. >>>>> Today i've found that this driver compiles, installes, but is not working as >>>>> it should. >>>>> Looks like it not receives any interrupts from PCI. I've test it again with >>>>> kernel >>>>> 4.2 and it works okay. What changes was made in PCI subsystem from 4.2 to >>>>> 4.3 >>>>> which could have impact this driver work. >>>> Thank you very much for this problem report. There were many PCI >>>> changes between v4.2 and v4.3, and without more information, I can't >>>> guess what might be causing this problem. >>>> >>>> I opened a bug report at https://bugzilla.kernel.org/show_bug.cgi?id=111211 >>>> >>>> Please attach complete dmesg logs for both v4.2 and v4.3 to that bug >>>> report. Also, please attach the complete "lspci -vv" output (as >>>> root). >>>> >>>> Thanks! >>>> >>>> Bjorn >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-pci" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: PCI device driver broken between 4.2 and 4.3 2016-01-26 19:05 ` Олег Мороз @ 2016-01-27 9:38 ` Мороз Олег 2016-01-27 13:22 ` Bjorn Helgaas 0 siblings, 1 reply; 19+ messages in thread From: Мороз Олег @ 2016-01-27 9:38 UTC (permalink / raw) To: Bjorn Helgaas Cc: Bjorn Helgaas, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Jiang Liu Also, my drive has no pcibios_enable_device() pcibios_alloc_irq() calls. 26.01.2016 22:05, Олег Мороз пишет: > I confirmed it works in > > 890e4847587f > > and do not works in > > 991de2e59090 > > 26.01.2016 18:32, Bjorn Helgaas пишет: >> [+cc Jiang] >> >> On Mon, Jan 25, 2016 at 03:52:51PM -0600, Bjorn Helgaas wrote: >>> Hi Олег, >>> >>> On Sun, Jan 24, 2016 at 04:50:08PM +0300, Олег Мороз wrote: >>>> Okay. I've sent logs (dmesg and lspci) from both 4.2 and 4.3 to >>>> bugzilla >>> I don't see anything wrong in either log. Both v4.2 and v4.3 >>> enumerate the device the same way, and the driver seems to claim it >>> the same way: >>> >>> pci 0000:0d:00.0: [10b5:9030] type 00 class 0x078000 >>> pci 0000:0d:00.0: reg 0x14: [io 0x2100-0x217f] >>> pci 0000:0d:00.0: reg 0x18: [io 0x2380-0x239f] >>> pci 0000:0d:00.0: PME# supported from D0 D3hot >>> pci 0000:0d:01.0: [10b5:9030] type 00 class 0x078000 >>> pci 0000:0d:01.0: reg 0x14: [io 0x2180-0x21ff] >>> pci 0000:0d:01.0: reg 0x18: [io 0x23a0-0x23bf] >>> pci 0000:0d:01.0: PME# supported from D0 D3hot >>> pci 0000:0d:02.0: [10b5:9030] type 00 class 0x078000 >>> pci 0000:0d:02.0: reg 0x14: [io 0x2200-0x227f] >>> pci 0000:0d:02.0: reg 0x18: [io 0x2280-0x22ff] >>> pci 0000:0d:02.0: reg 0x1c: [io 0x2300-0x237f] >>> pci 0000:0d:02.0: PME# supported from D0 D3hot >>> >>> sja1000_plx_pci 0000:0d:02.0: Detected "Eclus CAN-200-PCI" card >>> at slot #2 >>> sja1000_plx_pci 0000:0d:02.0: Channel #1 at 0x0000000000012280, >>> irq 22 registered as can0 >>> sja1000_plx_pci 0000:0d:02.0: Channel #2 at 0x0000000000012300, >>> irq 22 registered as can1 >>> sja1000_plx_pci 0000:0d:02.0 can0: setting BTR0=0x03 BTR1=0x37 >>> >>> One option is always to bisect between v4.2 and v4.3 to see which >>> commit made it stop working. See https://git-scm.com/docs/git-bisect >> Jiang, Олег bisected this to 991de2e59090 ("PCI, x86: Implement >> pcibios_alloc_irq() and pcibios_free_irq()"). >> >> Олег, please double-check and confirm that 890e4847587f works and >> 991de2e59090 fails. >> >> Then please add some printks in the pcibios_enable_device() and >> pcibios_alloc_irq() paths and in your driver to see exactly what changed >> between 890e4847587f and 991de2e59090 >> >> Bjorn >> >>>> 23.01.2016 17:54, Bjorn Helgaas пишет: >>>>> [+cc linux-kernel] >>>>> >>>>> Hi Олег, >>>>> >>>>> On Sat, Jan 23, 2016 at 1:08 AM, Олег Мороз >>>>> <oleg.moroz@mcc.vniiem.ru> wrote: >>>>>> Hello. I've got a device driver for MIL-1553b card called >>>>>> TA1-PCI, which >>>>>> could be found at >>>>>> https://github.com/qmor/elcus-1553-driver-linux >>>>>> Card is using PLX_PCI9030 PCI controller. >>>>>> Today i've found that this driver compiles, installes, but is not >>>>>> working as >>>>>> it should. >>>>>> Looks like it not receives any interrupts from PCI. I've test it >>>>>> again with >>>>>> kernel >>>>>> 4.2 and it works okay. What changes was made in PCI subsystem >>>>>> from 4.2 to >>>>>> 4.3 >>>>>> which could have impact this driver work. >>>>> Thank you very much for this problem report. There were many PCI >>>>> changes between v4.2 and v4.3, and without more information, I can't >>>>> guess what might be causing this problem. >>>>> >>>>> I opened a bug report at >>>>> https://bugzilla.kernel.org/show_bug.cgi?id=111211 >>>>> >>>>> Please attach complete dmesg logs for both v4.2 and v4.3 to that bug >>>>> report. Also, please attach the complete "lspci -vv" output (as >>>>> root). >>>>> >>>>> Thanks! >>>>> >>>>> Bjorn >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe >>>> linux-pci" in >>>> the body of a message to majordomo@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: PCI device driver broken between 4.2 and 4.3 2016-01-27 9:38 ` Мороз Олег @ 2016-01-27 13:22 ` Bjorn Helgaas 0 siblings, 0 replies; 19+ messages in thread From: Bjorn Helgaas @ 2016-01-27 13:22 UTC (permalink / raw) To: Мороз Олег Cc: Bjorn Helgaas, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Jiang Liu On Wed, Jan 27, 2016 at 12:38:06PM +0300, Мороз Олег wrote: > Also, my drive has no > > pcibios_enable_device() > pcibios_alloc_irq() > > calls. Those are internal interfaces used by the PCI core. Drivers shouldn't call them directly. Drivers normally call pci_enable_device(), and those internal interfaces are used in that path. > 26.01.2016 22:05, Олег Мороз пишет: > >I confirmed it works in > > > >890e4847587f > > > >and do not works in > > > >991de2e59090 > > > >26.01.2016 18:32, Bjorn Helgaas пишет: > >>[+cc Jiang] > >> > >>On Mon, Jan 25, 2016 at 03:52:51PM -0600, Bjorn Helgaas wrote: > >>>Hi Олег, > >>> > >>>On Sun, Jan 24, 2016 at 04:50:08PM +0300, Олег Мороз wrote: > >>>>Okay. I've sent logs (dmesg and lspci) from both 4.2 and 4.3 > >>>>to bugzilla > >>>I don't see anything wrong in either log. Both v4.2 and v4.3 > >>>enumerate the device the same way, and the driver seems to claim it > >>>the same way: > >>> > >>> pci 0000:0d:00.0: [10b5:9030] type 00 class 0x078000 > >>> pci 0000:0d:00.0: reg 0x14: [io 0x2100-0x217f] > >>> pci 0000:0d:00.0: reg 0x18: [io 0x2380-0x239f] > >>> pci 0000:0d:00.0: PME# supported from D0 D3hot > >>> pci 0000:0d:01.0: [10b5:9030] type 00 class 0x078000 > >>> pci 0000:0d:01.0: reg 0x14: [io 0x2180-0x21ff] > >>> pci 0000:0d:01.0: reg 0x18: [io 0x23a0-0x23bf] > >>> pci 0000:0d:01.0: PME# supported from D0 D3hot > >>> pci 0000:0d:02.0: [10b5:9030] type 00 class 0x078000 > >>> pci 0000:0d:02.0: reg 0x14: [io 0x2200-0x227f] > >>> pci 0000:0d:02.0: reg 0x18: [io 0x2280-0x22ff] > >>> pci 0000:0d:02.0: reg 0x1c: [io 0x2300-0x237f] > >>> pci 0000:0d:02.0: PME# supported from D0 D3hot > >>> > >>> sja1000_plx_pci 0000:0d:02.0: Detected "Eclus CAN-200-PCI" > >>>card at slot #2 > >>> sja1000_plx_pci 0000:0d:02.0: Channel #1 at > >>>0x0000000000012280, irq 22 registered as can0 > >>> sja1000_plx_pci 0000:0d:02.0: Channel #2 at > >>>0x0000000000012300, irq 22 registered as can1 > >>> sja1000_plx_pci 0000:0d:02.0 can0: setting BTR0=0x03 BTR1=0x37 > >>> > >>>One option is always to bisect between v4.2 and v4.3 to see which > >>>commit made it stop working. See https://git-scm.com/docs/git-bisect > >>Jiang, Олег bisected this to 991de2e59090 ("PCI, x86: Implement > >>pcibios_alloc_irq() and pcibios_free_irq()"). > >> > >>Олег, please double-check and confirm that 890e4847587f works and > >>991de2e59090 fails. > >> > >>Then please add some printks in the pcibios_enable_device() and > >>pcibios_alloc_irq() paths and in your driver to see exactly what changed > >>between 890e4847587f and 991de2e59090 > >> > >>Bjorn > >> > >>>>23.01.2016 17:54, Bjorn Helgaas пишет: > >>>>>[+cc linux-kernel] > >>>>> > >>>>>Hi Олег, > >>>>> > >>>>>On Sat, Jan 23, 2016 at 1:08 AM, Олег Мороз > >>>>><oleg.moroz@mcc.vniiem.ru> wrote: > >>>>>>Hello. I've got a device driver for MIL-1553b card > >>>>>>called TA1-PCI, which > >>>>>>could be found at > >>>>>>https://github.com/qmor/elcus-1553-driver-linux > >>>>>>Card is using PLX_PCI9030 PCI controller. > >>>>>>Today i've found that this driver compiles, installes, > >>>>>>but is not working as > >>>>>>it should. > >>>>>>Looks like it not receives any interrupts from PCI. I've > >>>>>>test it again with > >>>>>>kernel > >>>>>>4.2 and it works okay. What changes was made in PCI > >>>>>>subsystem from 4.2 to > >>>>>>4.3 > >>>>>>which could have impact this driver work. > >>>>>Thank you very much for this problem report. There were many PCI > >>>>>changes between v4.2 and v4.3, and without more information, I can't > >>>>>guess what might be causing this problem. > >>>>> > >>>>>I opened a bug report at > >>>>>https://bugzilla.kernel.org/show_bug.cgi?id=111211 > >>>>> > >>>>>Please attach complete dmesg logs for both v4.2 and v4.3 to that bug > >>>>>report. Also, please attach the complete "lspci -vv" output (as > >>>>>root). > >>>>> > >>>>>Thanks! > >>>>> > >>>>>Bjorn > >>>>-- > >>>>To unsubscribe from this list: send the line "unsubscribe > >>>>linux-pci" in > >>>>the body of a message to majordomo@vger.kernel.org > >>>>More majordomo info at http://vger.kernel.org/majordomo-info.html > >>>-- > >>>To unsubscribe from this list: send the line "unsubscribe linux-pci" in > >>>the body of a message to majordomo@vger.kernel.org > >>>More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: PCI device driver broken between 4.2 and 4.3 2016-01-23 7:08 Олег Мороз 2016-01-23 14:54 ` Bjorn Helgaas @ 2016-02-05 17:40 ` Bjorn Helgaas 1 sibling, 0 replies; 19+ messages in thread From: Bjorn Helgaas @ 2016-02-05 17:40 UTC (permalink / raw) To: Олег Мороз Cc: linux-pci, Jiang Liu, Yinghai Lu, Sunjin Yang, linux-kernel [+cc Jiang, Yinghai, Sunjin, linux-kernel] On Sat, Jan 23, 2016 at 10:08:50AM +0300, Олег Мороз wrote: > Hello. I've got a device driver for MIL-1553b card called TA1-PCI, > which could be found at > https://github.com/qmor/elcus-1553-driver-linux > Card is using PLX_PCI9030 PCI controller. > Today i've found that this driver compiles, installes, but is not > working as it should. > Looks like it not receives any interrupts from PCI. I've test it > again with kernel > 4.2 and it works okay. What changes was made in PCI subsystem from > 4.2 to 4.3 > which could have impact this driver work. Sunjin reported another driver, RocketRAID 272x, with the same problem. "pci=routeirq" is a workaround: https://bugzilla.kernel.org/show_bug.cgi?id=111211#c7 Олег bisected the problem with his driver to Jiang's patch, 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") and found that "pci=routeirq" was a workaround. I don't think Sunjin has bisected this, but the RocketRAID driver stopped working at the same time and the same workaround works, so we assume it is the same problem. Prior to 991de2e59090, we called pcibios_enable_irq() in the pci_enable_device() path, which recursively called pcibios_enable_irq() for upstream bridges via pci_enable_bridge(). After 991de2e59090, we call pcibios_enable_irq() from the pci_device_probe() path instead of the pci_enable_device() path. This does *not* call pcibios_enable_irq() for upstream bridges. I think this is what Yinghai meant in his response, but I didn't understand the connection. This is a pretty serious problem that should affect many devices behind bridges, so I think we need a PCI or ACPI core fix. Jiang? Bjorn ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2016-02-05 17:40 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-01-28 19:28 PCI device driver broken between 4.2 and 4.3 Мороз Олег 2016-01-29 16:31 ` Bjorn Helgaas 2016-01-30 6:15 ` Yinghai Lu 2016-02-01 5:18 ` Олег Мороз 2016-02-01 21:08 ` Bjorn Helgaas 2016-02-02 5:04 ` Олег Мороз 2016-02-02 16:13 ` Bjorn Helgaas 2016-02-02 16:17 ` Олег Мороз 2016-02-05 14:29 ` Bjorn Helgaas -- strict thread matches above, loose matches on Subject: below -- 2016-01-28 19:28 Мороз Олег 2016-01-23 7:08 Олег Мороз 2016-01-23 14:54 ` Bjorn Helgaas 2016-01-24 13:50 ` Олег Мороз 2016-01-25 21:52 ` Bjorn Helgaas 2016-01-26 15:32 ` Bjorn Helgaas 2016-01-26 19:05 ` Олег Мороз 2016-01-27 9:38 ` Мороз Олег 2016-01-27 13:22 ` Bjorn Helgaas 2016-02-05 17:40 ` Bjorn Helgaas
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).