Created attachment 568969 [details] dmesg log Description of problem: System bootup delayed Version-Release number of selected component (if applicable): kernel-3.3.0-0.rc6.git0.2.fc17.x86_64 How reproducible: Always using the kernel-3.3.0-0.rc6.git0.2.fc17.x86_64. Actual results: Fedora seems perfectly useable.
"BUG: soft lockup - CPU#0 stuck for 23s! [biosdevname:448]" disappears with kernel-3.3.0-0.rc6.git2.1.fc17.x86_64.
"BUG: soft lockup - CPU#0 stuck for 23s! [biosdevname:423]" appears again with kernel-3.3.0-0.rc7.git0.2.fc17.x86_64. Does this issue depend from kernel debugging options activated/deactivated ? Regards.
(In reply to comment #2) > "BUG: soft lockup - CPU#0 stuck for 23s! [biosdevname:423]" appears again with > kernel-3.3.0-0.rc7.git0.2.fc17.x86_64. > > Does this issue depend from kernel debugging options activated/deactivated ? > > Regards. Hi, is the issue seen if you boot into the kernel with 'biosdevname=0' passed (on the kernel where you see the issue) ? It seems like this issue is same/similar to bug 781572. It could be that the vpd is not implemented/broken on the network adapter and a read of it is causing the hang. Could you please provide the following info from your system ? dmidecode biosdecode lspci -vvvxxx (needs to be run as root)
(In reply to comment #3) > (In reply to comment #2) > > "BUG: soft lockup - CPU#0 stuck for 23s! [biosdevname:423]" appears again with > > kernel-3.3.0-0.rc7.git0.2.fc17.x86_64. > > > > Does this issue depend from kernel debugging options activated/deactivated ? > > > > Regards. > > Hi, is the issue seen if you boot into the kernel with 'biosdevname=0' passed > (on the kernel where you see the issue) ? > > It seems like this issue is same/similar to bug 781572. It could be that the > vpd is not implemented/broken on the network adapter and a read of it is > causing the hang. > > Could you please provide the following info from your system ? > > dmidecode > biosdecode > lspci -vvvxxx (needs to be run as root) With biosdevname=0 passed, the "BUG": soft lockup is not present.
Created attachment 569721 [details] lspci/dmidecode/biosdecode The archive contains the logs requested.
(In reply to comment #5) > Created attachment 569721 [details] > lspci/dmidecode/biosdecode > > The archive contains the logs requested. 09:00.0 Ethernet controller: Atheros Communications AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) Subsystem: Atheros Communications AR8121/AR8113/AR8114 Gigabit or Fast Ethernet <snip> Capabilities: [6c] Vital Product Data Unknown small resource type 0b, will not decode more. Hi, from the attached 'lspci' output, it looks like the VPD is not implemented/broken on this network adapter. (similar to bug 781572 - the network adapter is also the same) Is the firmware latest on the adapter ?
(In reply to comment #6) > (In reply to comment #5) > > Created attachment 569721 [details] > > lspci/dmidecode/biosdecode > > > > The archive contains the logs requested. > > 09:00.0 Ethernet controller: Atheros Communications AR8121/AR8113/AR8114 > Gigabit or Fast Ethernet (rev b0) > Subsystem: Atheros Communications AR8121/AR8113/AR8114 Gigabit or Fast > Ethernet > > <snip> > > Capabilities: [6c] Vital Product Data > Unknown small resource type 0b, will not decode more. > > Hi, from the attached 'lspci' output, it looks like the VPD is not > implemented/broken on this network adapter. (similar to bug 781572 - the > network adapter is also the same) > > Is the firmware latest on the adapter ? I do not know. The 'Atheros ethernet controller' works fine from ever. Its module atl1e was not loaded and maybe doesn't need of any firmware. Am i wrong ? $ modinfo atl1e filename: /lib/modules/3.3.0-0.rc7.git0.2.fc17.x86_64/kernel/drivers/net/ethernet/atheros/atl1e/atl1e.ko version: 1.0.0.7-NAPI license: GPL description: Atheros 1000M Ethernet Network Driver author: Atheros Corporation, <xiong.huang>, Jie Yang <jie.yang> srcversion: DBA608BB9CF6688ED7C83DE alias: pci:v00001969d00001066sv*sd*bc*sc*i* alias: pci:v00001969d00001026sv*sd*bc*sc*i* depends: intree: Y vermagic: 3.3.0-0.rc7.git0.2.fc17.x86_64 SMP mod_unload parm: tx_desc_cnt:Transmit description count (array of int) parm: rx_mem_size:memory size of rx buffer(KB) (array of int) parm: media_type:MediaType Select (array of int) parm: int_mod_timer:Interrupt Moderator Timer (array of int)
This problem still remains with kernel-3.3.0-1.fc17.x86_64 .
Please, can you say me if biosdevname is a critical component or if is it in the process of resolution ? Can i remove it ? Regards.
(In reply to comment #9) > Please, can you say me if biosdevname is a critical component or if is it in > the process of resolution ? > Can i remove it ? Hi, we are exploring a fix to address this issue. biosdevname suggests names to network interfaces based on their location on system motherboard, such as onboard or PCI add-in. Onboard interfaces will be named: em<port number> (em1, em2 etc) Add-in interfaces will be named: p<slot number>p<port number> (p2p1, p2p2 etc) If this functionality is not desired, then biosdevname can be disabled by passing 'biosdevname=0' to the boot command line during and after installation. If biosdevname is not used, the network interfaces will have traditional 'eth' names.
The problem still remains with biosdevname-0.3.11-6.fc17 .
(In reply to comment #11) > The problem still remains with biosdevname-0.3.11-6.fc17 . Hi, could you please test the attached test rpm built from Fedora 16 sources on your system and let us know the results ? After the rpm is installed, please ensure that 70-persistent-net.rules file is deleted. 1. rpm -Uvh <attached biosdevname test rpm> 2. rm /etc/udev/rules.d/70-persistent-net.rules 3. ensure that /etc/sysconfig/network-scripts/ifcfg-* contain the correct DEVICE= (such as emN). The correct emN can be determined by running 'biosdevname -d' (as the test rpm is already installed in step 1). 4. Reboot the system. Observe and report if the issue described in the BZ is still seen.
Created attachment 576565 [details] biosdevname test rpm
(In reply to comment #12) > (In reply to comment #11) > > The problem still remains with biosdevname-0.3.11-6.fc17 . > > Hi, could you please test the attached test rpm built from Fedora 16 sources on > your system and let us know the results ? > > After the rpm is installed, please ensure that 70-persistent-net.rules file is > deleted. > > 1. rpm -Uvh <attached biosdevname test rpm> Done. > 2. rm /etc/udev/rules.d/70-persistent-net.rules This file doesn't exist. > 3. ensure that /etc/sysconfig/network-scripts/ifcfg-* contain the correct > DEVICE= (such as emN). # cat /etc/sysconfig/network-scripts/ifcfg-Auto_Netgear (the DEVICE entry has been added by me): ESSID="Netgear" DEVICE=p3p1 MODE=Managed KEY_MGMT=WPA-PSK TYPE=Wireless BOOTPROTO=dhcp DEFROUTE=yes IPV4_FAILURE_FATAL=yes IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no NAME="Auto Netgear" UUID=951a9c76-bdab-4ea4-b8c5-3c9d721eb3c5 ONBOOT=yes HWADDR=00:21:5D:50:F0:5A WPA_ALLOW_WPA=yes WPA_ALLOW_WPA2=yes PEERDNS=yes PEERROUTES=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes ZONE=home >The correct emN can be determined by running > 'biosdevname -d' (as the test rpm is already installed in step 1). # biosdevname -d BIOS device: p3p1 Kernel name: wlan0 Permanent MAC: 00:21:5D:50:F0:5A Assigned MAC : 00:21:5D:50:F0:5A ifIndex: 3 Driver: iwlwifi Driver version: 3.3.1-3.fc17.x86_64 Firmware version: 8.83.5.1 build 33692 Bus Info: 0000:07:00.0 PCI name : 0000:07:00.0 PCI Slot : 3 Index in slot: 1 BIOS device: p5p1 Kernel name: p5p1 Permanent MAC: 00:23:8B:2E:05:C3 Assigned MAC : 00:23:8B:2E:05:C3 ifIndex: 2 Driver: ATL1E Driver version: 1.0.0.7-NAPI Firmware version: L1e Bus Info: 0000:09:00.0 PCI name : 0000:09:00.0 PCI Slot : 5 Index in slot: 1 > 4. Reboot the system. Observe and report if the issue described in the BZ is > still seen. The error is desappeared. :)
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This issue is similar to https://bugzilla.redhat.com/show_bug.cgi?id=781572 and is addressed in biosdevname-0.4.1-1.fc17.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.