Description of problem: When I close down the screen of my laptop and open it again, the eth0 ethernet interface has disappeared, my network connection has been closed. ifconfig eth0 up do not work because eth0 is unknown ifconfig -a do not show eth0 after the screen was closed. Pressing Alt CTRL Backspace to reset X server do not fix eth0. The wireless interface (wlan0) is not concerned. Version-Release number of selected component (if applicable): unknown How reproducible: Every time I close the screen on fedora. Steps to Reproduce: 1. ifconfig -a shows you (a working) eth0 interface 2. Close your laptop screen 3. Open your laptop screen 4. ifconfig -a show you NO eth0 interface Actual results: None Expected results: When I close the screen, I expect that fedora do not interfere with my network connection (keep it connected and keep the interface alive). Additional info: Laptop : Dell latitude D520 Kernel: Linux ****** 2.6.29.4-167.fc11.x86_64 #1 SMP Wed May 27 17:27:08 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
Before closing the screen lspci shows me Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02) After closing the screen (and restarting X) this line has disappeared from lspci.
Thanks for filling this bug. Can you please provide your /var/log/messages after you open the lid again. What are your power management settings when the lid is closed? Please be aware that it make a difference if you on AC or battery power. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
1) Running on AC. su - rm /var/log/messages * Close my screen * Open my screen * ALT + CTRL + Backspace to restart X because my screen do not switch on ( see BUG : 506419) Login on my user name su - cat /var/log/messages says the file does not exist
Created attachment 348246 [details] see comment 3 The /var/log/message after - starting computer on AC, - login - unplug the Ac power.
2) Running on Battery: IDEM * The PC was on AC: su - rm /var/log/messages * reboot * login * unplug the AC power cat /var/log/messages (that messages1.txt attached in comment #3) rm /var/log/messages * close the screen * open the screen * ALT CTRL Backsapce to restart X Login on my user name su - cat /var/log/messages says the file does not exists
Created attachment 348248 [details] My powerdevil settings My powerdevil settings
3) Restarting X alone Do not bug. * Start my computer * login * ALT CTRL Backsapce to restart X * login --> eth0 is working. 4) Power management: I've attached the powerdevil settings. (comment #6) Do you need additional information? Where can I find them?
Reporter, please to not rm your /var/log/messages. To get a mark in the file, please do 'echo "closing lid now" >> /var/log/messages' as root or something similar. So please start-up your system, copy your messages to /tmp su -c 'cp /var/log/messages /tmp && chmod 777 /tmp/messages_after_boot' Set a mark on the messages su -c 'echo "### closing lid now ###" >> /var/log/messages' close your lid, open it again, try to active the eth0 interface with NM su -c 'cp /var/log/messages /tmp && chmod 777 /tmp/messages_after_lid_close' please attach the two files from /tmp. Thank you. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 349230 [details] Requested messages I did NOT try to connect Network Manages (NM) using eth0 because eth0 has disapeared. Instead I uncheck use netxork, and then I check it again. eth0 is the bugged ethernet connection wlan0 is my working wireless connection (see attached files) ### closing lid now ### Jun 24 14:18:26 pcpblavy dhclient: receive_packet failed on eth0: Network is down Jun 24 14:18:26 pcpblavy avahi-daemon[1473]: Interface eth0.IPv4 no longer relevant for mDNS. Jun 24 14:18:26 pcpblavy avahi-daemon[1473]: Leaving mDNS multicast group on interface eth0.IPv4 with address 131.254.100.149. Jun 24 14:18:26 pcpblavy kernel: b44: eth0: powering down PHY Jun 24 14:18:26 pcpblavy avahi-daemon[1473]: Withdrawing address record for fe80::219:b9ff:fe56:799d on eth0. Jun 24 14:18:26 pcpblavy avahi-daemon[1473]: Withdrawing address record for 131.254.100.149 on eth0. Jun 24 14:18:26 pcpblavy NetworkManager: <info> (eth0): now unmanaged Jun 24 14:18:26 pcpblavy NetworkManager: <info> (eth0): device state change: 8 -> 1 Jun 24 14:18:26 pcpblavy NetworkManager: <info> (eth0): deactivating device (reason: 36). Jun 24 14:18:26 pcpblavy NetworkManager: <info> eth0: canceled DHCP transaction, dhcp client pid 1851 Jun 24 14:18:26 pcpblavy NetworkManager: <info> Policy set 'Auto INRIA' (wlan0) as default for routing and DNS. Jun 24 14:18:26 pcpblavy NetworkManager: nm_system_device_flush_ip4_routes_with_iface: assertion `iface_idx >= 0' failed Jun 24 14:18:26 pcpblavy NetworkManager: nm_system_device_flush_ip4_addresses_with_iface: assertion `iface_idx >= 0' failed Jun 24 14:18:26 pcpblavy NetworkManager: <info> (eth0): cleaning up... Jun 24 14:18:26 pcpblavy nm-dispatcher.action: Error in get_property: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist#012 Jun 24 14:18:26 pcpblavy kernel: b44 0000:02:00.0: PCI INT A disabled Jun 24 14:18:27 pcpblavy kernel: type=1400 audit(1245845907.761:5): avc: denied { mmap_zero } for pid=2511 comm="vbetool" scontext=system_u:system_r:apmd_t:s0 tcontext=system_u:system_r:apmd_t:s0 tclass=memprotect Jun 24 14:18:28 pcpblavy ntpd[1709]: Deleting interface #4 eth0, fe80::219:b9ff:fe56:799d#123, interface stats: received=0, sent=0, dropped=0, active_time=178 secs Jun 24 14:18:28 pcpblavy ntpd[1709]: Deleting interface #5 eth0, 131.254.100.149#123, interface stats: received=0, sent=7, dropped=0, active_time=172 secs Jun 24 14:18:33 pcpblavy kernel: type=1400 audit(1245845913.481:6): avc: denied { mmap_zero } for pid=2531 comm="vbetool" scontext=system_u:system_r:apmd_t:s0 tcontext=system_u:system_r:apmd_t:s0 tclass=memprotect
Seems like a kernel driver issue. Can you try latest F11 update kernels (2.6.30.9-96.fc11) and report whether they fix your issue?
This is still happening in F-12.
I've tryed su - setenforce 0 The bug is fixed. So it seems that's a selinux problem. rpm -qf /usr/sbin/setenforce libselinux-utils-2.0.80-1.fc11.x86_64 rpm -q selinux-policy selinux-policy-3.6.12-86.fc11.noarch
The last F11 kernell do not fix the bug uname -a Linux pcpierre 2.6.30.9-96.fc11.x86_64 #1 SMP Wed Nov 4 00:02:04 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
Pierre, can you try to relabel to isolate the SELinux problem? su - touch /.autorelabel then reboot and let it relabel your files, then try to reproduce the issue. If something happened and a fiel doesn't have the right label it might cause the selinux issues. (dan, what's the non-rebooting relabel magic again?)
fixfiles restore Are you seeing any AVC messages in /var/log/audit/audit.log The error I do see is apmd running vbetool, which policy does not currently allow. I was not aware that it did this.
Miroslav looks like we need optional_policy(` vbetool_domtrans(apmd_t) ')
Fixed in selinux-policy-3.6.12-91.fc11
Fix confirmed. eth0 is working ;) Thank you very much for your work.
Still working in Fedora 12 :)
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11'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 11 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping