Bug 132352

Summary: Certain CD/DVD I/O causes network and NetworkManager to go down
Product: [Fedora] Fedora Reporter: Ellen Shull <ellenshull>
Component: NetworkManagerAssignee: Christopher Aillon <caillon>
Status: CLOSED CANTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-10-30 14:29:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 123268, 136451    
Attachments:
Description Flags
strace of the NM with the problem occurring none

Description Ellen Shull 2004-09-11 08:03:15 UTC
Description of problem: 
Certain types of CD/DVD I/O causes the network and NetworkManager to 
go down.  I am unsure whether the network is going down causing NM to 
die, or if NM is freaking out and taking the network down itself.  
The triggering I/O seems to continue along fine without a problem. 
 
Version-Release number of selected component (if applicable): 
NetworkManager-0.2-1 
 
How reproducible: 
always 
 
Steps to Reproduce: 
1.  make sure network is up and happy 
2.  engage in one of the trigger forms of I/O.  So far the two I've 
identified are trying to read bad sectors, and burning a disc.  
Normal reading of discs doesn't seem to cause the problem. 
   
Actual results: 
network goes down, 'service NetworkManager status' reports that 
pidfile is still there but process is dead 
 
Expected results: 
network should stay up! 
 
Additional info: 
My system is current with rawhide, but I've been seeing this problem 
for close to two weeks; I just now made the connection with the 
CD/DVD I/O. 
 
In /var/log/messages is this every time it happens (all at the exact 
same time, so I cut the timestamps for clarity) 
 
NetworkManager: AUTO: Best wired device = (null) 
NetworkManager: AUTO: Best wireless device = (null)  (null) 
NetworkManager: nm_state_modification_monitor(): beginning activation 
for device '(null)' 
 
with this additional line after those in /var/log/debug (to which I 
have syslog dumping *.debug): 
NetworkManager: nm_device_activation_cancel(eth1): canceled 
 
 
The drive (and controller) in question: 
(from dmesg, other drives edited out) 
VP_IDE: IDE controller at PCI slot 0000:00:11.1 
ACPI: PCI interrupt 0000:00:11.1[A] -> GSI 10 (level, low) -> IRQ 10 
VP_IDE: chipset revision 6 
VP_IDE: not 100% native mode: will probe irqs later 
VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci0000:00:11.1 
    ide1: BM-DMA at 0xd408-0xd40f, BIOS settings: hdc:DMA, hdd:pio 
Probing IDE interface ide1... 
hdc: PIONEER DVD-RW DVR-104, ATAPI CD/DVD-ROM drive 
ide1 at 0x170-0x177,0x376 on irq 15 
hdc: ATAPI 24X DVD-ROM DVD-R CD-R/RW drive, 2000kB Cache, UDMA(33) 
 
(from hdparm) 
/dev/hdc: 
 HDIO_GET_MULTCOUNT failed: Invalid argument 
 IO_support   =  1 (32-bit) 
 unmaskirq    =  1 (on) 
 using_dma    =  1 (on) 
 keepsettings =  0 (off) 
 readonly     =  0 (off) 
 readahead    = 256 (on) 
 HDIO_GETGEO failed: Invalid argument 
 
The interface in question (from dmesg) 
Linux Tulip driver version 1.1.13 (May 11, 2002) 
ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 7 (level, low) -> IRQ 7 
tulip0:  MII transceiver #1 config 1000 status 786d advertising 01e1. 
divert: allocating divert_blk for eth1 
eth1: ADMtek Comet rev 17 at 0x1282e000, 00:04:5A:56:3C:A6, IRQ 7. 
 
 
running NM under gdb, as soon as the actual burn starts: 
libhal.c 1560 : Error sending msg: Message did not receive a reply 
libhal.c 1560 : Error sending msg: Message did not receive a reply 
libhal.c 1560 : Error sending msg: Message did not receive a reply 
 
(those three are separated by about a second each, then:) 
 
** (process:4672): CRITICAL **: file NetworkManagerDevice.c: line 290 
(nm_device_ref): assertion `dev != NULL' failed 
 
I'm not familiar with using gdb on threaded apps like NM so wasn't 
able to get a backtrace. 
 
Could be a hal or dbus or kernel problem for all I know, I'm just 
starting at the obvious point. 
 
I will attach output files from 'strace -f -ff -F -o netman -p <pid>' 
showing the problem; I don't know the code so it wasn't very 
enlightening to me.

Comment 1 Ellen Shull 2004-09-11 08:04:52 UTC
Created attachment 103720 [details]
strace of the NM with the problem occurring

Comment 2 Jay Turner 2004-09-17 12:03:44 UTC
I'm still seeing this behavior with 0.2-3 and an e1000 device.

Comment 3 Dan Williams 2005-05-05 18:53:19 UTC
Is this still the same with 0.3 and later?

Comment 4 John Thacker 2006-10-30 14:29:11 UTC
Closing per lack of response to previous request for information.
Note that FC3 and FC4 are supported by Fedora Legacy for security
fixes only.  Please install a still supported version and retest.  If
it still occurs on FC5 or FC6, please reopen and assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.