Hello,
I recently put up 2 intel network adapters:
00:09.0 Ethernet controller: Intel Corp. 82545EM Gigabit Ethernet Controller (Copper) (rev 01)
00:0b.0 Ethernet controller: Intel Corp. 82545EM Gigabit Ethernet Controller (Copper) (rev 01)
( I replaced some Intel PRO1000 Desktop which I had before ) and now
I get serious problems with the hda disk:
Nov 19 12:42:28 firelog2 kernel: hda: status timeout: status=0x82 { Busy }
Nov 19 12:42:28 firelog2 kernel:
Nov 19 12:42:28 firelog2 kernel: hda: DMA disabled
Nov 19 12:42:28 firelog2 kernel: hda: drive not ready for command
Nov 19 12:42:33 firelog2 kernel: ide0: reset: success
Nov 19 12:43:53 firelog2 kernel: hda: status timeout: status=0x80 { Busy }
Nov 19 12:43:53 firelog2 kernel:
Nov 19 12:43:53 firelog2 kernel: hda: drive not ready for command
Nov 19 12:43:54 firelog2 kernel: ide0: reset: success
Nov 19 12:46:19 firelog2 kernel: hda: status timeout: status=0x80 { Busy }
Nov 19 12:46:19 firelog2 kernel:
Nov 19 12:46:19 firelog2 kernel: hda: drive not ready for command
Nov 19 12:46:19 firelog2 kernel: ide0: reset: success
>From time to time I cannot even boot the system ( even the e1000 module
is not loaded )
The kernel version is 2.4.22 and the intel driver version is : 5.2.20
( I was using the same intel driver and the same kernel version before with
Intel PRO1000 Desktop adapter )
Can anybody help me track down this? to see if it's something hardware related,
only software... is it DMA related?
Teo
> I recently put up 2 intel network adapters:
> 00:09.0 Ethernet controller: Intel Corp. 82545EM Gigabit
> Ethernet Controller (Copper) (rev 01)
> 00:0b.0 Ethernet controller: Intel Corp. 82545EM Gigabit
> Ethernet Controller (Copper) (rev 01)
>
> ( I replaced some Intel PRO1000 Desktop which I had before ) and now
> I get serious problems with the hda disk:
Did you put the 82545 nics in the same slots where you had the desktop
nics?
Are the 82545 nics on the same bus segment as the disk controller? Are
there any shared interrupts? See lcpci -vvv.
-scott
I put them at first on the same slots.. then I changed the slots to see if the trouble goes away
and got the same results. There are no shared interrupts. At this moment at PCI Device Listing
I get the NICs on irq 10 and 11, the 1st IDE on 14 and VGA on 15 ( the 2nd IDE is disabled )
I disabled DMA on ide ( with hdparm -d 0 /dev/hda ), but now I see after a few hours of traffic
going through this machine errors in logs like hell:
end_request: I/O error, dev 03:02 (hda), sector 16515104
end_request: I/O error, dev 03:02 (hda), sector 16777248
end_request: I/O error, dev 03:03 (hda), sector 524344
end_request: I/O error, dev 03:03 (hda), sector 7864352
end_request: I/O error, dev 03:03 (hda), sector 14155920
end_request: I/O error, dev 03:03 (hda), sector 524320
vmstat 1 shows like this:
0 0 0 0 343764 38464 35004 0 0 0 0 5901 1025 0 26 74
0 0 0 0 343756 38472 35004 0 0 0 8 5919 906 0 30 70
0 0 0 0 343756 38472 35004 0 0 0 0 5712 915 0 30 70
0 0 1 0 343756 38472 35004 0 0 0 0 5641 929 0 28 72
00:09.0 Ethernet controller: Intel Corp. 82545EM Gigabit Ethernet Controller (Copper) (rev 01)
Subsystem: Intel Corp. PRO/1000 MT Server Adapter
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (63750ns min), cache line size 08
Interrupt: pin A routed to IRQ 10
Region 0: Memory at e2c00000 (64-bit, non-prefetchable) [size=128K]
Region 4: I/O ports at d000 [size=64]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [e4] PCI-X non-bridge device.
Command: DPERE- ERO+ RBC=0 OST=0
Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-, DC=simple, DMMRBC=0, DMOST=0, DMCRS=0, RSCEM-
Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
00:0b.0 Ethernet controller: Intel Corp. 82545EM Gigabit Ethernet Controller (Copper) (rev 01)
Subsystem: Intel Corp. PRO/1000 MT Server Adapter
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (63750ns min), cache line size 08
Interrupt: pin A routed to IRQ 11
Region 0: Memory at e2c20000 (64-bit, non-prefetchable) [size=128K]
Region 4: I/O ports at d400 [size=64]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [e4] PCI-X non-bridge device.
Command: DPERE- ERO+ RBC=0 OST=0
Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-, DC=simple, DMMRBC=0, DMOST=0, DMCRS=0, RSCEM-
Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
Btw.. I don't know what you mean on the same bus segment.
On Wed, Nov 19, 2003 at 07:02:27PM -0800, Feldman, Scott wrote:
> > I recently put up 2 intel network adapters:
> > 00:09.0 Ethernet controller: Intel Corp. 82545EM Gigabit
> > Ethernet Controller (Copper) (rev 01)
> > 00:0b.0 Ethernet controller: Intel Corp. 82545EM Gigabit
> > Ethernet Controller (Copper) (rev 01)
> >
> > ( I replaced some Intel PRO1000 Desktop which I had before ) and now
> > I get serious problems with the hda disk:
>
> Did you put the 82545 nics in the same slots where you had the desktop
> nics?
>
> Are the 82545 nics on the same bus segment as the disk controller? Are
> there any shared interrupts? See lcpci -vvv.
>
> -scott
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Teodor Iacob,
Manager Infrastructura Nationala
Astral Telecom Internet
I found something really interesting. I am now able to reproduce problems
exactly at the same point:
If I boot the machine without ethernet cables connected before loading
the kernel the machine seems to work fine for a while. If I put for
example a crossover cable between the cards I cannot even boot the system!
right after the kernel initialization after it starts the init I get
IDE errors and then freezes because it cannot run the commands in
rc.sysinit.
I have to mention I also tried the built-in driver of intel e1000.
The 5.2.20 of course it was loaded as a module at network scripts
initialization.
So the problems trims down to how can those NICs can affect the IDE
only when they have cables connected ( even though without the driver
initialization they don't have the led link on ) even without traffic
going through them.
On Wed, Nov 19, 2003 at 07:02:27PM -0800, Feldman, Scott wrote:
> > I recently put up 2 intel network adapters:
> > 00:09.0 Ethernet controller: Intel Corp. 82545EM Gigabit
> > Ethernet Controller (Copper) (rev 01)
> > 00:0b.0 Ethernet controller: Intel Corp. 82545EM Gigabit
> > Ethernet Controller (Copper) (rev 01)
> >
> > ( I replaced some Intel PRO1000 Desktop which I had before ) and now
> > I get serious problems with the hda disk:
>
> Did you put the 82545 nics in the same slots where you had the desktop
> nics?
>
> Are the 82545 nics on the same bus segment as the disk controller? Are
> there any shared interrupts? See lcpci -vvv.
>
> -scott
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Teodor Iacob,
Manager Infrastructura Nationala
Astral Telecom Internet
One more thing to add:
After a few of those kind of freezes the BIOS won't even recognize the
Harddisk anymore, I had to turn on the machine without the harddisk in it
then I forced the bios to update ESCD and the put back the harddrive in it
and worked. Somehow those cards affect the system anyway. ( even only in
CMOS setup )
On Thu, Nov 20, 2003 at 01:22:17PM +0200, Teodor Iacob wrote:
> I found something really interesting. I am now able to reproduce problems
> exactly at the same point:
>
> If I boot the machine without ethernet cables connected before loading
> the kernel the machine seems to work fine for a while. If I put for
> example a crossover cable between the cards I cannot even boot the system!
> right after the kernel initialization after it starts the init I get
> IDE errors and then freezes because it cannot run the commands in
> rc.sysinit.
>
> I have to mention I also tried the built-in driver of intel e1000.
> The 5.2.20 of course it was loaded as a module at network scripts
> initialization.
>
> So the problems trims down to how can those NICs can affect the IDE
> only when they have cables connected ( even though without the driver
> initialization they don't have the led link on ) even without traffic
> going through them.
>
> On Wed, Nov 19, 2003 at 07:02:27PM -0800, Feldman, Scott wrote:
> > > I recently put up 2 intel network adapters:
> > > 00:09.0 Ethernet controller: Intel Corp. 82545EM Gigabit
> > > Ethernet Controller (Copper) (rev 01)
> > > 00:0b.0 Ethernet controller: Intel Corp. 82545EM Gigabit
> > > Ethernet Controller (Copper) (rev 01)
> > >
> > > ( I replaced some Intel PRO1000 Desktop which I had before ) and now
> > > I get serious problems with the hda disk:
> >
> > Did you put the 82545 nics in the same slots where you had the desktop
> > nics?
> >
> > Are the 82545 nics on the same bus segment as the disk controller? Are
> > there any shared interrupts? See lcpci -vvv.
> >
> > -scott
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
--
Teodor Iacob,
Manager Infrastructura Nationala
Astral Telecom Internet
Last thing I did.. I changed the motherboard from Soltek 75DRV5 with KT333
to a Shuttle with KT400 .. no problems anymore. Sorry for the spam
and trouble :)
On Thu, Nov 20, 2003 at 02:45:35PM +0200, Teodor Iacob wrote:
> One more thing to add:
>
> After a few of those kind of freezes the BIOS won't even recognize the
> Harddisk anymore, I had to turn on the machine without the harddisk in it
> then I forced the bios to update ESCD and the put back the harddrive in it
> and worked. Somehow those cards affect the system anyway. ( even only in
> CMOS setup )
>
> On Thu, Nov 20, 2003 at 01:22:17PM +0200, Teodor Iacob wrote:
> > I found something really interesting. I am now able to reproduce problems
> > exactly at the same point:
> >
> > If I boot the machine without ethernet cables connected before loading
> > the kernel the machine seems to work fine for a while. If I put for
> > example a crossover cable between the cards I cannot even boot the system!
> > right after the kernel initialization after it starts the init I get
> > IDE errors and then freezes because it cannot run the commands in
> > rc.sysinit.
> >
> > I have to mention I also tried the built-in driver of intel e1000.
> > The 5.2.20 of course it was loaded as a module at network scripts
> > initialization.
> >
> > So the problems trims down to how can those NICs can affect the IDE
> > only when they have cables connected ( even though without the driver
> > initialization they don't have the led link on ) even without traffic
> > going through them.
> >
> > On Wed, Nov 19, 2003 at 07:02:27PM -0800, Feldman, Scott wrote:
> > > > I recently put up 2 intel network adapters:
> > > > 00:09.0 Ethernet controller: Intel Corp. 82545EM Gigabit
> > > > Ethernet Controller (Copper) (rev 01)
> > > > 00:0b.0 Ethernet controller: Intel Corp. 82545EM Gigabit
> > > > Ethernet Controller (Copper) (rev 01)
> > > >
> > > > ( I replaced some Intel PRO1000 Desktop which I had before ) and now
> > > > I get serious problems with the hda disk:
> > >
> > > Did you put the 82545 nics in the same slots where you had the desktop
> > > nics?
> > >
> > > Are the 82545 nics on the same bus segment as the disk controller? Are
> > > there any shared interrupts? See lcpci -vvv.
> > >
> > > -scott
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to [email protected]
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at http://www.tux.org/lkml/
> >
>
--
Teodor Iacob,
Manager Infrastructura Nationala
Astral Telecom Internet