lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 18 Feb 2009 15:02:24 -0700
From:	Michael Grollman <mgrollman@...us.com>
To:	netdev@...r.kernel.org
Subject: Reboot Hangs When R8169 Loaded, Intel D945GCLF Atom Board With Anything
 in PCI Slot, 2.6.28-6 Vanilla Kernel  & Debian Etch


(This is a newbie reporting the problem, so take it with a grain of 
salt, to be sure.)

Reboot hangs when R8169 loaded, Intel D945GCLF Atom MB, 2.6.28-6 vanilla 
kernel on Debian etch if any card is in PCI slot.

I do know truly that the r8169 module is the culprit, but since r8169 
has fingerprints on the problem (see below), and I have had several 
issues with the D945GCLF before for me with this driver, I figured might 
as well start there, and report it as such.  If I am filing this in the 
wrong place, please direct me to a better one.

Tested 2.6.28-5 and 2.6.28-6 on the D945GCLF.  With no devices in the 
PCI slot, and r8169 enabled, unit will shutdown -h and showdown -r just 
fine, and r8169 working in practice.

However, when any PCI device, and I tried video capture cards, USB port 
expander cards, unrelated network cards using different chip sets, WiFi 
PCI cards, any card I tried, shutdown -h continued to work fine, but any 
attempt at reboot with either reboot command or shutdown -r  resulted in 
a system that did not reboot, just displayed the message as follows:

<snip>
Will now restart
r8169 0000:00:00.0: PME# enable
Restarting system
machine restart

And then it just sits there.

I did not have this issue with this Motherboard D945GCLF with 2.6.26.

Here is what makes me think the r8169 might be involved:

* When I ifdown eth0, reboot still does not work;
* When I rmmod r8169 just prior to reboot, then reboot works fine (and 
there is then no r8169  in the Restart message) ;
* When I disable the r8169 in BIOS, the reboot function works fine again 
(obviously not the Ethernet port then)

I include an excerpted  lspic -v and dmesg below, for reference.  I can 
live with the rmmod r8169 just prior to reboot as a work-around, but it 
seems like there must be a cleaner fix somewhere.

Cheers,

- Michael


lspic -v:

<snip>
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E 
PCI Express Fast Ethernet controller (rev 02)
    Subsystem: Intel Corporation Unknown device 0001
    Flags: bus master, fast devsel, latency 0, IRQ 508
    I/O ports at 1000 [size=256]
    Memory at 30200000 (64-bit, non-prefetchable) [size=4K]
    Memory at 30000000 (64-bit, prefetchable) [size=64K]
    Expansion ROM at 30020000 [disabled] [size=128K]
    Capabilities: [40] Power Management version 3
    Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ 
Queue=0/0 Enable+
    Capabilities: [70] Express Endpoint IRQ 1
    Capabilities: [ac] MSI-X: Enable- Mask- TabSize=2
    Capabilities: [cc] Vital Product Data
<snip>


dmesg:
<snip>
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:01:00.0: found PCI INT A -> IRQ 11
r8169 0000:01:00.0: sharing IRQ 11 with 0000:00:02.0
r8169 0000:01:00.0: sharing IRQ 11 with 0000:00:1d.3
r8169 0000:01:00.0: setting latency timer to 64
r8169 0000:01:00.0: irq 508 for MSI/MSI-X
<snip>




--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ