Hi, using old MAXDATA notebook with AMD Athlon XP-M 2600+ 32-bit processor and Fedora 22 Server installed (minimum software schema option selected) I have noticed the kernel driver yenta_cardbus problem. The HW is with just one PCMCIA slot and I want to use it for the network cards (either old 3Com device or newr one TP-Link Wi-Fi with Atheros AR5416 chipset) since the built-in network adapter is broken. With the kernel 4.0.4 and then later updated to 4.0.7 the PCMCIA socket has been recognised correctly and the cards as well (with pccardctl, lspci and NetworkManager). After the kernel has been updated to 4.0.8, the both cards are not recognised at all. The pccardctl status shows nothing and the lspci doesn't list the card when it is plugged into the socket. Exactly same problem I can see with kernel 4.1.2 updated from updates-testing repo. During the startup just after the kernel list shown on the screen: Fedora (4.0.8-300.fc22.i686+PAE) 22 (Twenty Two) Fedora (4.0.7-300.fc22.i686+PAE) 22 (Twenty Two) Fedora (4.0.4-300.fc22.i686+PAE) 22 (Twenty Two) ... it is very shortly presented the text (no manual kernel selection, automatically starts the newest one from the top): [ 1.680080] yenta_cardbus 0000:00:0a.0: No cardbus resource! after that the white-blue progress bar at the bottom shows that system follows the starting steps and than everything seem to be working well... unfortunatelly with no PCMCIA interface available. In my system under the slot 0000:00:0a.0 the lspci shows the TI PCI1410 bridge to the HW PCMCIA slot. Probably it would help, when you analyze the lspci listings and particularly the differences between the scenarios with kernel 4.0.7 (working OK) and with 4.0.8 (missing PCMCIA): For the kernel 4.0.7 the lspci -Dv shows (it works with PCMCIA): 0000:00:0a.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 02) Subsystem: Uniwill Computer Corp Device 3200 Flags: bus msater, medium devsel, latency 168, IRQ 11 Memory at 50000000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=02, subordinate=05, sec-latency=176 Memory window 0: 54000000-57ffffff (prefetchable) Memory window 1: 58000000-5bffffff I/O window 0: 00001000-000010ff I/O window 1: 00001400-000014ff 16-bit legacy interface ports at 0001 Capabilites: [a0] Power Management version 1 Kernel driver in use: yenta_cardbus Kernel modules: yenta_socket For the kernel 4.0.8 the lspci -Dv shows (it doesn't work with PCMCIA, the result is same for kernel 4.1.2): 0000:00:0a.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 02) Subsystem: Uniwill Computer Corp Device 3200 Flags: medium devsel, IRQ 11 Bus: primary=00, secondary=02, subordinate=05, sec-latnecy=176 Memory window 0: 00000000-00000fff (prefetchable) Memory window 1: 00000000-00000fff I/O window 0: 00001000-000010ff I/O window 1: 00001400-000014ff 16-bit legacy interface ports at 0001 Capabilites: [a0] Power Management version 1 Kernel modules: yenta_socket In case of same additional questions, let me know, please.
*** Bug 1246181 has been marked as a duplicate of this bug. ***
This issue is going to be most easily identified by bisection. You can use some (experimental) scripts I wrote to do a bisect of commits between 4.0.7 and 4.0.8 to identify which commit actually broke the kernel. Please see https://pagure.io/fedbisect
Hi Laura, I see, the newest kernel-4.1.3-201 is published, but still with bug reported before (1244515) and not solved up to now. I think, it's definitely the quality issue to keep the published packages with no bugs and make the updates with attention to the bug reports. Actually the bug statics show that the command: dnf upgrade --exclude=kernel* will become the most popular one between the administrators. In order to avoid that I would suggest to slow down a bit with the new versioning and much more care on the faults announced by the users. Regards, Rick
*** Bug 1248473 has been marked as a duplicate of this bug. ***
i686 bugs are the lowest priority for the Fedora kernel team and require community assistance for resolution. Laura has provided a suggestion that interested community members can attempt to help narrow down the issue. Also, please refrain from opening multiple bugs for the same issue.
(In reply to Josh Boyer from comment #5) > i686 bugs are the lowest priority for the Fedora kernel team and require > community assistance for resolution. Laura has provided a suggestion that > interested community members can attempt to help narrow down the issue. > Also, please refrain from opening multiple bugs for the same issue. OK, than stop publishing the new versions until the bug is fully resolved. Again, it is a quality question. I will try to help using the script from Laura, but it's not sure, when. The HW with Fedora is used as small development server and with very difficult direct manual accesss, maintained normally over LAN (but only when network connection is on which is not with kernel 4.0.8 and higher, what irritating me a lot). The choice for Fedora has had in the background the expectation, that this server will follow closely the newest versions of software, I'm using. Now I can see, it's in principle true, but need to remember --exclude=kernel all the time.
(In reply to it_man from comment #6) > (In reply to Josh Boyer from comment #5) > > i686 bugs are the lowest priority for the Fedora kernel team and require > > community assistance for resolution. Laura has provided a suggestion that > > interested community members can attempt to help narrow down the issue. > > Also, please refrain from opening multiple bugs for the same issue. > > OK, than stop publishing the new versions until the bug is fully resolved. > Again, it is a quality question. I'm sorry, but we cannot do that. If we stopped to try and solve every bug before shipping another kernel, we would never ship a new kernel. There are over 500 open bugs. This bug, simply via numerical order, is very far towards the end of the line.
This bug is almost certainly caused by this commit in 4.0.8: commit 3d9fecf6bf upstream x86/PCI: Use host bridge _CRS info on systems with >32 bit addressing To test, try booting with "pci=nocrs" on the kernel command line
(In reply to Chuck Ebbert from comment #8) > This bug is almost certainly caused by this commit in 4.0.8: > > commit 3d9fecf6bf upstream > x86/PCI: Use host bridge _CRS info on systems with >32 bit addressing > > To test, try booting with "pci=nocrs" on the kernel command line Thanks Chuck, but unfortunately the pci=norcs doesn’t help. The problem seems to be still not solved and the PCI card remains unrecognized. I have checked it with kernel packages (PAE, i686, f22) ver. 4.0.8-300 and the newest one I can see on repo with testing-pending status, the 4.1.4-200. They are both with this bug.
(In reply to it_man from comment #9) > Thanks Chuck, but unfortunately the pci=norcs doesn’t help. The problem > seems to be still not solved and the PCI card remains unrecognized. > I have checked it with kernel packages (PAE, i686, f22) ver. 4.0.8-300 and > the newest one I can see on repo with testing-pending status, the 4.1.4-200. > They are both with this bug. That's "pci=nocrs", not "pci=norcs". In any case, you should upload the boot messages from the broken and working kernels as separate plain text attachments.
(In reply to Chuck Ebbert from comment #10) > (In reply to it_man from comment #9) > > Thanks Chuck, but unfortunately the pci=norcs doesn’t help. The problem > > seems to be still not solved and the PCI card remains unrecognized. > > I have checked it with kernel packages (PAE, i686, f22) ver. 4.0.8-300 and > > the newest one I can see on repo with testing-pending status, the 4.1.4-200. > > They are both with this bug. > > That's "pci=nocrs", not "pci=norcs". > > In any case, you should upload the boot messages from the broken and working > kernels as separate plain text attachments. Hi Chuck, it was a typo from my side in the answer's text. The tests have been provided with the correct "pci=nocrs" (I have tested it twice just to make it sure). The boot messages are described precisly in my initial post, where I have informed about the bug and nothing more can be added now.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 22 kernel bugs. Fedora 22 has now been rebased to 4.2.3-200.fc22. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.