Bug 169507 - Network link down (B44), when writting to SATA disk AND network in use
Network link down (B44), when writting to SATA disk AND network in use
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: John W. Linville
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-09-29 00:38 EDT by starlight
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-12-08 13:39:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description starlight 2005-09-29 00:38:28 EDT
Description of problem:

I'm encountering the same problem described here:


However the only thing exactly the same about the system is the B44
chip integrated on the mainboard.  Different mainboard (Dell),
different SATA board (Adaptec 1205SA), different SATA chip (SiI 3112),
different disk (Hitachi Deskstar 7K500, HDS725050KLA360).

The B44 Ethernet link on the Dell mainboard cycles down and up
when a 'rsh other_box cat file.gz | gzip -d >file' is executed.
After I write this, I'm planning to throw in a PCI Ethernet card
to work around the issue, but it seems like something that should
be fixed.

Kernel is 2.6.9-11.EL.

'dmesg' says this about the devices:

b44.c:v0.95 (Aug 3, 2004)
ACPI: PCI interrupt 0000:01:09.0[A] -> GSI 3 (level, low) -> IRQ 3
divert: allocating divert_blk for eth0
eth0: Broadcom 4400 10/100BaseT Ethernet 00:0d:56:5d:a7:31
Linux Tulip driver version 1.1.13 (May 11, 2002)
libata version 1.10 loaded.
sata_sil version 0.8
ACPI: PCI interrupt 0000:01:04.0[A] -> GSI 11 (level, low) -> IRQ 11
ata1: SATA max UDMA/100 cmd 0xF0840E80 ctl 0xF0840E8A bmdma 0xF0840E00 irq 11
ata2: SATA max UDMA/100 cmd 0xF0840EC0 ctl 0xF0840ECA bmdma 0xF0840E08 irq 11
ata1: dev 0 cfg 49:2f00 82:346b 83:7fe9 84:4773 85:3468 86:3c01 87:4763 8:207f
ata1: dev 0 ATA, max UDMA/133, 976773168 sectors: lba48
ata1: dev 0 configured for UDMA/100
scsi0 : sata_sil
ata2: no device found (phy stat 00000000)
scsi1 : sata_sil
  Vendor: ATA       Model: HDS725050KLA360   Rev: K2AO
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 976773168 512-byte hdwr sectors (500108 MB)
SCSI device sda: drive cache: write back
 sda: sda1
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0

'lspci -v' says this about the devices:

01:04.0 Unknown mass storage controller: Silicon Image, Inc. SiI 3112
[SATALink/SATARaid] Serial ATA Controller (rev 02) (prog-if 01)
        Subsystem: Adaptec: Unknown device 0250
        Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11
        I/O ports at dfe0 [size=8]
        I/O ports at dfa8 [size=4]
        I/O ports at dfe8 [size=8]
        I/O ports at dfac [size=4]
        I/O ports at dff0 [size=16]
        Memory at fe9fde00 (32-bit, non-prefetchable) [size=512]
        Expansion ROM at fea00000 [disabled] [size=512K]
        Capabilities: [60] Power Management version 2

01:09.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01)
        Subsystem: Dell: Unknown device 8127
        Flags: bus master, fast devsel, latency 64, IRQ 3
        Memory at fe9fe000 (32-bit, non-prefetchable) [size=8K]
        Expansion ROM at fea00000 [disabled] [size=16K]
        Capabilities: [40] Power Management version 2

Happy to provide any other details that might be of interest.
Comment 1 John W. Linville 2005-10-07 13:01:27 EDT
Strange...first reaction would be that they were sharing an interrupt, but 
information above does not support that...hmmm... 
Comment 3 John W. Linville 2005-10-20 11:07:46 EDT
Just curious, have you tried adding "acpi=off" or "acpi=noirq" to your kernel 
command line when booting? 
Comment 4 starlight 2005-10-20 11:50:52 EDT
No.  I'll try it next time the covers are off, but right
now the system critically in use.  The D-Link NIC I threw
in did eliminate the problem.
Comment 5 John W. Linville 2005-12-08 13:39:16 EST
Closed due to lack of response.  Please reopen when the requested information  
becomes available...thanks! 

Note You need to log in before you can comment on or make changes to this bug.