RTL8136

RTL8136

[Darren Salt]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

In case you don't yet have an lspci dump for an RTL8136, here's one for a
device which is working with the r1000 driver which is supplied with Ubuntu
dapper (though the machine in question - a Toshiba Equium A110-233 - is
actually running Debian testing.)

I _should_ be able to test your patches once I've got a locally-compiled
kernel working for it.

[M-F-T set; not subscribed.]

-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + At least 4000 million too many people. POPULATION LEVEL IS UNSUSTAINABLE.

If no one uses it, there's a reason.

[-- Attachment #2: lspci_rtl8136.txt --]
[-- Type: text/plain, Size: 1717 bytes --]

05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. Unknown device 8136 (rev 01)
	Subsystem: Toshiba America Info Systems Unknown device ff00
	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, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 185
	Region 0: I/O ports at 4000 [size=256]
	Region 2: Memory at da000000 (64-bit, non-prefetchable) [size=4K]
	[virtual] Expansion ROM at d4000000 [disabled] [size=64K]
	Capabilities: [40] 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+
	Capabilities: [48] Vital Product Data
	Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [60] Express Endpoint IRQ 0
		Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+
		Device: Latency L0s <1us, L1 unlimited
		Device: AtnBtn+ AtnInd+ PwrInd+
		Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
		Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
		Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
		Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s, Port 0
		Link: Latency L0s unlimited, L1 unlimited
		Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
		Link: Speed 2.5Gb/s, Width x1
	Capabilities: [84] Vendor Specific Information
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [12c] Virtual Channel
	Capabilities: [148] Device Serial Number 36-81-ec-10-00-00-10-01
	Capabilities: [154] Power Budgeting

Re: RTL8136

[Francois Romieu]

Darren Salt <linux@youmustbejoking.demon.co.uk> :
> In case you don't yet have an lspci dump for an RTL8136, here's one for a
> device which is working with the r1000 driver which is supplied with Ubuntu
> dapper (though the machine in question - a Toshiba Equium A110-233 - is
> actually running Debian testing.)

Thanks. The MM region was correctly guessed. If the driver does not work,
you can try to s/RTL_CFG_1/RTL_CFG_2/ for the 0x8136 entry in the
rtl8169_pci_tbl array.

-- 
Ueimor

Re: RTL8136

[Darren Salt]

I demand that Francois Romieu may or may not have written...

> Darren Salt <linux@youmustbejoking.demon.co.uk> :
>> In case you don't yet have an lspci dump for an RTL8136, here's one for a
>> device which is working with the r1000 driver which is supplied with
>> Ubuntu dapper (though the machine in question - a Toshiba Equium A110-233
>> - is actually running Debian testing.)

> Thanks. The MM region was correctly guessed. If the driver does not work,

... which it doesn't - the connection is lost, and the hardware continually
tries and fails to re-establish it. I can at least get a 10baseT/full
connection with help from ethtool, but trying to send anything over it fails;
switching back to r1000 (and forcing the connection speed) gets things
working again, though a reboot seems to be needed to get auto-negotiation of
higher speeds working again (note that it's limited to 100baseT/full; I
have nothing else capable of 1000baseT).

> you can try to s/RTL_CFG_1/RTL_CFG_2/ for the 0x8136 entry in the
> rtl8169_pci_tbl array.

That appears to make no difference.

-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
|   Kill all extremists!

"The universe is a spheroid region 705m in diameter."

Re: RTL8136

[Darren Salt]

I demand that I definitely did write...

> I demand that Francois Romieu may or may not have written...
>> Darren Salt <linux@youmustbejoking.demon.co.uk> :
>>> In case you don't yet have an lspci dump for an RTL8136, here's one for a
>>> device which is working with the r1000 driver which is supplied with
>>> Ubuntu dapper (though the machine in question - a Toshiba Equium A110-233
>>> - is actually running Debian testing.)

>> Thanks. The MM region was correctly guessed. If the driver does not work,

> ... which it doesn't - the connection is lost, and the hardware continually
> tries and fails to re-establish it. [...]

Whoops. I'd not noticed the -rc4 patches...

These seem to help a little: mii-tool can reset it and bring the link up
regardless of RTL_CFG_{1,2}. After that, RTL_CFG_1 allows sending to work,
and RTL_CFG_2 allows both sending and receiving to work (tested by trying to
get an IP address via DHCP).

[snip]
-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Output *more* particulate pollutants.      BUFFER AGAINST GLOBAL WARMING.

"It'll drive the conspiracy nuts crazy, but WTH."

Re: RTL8136

[Francois Romieu]

Darren Salt <linux@youmustbejoking.demon.co.uk> :
[...]
> Whoops. I'd not noticed the -rc4 patches...
> 
> These seem to help a little: mii-tool can reset it and bring the link up
> regardless of RTL_CFG_{1,2}. After that, RTL_CFG_1 allows sending to work,
> and RTL_CFG_2 allows both sending and receiving to work (tested by trying to
> get an IP address via DHCP).

Did you need to play with mii-tool to have DHCP working or did it work
automagically (assuming the -rc4 patches + the RTL_CFG_2 change of course) ?

-- 
Ueimor

Re: RTL8136

[Darren Salt]

I demand that Francois Romieu may or may not have written...

> Darren Salt <linux@youmustbejoking.demon.co.uk> :
> [...]
>> Whoops. I'd not noticed the -rc4 patches...

>> These seem to help a little: mii-tool can reset it and bring the link up
>> regardless of RTL_CFG_{1,2}. After that, RTL_CFG_1 allows sending to work,
>> and RTL_CFG_2 allows both sending and receiving to work (tested by trying
>> to get an IP address via DHCP).

> Did you need to play with mii-tool to have DHCP working or did it work
> automagically (assuming the -rc4 patches + the RTL_CFG_2 change of course)?

The former. Without that, the connection is persistently re-negotiated
(though, according to the switch's LEDs, it's fine before the module is
loaded).

-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
|   Say NO to UK ID cards. http://www.no2id.net/

Experience is something you don't get until just after you need it.

Re: RTL8136

[Francois Romieu]

Darren Salt <linux@youmustbejoking.demon.co.uk> :
[...]
> The former. Without that, the connection is persistently re-negotiated
> (though, according to the switch's LEDs, it's fine before the module is
> loaded).

The state of the LEDs at startup is not necessarily significant (it can
come from the eeprom).

I have regenerated a serie which includes a fix with the correct RTL_CFG_2
at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.18-rc5/r8169 (the git
branch has been updated as well).

Could you use it with mii-tool to collect the state of the mii registers
in the broken state and in the working state ?

-- 
Ueimor

Re: RTL8136

[Darren Salt]

I demand that Francois Romieu may or may not have written...

> Darren Salt <linux@youmustbejoking.demon.co.uk> :
> [...]
>> The former. Without that, the connection is persistently re-negotiated
>> (though, according to the switch's LEDs, it's fine before the module is
>> loaded).

> The state of the LEDs at startup is not necessarily significant (it can
> come from the eeprom).

I'm inclined to believe the switch...

> I have regenerated a serie which includes a fix with the correct RTL_CFG_2
> at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.18-rc5/r8169 (the git
> branch has been updated as well).

Got it.

> Could you use it with mii-tool to collect the state of the mii registers in
> the broken state and in the working state ?

Broken:

eth0: no link
  registers for MII PHY 32: 
    1000 7849 0000 8201 0de1 0000 0000 0000
    0000 0000 0000 0000 0000 0000 0000 0000
    0000 05c0 0000 000f 0000 0000 0000 0000
    0000 0080 0000 0000 0000 0000 0000 0000
  product info: vendor 00:00:20, model 32 rev 1
  basic mode:   autonegotiation enabled
  basic status: no link
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

eth0: no link
  registers for MII PHY 32: 
    3100 7849 0000 8201 0de1 45e0 0001 0000
    0000 0000 0000 0000 0000 0000 0000 0000
    000c 05c0 007a 000f 0000 0000 0000 0000
    0000 00f8 0000 0000 0000 0000 0000 0000
  product info: vendor 00:00:20, model 32 rev 1
  basic mode:   autonegotiation enabled
  basic status: no link
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
  link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control


Working (after "mii-tool -A 10baseT eth0"):

eth0: negotiated 10baseT-FD, link ok
  registers for MII PHY 32: 
    1100 786d 0000 8201 0061 45e1 0001 0000
    0000 0000 0000 0000 0000 0000 0000 0000
    000c 05c0 0000 000f 0000 0000 0000 0000
    0000 0086 0000 0000 0000 0000 0000 0000
  product info: vendor 00:00:20, model 32 rev 1
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  10baseT-FD 10baseT-HD
  link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control


Working (after "mii-tool -R eth0", needed to allow 100baseTx):

eth0: negotiated 100baseTx-FD, link ok
  registers for MII PHY 32: 
    3100 786d 0000 8201 01e1 45e1 0001 0000
    0000 0000 0000 0000 0000 0000 0000 0000
    000c 05c0 0000 0002 0000 0000 0000 0000
    0000 00f9 0000 0000 0000 0000 0000 0000
  product info: vendor 00:00:20, model 32 rev 1
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
|   Say NO to UK ID cards. http://www.no2id.net/

Windows 2000. Known to some as Windows 1900.