Red Hat Bugzilla – Bug 118102
(NET ACENIC)oops during bootup in ethtool
Last modified: 2013-07-02 22:18:40 EDT
Description of problem:
Did upgrade from Fedora Core release 1 (Yarrow) to
Fedora Core 2 test 1. First try got to "About to Upgrade" screen,
then eventually reported there was not enough disk space in /usr.
I deleted /usr/doc, and retried. Worked until tried to reboot after
install, when it gave an oops during running of ethtool. This oops
happens every time with the Fedora kernel (2.6.1-1.65). It does not
happen if I boot with vanilla 2.6.1 or with a CITI patched
Version-Release number of selected component (if applicable):
Fedora Core 2 test 1
I've attached the boot messages from the (nonworking) Fedora kernel
and another (working) kernel, as well as output from scanpci.
Created attachment 98469 [details]
boot messages and scanpci dump
Looks like a driver bug.
I guess the difference between FC2 test1 kernel and the vanilla / CITI
kernels you're using is that the latter don't have SELinux compiled
Does the oops happen if you don't bringup the eth interface in
interactive startup but later using ifconfig? Do you get the same oops
Oh, silly me. It is totally obvious from your boot logs that SELinux
is not enabled in vanilla / CITI kernels. If you boot FC2 test1 with
selinux=0 the oops should go away.
That doesn't explain the panic though.
Yes, oops still happens if use interactive startup to avoid
up the eth interface and then later using ifconfig.
Here is relevant snippet from bootup
Start service network (Y)es/(N)o/(C)ontinue? [Y]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Start service eth1 (Y)es/(N)o/(C)ontinue? [Y] n
Start service syslog (Y)es/(N)o/(C)ontinue? [Y] c
Then as root `ifconfig eth1 up` causes basically same oops.
Ok, at the boot menu press 'e' to edit the args and append 'selinux=0'
to the 'kernel' line. Does that make the oops go away?
Created attachment 98660 [details]
Boot log with oops (selinux=0)
Adding selinux=0 still has oops (with slightly different stack trace)
*** This bug has been marked as a duplicate of 119491 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.