[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: eepro100 detection fail? (and a success story :-))
From: |
arief# |
Subject: |
Re: eepro100 detection fail? (and a success story :-)) |
Date: |
Wed, 28 Jul 2004 15:21:19 +0700 |
Dear all,
I've tried Patrick suggestion, go to the BIOS, and after some round, I
finally able to make my NIC stand alone at IRQ-11. But still failed. No
eepro100 detected.
And tried Adrian suggestion and replace eepro100.c from src/ to dev/
directory, after a lot of fixes of compilation errors, I finally get
that one compiled. But still failed.
And Marco, thanks for your suggestion, but I don't know how to move to
another PCI slot in a thinkpad laptop, yet... ;-)
I even try to hardcode IRQ and PCI address of the card directly in
eepro100.c (in eepro100_init function), I'm not sure I did that
correctly, but that also did not work. Anybody knows how to do that
correctly?
Any other advice?
Or could someone show me the way to Oskit-mach sources without the need
of CVS (my office proxy don't allow CVS access) ?
Thanks for everyone.
Best Regards.
-arief
On Tue, 2004-07-27 at 16:13, Patrick Strasser wrote:
> arief# wrote:
> > Dear all,
> > [...]
> > I dont have a working eth0 device.
> > In linux I use eepro100 as the driver, and I can see that this is
> > supported in gnumach. But nothing appears as eepro100 in /dev/klog.
> > Funny, I guess, so I take a few more ups and downs in the hurd.
> >
> > Finally I get myself compiling gnumach that I got from debian's ftp
> > (package name: gnumach_20040229.orig.tar.gz) with this configure
> > command: ./configure --enable-lpr --enable-floppy --enable-ide
> > --enable-eexpresspro100 --host=i386-gnu --build=i386-linux.
>
> It's not driver support that fails, but Shared Interrupts. The Safe Way
> of installing Debian GNU/Hurd is removing or disabeling or removing all
> unnecessary components like USB or Sound and leave just the really
> needed things in, usually graphics and network.
>
> > What happened? I dont know.
> >
> > Below here, I attach my lspci -v output.
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> > 0000:00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 02)
> > (prog-if 00 [UHCI])
> > Flags: bus master, medium devsel, latency 0, IRQ 11
> > 0000:00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev 02)
> > (prog-if 00 [UHCI])
> > Flags: bus master, medium devsel, latency 0, IRQ 11
> > 0000:00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev 02)
> > (prog-if 00 [UHCI])
> > Flags: bus master, medium devsel, latency 0, IRQ 11
> > 0000:00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02) (prog-if
> > 8a [Master SecP PriP])
> > Flags: bus master, medium devsel, latency 0, IRQ 11
> > 0000:00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus Controller (rev 02)
> > Flags: medium devsel, IRQ 5
> > 0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97
> > Audio Controller (rev 02)
> > Flags: bus master, medium devsel, latency 0, IRQ 5
> > 0000:00:1f.6 Modem: Intel Corp. 82801CA/CAM AC'97 Modem Controller (rev 02)
> > (prog-if 00 [Generic])
> > Flags: bus master, medium devsel, latency 0, IRQ 5
> > 0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon
> > Mobility M7 LW [Radeon Mobility 7500] (prog-if 00 [VGA])
> > Flags: bus master, stepping, fast Back2Back, 66MHz, medium devsel,
> > latency 66, IRQ 11
> > 0000:02:00.0 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus
> > Controller (rev 01)
> > Flags: bus master, medium devsel, latency 168, IRQ 11
> > 0000:02:00.1 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus
> > Controller (rev 01)
> > Flags: bus master, medium devsel, latency 168, IRQ 5
> > 0000:02:08.0 Ethernet controller: Intel Corp. 82801CAM (ICH3) PRO/100 VE
> > (LOM) Ethernet Controller (rev 42)
> > Flags: bus master, medium devsel, latency 66, IRQ 11
>
> All your components share IRQ 5 or IRQ 11. Even worse, your NIC and your
> Radeon share IRQ 11.
> You cant try to disable some components in BIOS. You can also try to
> change the PCI-settings to let them use different interrupts.
>
> I don't know if OSKitMach works better with shared interrupts. Anyone
> who could clarify this?
>
> Patrick