[FC1], 2.6.8-rc2 kernel, new motherboard problems
Gene Heskett
gene.heskett at verizon.net
Thu Jul 22 01:07:44 UTC 2004
On Wednesday 21 July 2004 18:07, Robert Locke wrote:
>On Wed, 2004-07-21 at 14:37, Benjamin J. Weiss wrote:
>> MAC addresses are layer 2, not layer 3. This means that they're
>> used on the same subnet, but don't cross a router. IIRC, MAC
>> addresses don't cross switches either, only hubs or bridges.
>
>Actually, MAC addresses are bounded generally by Layer 3 or higher
>devices. Hubs are multi-port repeaters that some would say operate
> at the physical layer (Layer 1). Bridges and Layer 2 switches
> (aka. multi-port bridges) operate at Layer 2. What the
> "transparent" variety do for us is simply be selective in
> forwarding based on MAC address (though will "flood" broadcasts and
> multicasts), so the MAC address must be unique within that
> "broadcast domain".
>
>Now routers, and Layer 3 switches will strip the MAC header and
> create a new header as the packet is transmitted between "broadcast
> domains" or "subnets", perhaps represented by different "VLANs".
> (Yes I know the high end routers and layer 3 switches might do an
> inline rewrite to speed things up, but....) In reality, the two
> "sides" of the Layer 3 device can actually be different Layer 2
> technologies....
>
>HTH,
>
I see (I think).
I may have made some small progress on this, in the bios I enabled
the onboard LAN, and gave it a MAC address that was a mixture of
the old realtek 8139too's last 3, and one of those unlisted
manufacturer sets for the first 3. From that, and a reboot of
course, I'm now showing this in an
"lspci -vvv|grep Ethernet" for that device:
00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet Controller (rev a1)
Subsystem: Biostar Microtech Int'l Corp: Unknown device 2301
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (250ns min, 5000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at dc004000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at ec00 [size=8]
Capabilities: [44] 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-
--
01:06.0 Ethernet controller: D-Link System Inc RTL8139 Ethernet (rev 10)
Subsystem: D-Link System Inc DFE-530TX+ 10/100 Ethernet 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 (8000ns min, 16000ns max)
Interrupt: pin A routed to IRQ 12
Region 0: I/O ports at c000 [size=256]
Region 1: Memory at db000000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
So basicly its still an unk device and I'm running on the second
listed above. Is this the 'forcedeth' driver that I've seen
discussed on lkml at length, oh, say 6 weeks ago?
If so, should it not be in the kernel tree and selectable in a make xconfig
screen by now? Currently running 2.6.8-rc2 here. But I don't recall seeing
it in the -mm trees either, and I run both as they come out or shortly thereafter.
Am I on the right trail here, or am I getting colder?
>--Rob
--
Cheers Rob, Gene
There are 4 boxes to be used in defense of liberty.
Soap, ballot, jury, and ammo.
Please use in that order, starting now. -Ed Howdershelt, Author
Additions to this message made by Gene Heskett are Copyright 2004,
Maurice E. Heskett, all rights reserved.
More information about the fedora-list
mailing list