[vox-tech] eth0 troubles
Peter Jay Salzman
p at dirac.org
Wed Aug 11 11:22:44 PDT 2004
On Wed 11 Aug 04, 11:12 AM, Karalius, Joseph <Joseph.Karalius at seminis.com> said:
> p at dirac.org:
> > On Tue 10 Aug 04, 4:52 PM, Rick Moen <rick at linuxmafia.com> said:
> > > Quoting Karalius, Joseph (Joseph.Karalius at seminis.com):
> > >
> > > > The lights don't come on the onboard gigE port of an
> > Optiplex GX270 when a
> > > > tested cable is plugged into a tested port. Intel 82540EM
> > rev02 chipset.
> > >
> > > Two ideas:
> > >
> > > 1. Your running kernel may not recognise what PCI device this is,
> > > because its PCI ID string may not be in your /usr/share/misc/pci.ids
> > > file. Good news: You can always snarf the latest version
> > of that file
> > > from http://pciids.sf.net/ . (I describe this in my laptop
> > write-up,
> > > http://linuxmafia.com/~rick/inspiron7000.html .)
> > >
> > > 2. Try a 2.6 kernel. You mentioned Knoppix: In 3.4
> > Knoppix releases,
> > > you can boot a "knoppix26" kernel image at the lilo prompt,
> > instead of
> > > the default 2.4 kernel image.
> > >
> > > If that doesn't work, it might indeed be defective. You
> > can download
> > > diagnostic software for this chipset (for MS-DOS) from
> > Intel's Web site.
> >
> > Isn't it also safe to say that if lspci doesn't see the hardware, the
> > hardware is most likley broken?
> >
> > My understanding is that whether the kernel knows what to do with the
> > hardware or not, it should at least see a PCI ID. Or is that
> > incorrect?
>
> The PCI ID is on my /usr/share/misc/pci.ids
> lspci correctly lists the hardware, but does lspci do anything else but read
> the ID, and then get the name from the above file? I could change the name
> in the pci.ids file to 'Joey's F'd up gigE' and it wouldn't affect the
> operation, or lack thereof? Sure, if lspci doesn't detect the hardware, you
> can be assured the hardware is jacked, but successful detection in itself
> cannot be considered passing diagnostics, ¿verdad?
Absolutely not. That's why I said:
"Whether the kernel knows what to do with the hardware or not, it
should at least see a PCI ID."
Just because I tell you I have a Rubik's cube in my hand doesn't mean
you know what to do with it.
To state it mathematically, the kernel knowing the PCI ID of your device
is a *necessary* condition for the device to be functional.
It's simply not a *sufficient* condition for the device to be
functional.
> I downloaded some diagnostic software that I think is the right one, from
> the Intel Download Page
> (http://downloadfinder.intel.com/scripts-df/filter_results.asp?strOSs=All&st
> rTypes=DRV&ProductID=983&OSFullName=All+Operating+Systems&submit=Go%21)
>
> This file seems to be the right one according to the description, but the
> /Tools directory is missing, which of course is where the diagnostic utility
> is supposed to be
> http://downloadfinder.intel.com/scripts-df/Detail_Desc.asp?agr=Y&ProductID=9
> 83&DwnldID=4239
>
> I then googled around for DIAG1000, which seems to be the name of the
> utility I need and found a couple of versions that I can't be sure of
> http://support.buympc.com/apps/filelist.asp?ID=7073 DIAG1000.exe This
> doesn't seem right
>
> Is there a standard tool for diagnosis, or do I need to keep looking for
> this one file?
Can't help you there. But getting PCI devices to work on Linux is
usually very easy with the help of:
1. Google
2. The Ethernet HOWTO (if it's a network card/chipset)
Getting devices to work is basically:
1. Get the name or chipset of the hardware.
2. Google for the appropriate device driver.
3. Compile the driver if it's not already compiled.
4. Load the module.
Although I don't know much about your chipset, the fact that the light
doesn't come on is a very bad sign.
The fact that the kernel knows the PCI ID of the device is encouraging.
Do you know what module is required for your Gigabit device? That's the
first step.
Pete
--
Make everything as simple as possible, but no simpler. -- Albert Einstein
GPG Instructions: http://www.dirac.org/linux/gpg
GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D
More information about the vox-tech
mailing list