SUNGEM config

SUNGEM config

[Christopher Murtagh]

 Ben,

 A while back when the question was asked as to why we should use SUNGEM
instead of BMAC or GMAC, you said something to the affect that it offers
config options. I read through the pdf from the kernel config help and it
mentions a ge.conf file. So, if I got this right, I simply create an
/etc/ge.conf file and this will allow me to force XBaseT and Auto or
forced full/half duplex?

 I've been trying it with my iBook2 and 2.4.18pre8 and so far it works
very well. However, when my iBook is not connected, it keeps on try to
negotiate an eth0 connection (/var/log/messages):

Feb  7 15:42:53 shiva kernel: eth0: switching to forced 10bt
Feb  7 15:43:14 shiva kernel: eth0: switching to forced 100bt
Feb  7 15:43:21 shiva kernel: eth0: switching to forced 10bt
Feb  7 15:43:41 shiva kernel: eth0: switching to forced 100bt

So, it would be nice to turn this off other than turning off
/etc/rc.d/init.d/network.

 Is there a place where I can find docs for this? I tried google searches
for ge.conf linux with not much luck.

 Any enlightenment short of a LART would be much appreciated. :-)

Cheers,

Chris

--

Christopher Murtagh
Webmaster / Sysadmin
Web Communications Group
McGill University
Montreal, Quebec
Canada

Tel.: (514) 398-3122
Fax:  (514) 398-2017

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SUNGEM config

[benh]

>
> Ben,
>
> A while back when the question was asked as to why we should use SUNGEM
>instead of BMAC or GMAC, you said something to the affect that it offers
>config options. I read through the pdf from the kernel config help and it
>mentions a ge.conf file. So, if I got this right, I simply create an
>/etc/ge.conf file and this will allow me to force XBaseT and Auto or
>forced full/half duplex?

I'm not sure what ge.conf is. All I know is that the driver can be
set to various forced speeds via the ethtool tool, the config file
thing depends on whatever software package you have I don't know
about.

> I've been trying it with my iBook2 and 2.4.18pre8 and so far it works
>very well. However, when my iBook is not connected, it keeps on try to
>negotiate an eth0 connection (/var/log/messages):
>
>Feb  7 15:42:53 shiva kernel: eth0: switching to forced 10bt
>Feb  7 15:43:14 shiva kernel: eth0: switching to forced 100bt
>Feb  7 15:43:21 shiva kernel: eth0: switching to forced 10bt
>Feb  7 15:43:41 shiva kernel: eth0: switching to forced 100bt

Yes, that's normal. Some hubs/switches won't properly work with
autoneg, so the kernel has to try forced speeds. The proper way
to turn that off is to shut down the interface using ifconfig
(or /etc/init.d/network).

I know there are some laptop specific tools that monitor the link
and do the shutdown of the interface when there is no link but I
don't have any precise pointer at hand.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SUNGEM config

[Jens Schmalzing]

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

Hi,

> I know there are some laptop specific tools that monitor the link
> and do the shutdown of the interface when there is no link but I
> don't have any precise pointer at hand.

On Debian systems, this is done by a small daemon named ifd in the
laptop-net package.

Unfortunately, it uses the SIOCGMIIPHY and SIOCGMIIREG ioctls for link
detection, which on my Pismo reproducibly lead to machine check
oopses.  I've managed to track down the problem, a patch is included
below.  Basically, instead of really reading the registers it fakes
and returns a register setting from the cached status of the device.
Right now, it is fairly ugly, since it only works for that relevant
one bit.

Regards, Jens.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Patch to SUNGEM driver for GMAC --]
[-- Type: text/x-patch, Size: 662 bytes --]

--- linux-benh/drivers/net/sungem.c	Wed Feb  6 20:01:22 2002
+++ linux/drivers/net/sungem.c	Thu Feb 14 01:37:41 2002
@@ -2553,11 +2540,16 @@
 		break;

 	case SIOCGMIIPHY:		/* Get address of MII PHY in use. */
+	case SIOCDEVPRIVATE:		/* for binary compat, remove in 2.5 */
 		data->phy_id = gp->mii_phy_addr;
 		/* Fallthrough... */

 	case SIOCGMIIREG:		/* Read MII PHY register. */
-		data->val_out = __phy_read(gp, data->reg_num & 0x1f, data->phy_id & 0x1f);
+	case SIOCDEVPRIVATE+1:		/* for binary compat, remove in 2.5 */
+		if(data->reg_num==1 && gp->lstate==link_up)
+			data->val_out = PCS_MIISTAT_LS;
+		else
+			data->val_out = 0;
 		rc = 0;
 		break;

[-- Attachment #3: Type: text/plain, Size: 196 bytes --]


P.S.: I forget whether to include or to attach patches.  My apologies
if I have done it incorrectly.

--
J'qbpbe, le m'en fquz pe j'qbpbe!
Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!

Re: SUNGEM config

[benh]

>On Debian systems, this is done by a small daemon named ifd in the
>laptop-net package.
>
>Unfortunately, it uses the SIOCGMIIPHY and SIOCGMIIREG ioctls for link
>detection, which on my Pismo reproducibly lead to machine check
>oopses.  I've managed to track down the problem, a patch is included
>below.  Basically, instead of really reading the registers it fakes
>and returns a register setting from the cached status of the device.
>Right now, it is fairly ugly, since it only works for that relevant
>one bit.

Can you tell me more about those machine checks ? I suspect they happen
if you try to read the registers while the interface is shutdown, in
which case the GEM chip is down.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SUNGEM config

[Jens Schmalzing]

Hi,

> Can you tell me more about those machine checks ?

I can send you the usual output, it's still in my logs.

> I suspect they happen if you try to read the registers while the
> interface is shutdown, in which case the GEM chip is down.

Precisely.  That's what the ifd daemon does, it polls the device once
every second via that ioctl in order to see whether it is connected or
not.

Regards, Jens.

--
J'qbpbe, le m'en fquz pe j'qbpbe!
Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SUNGEM config

[Benjamin Herrenschmidt]

>
>Precisely.  That's what the ifd daemon does, it polls the device once
>every second via that ioctl in order to see whether it is connected or
>not.

Well, we have a chicken & egg problem then. I shut down the device when
the interface is down for more than about 10 seconds. At that point,
it's isn't possible to get the link state since even the PHY is powered
off. So ifd cannot detect the link up condition. Either I fake the ioctl
and return no link, or I power it back up each time, preventing basically
the chip to ever be power managed.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SUNGEM config

[Jens Schmalzing]

Hi,

> I shut down the device when the interface is down for more than
> about 10 seconds.

> Either I fake the ioctl and return no link,

Which makes ifd useless, because it won't be able to detect that a
link is actually present.

> or I power it back up each time, preventing basically the chip to
> ever be power managed.

Which consumes unnecassary power, reducing battery life.  I see the
point.  Would it make sense to make the time between the link going
down and the device powering off configurable, either as a module
parameter or as a kernel config option?  Then one could choose to have
either sensible power management or automatic link detection, if it's
not possible to get both.

Regards, Jens.

--
J'qbpbe, le m'en fquz pe j'qbpbe!
Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SUNGEM config

[Benjamin Herrenschmidt]

>Which consumes unnecassary power, reducing battery life.  I see the
>point.  Would it make sense to make the time between the link going
>down and the device powering off configurable, either as a module
>parameter or as a kernel config option?  Then one could choose to have
>either sensible power management or automatic link detection, if it's
>not possible to get both.

In that case, there is no need to configure the delay. If we go that
way, I can make sure the device gets powered back up on the ioctls,
those will keep the chip up. So either you use ifd and keep the interface
powered, or you dont. I have to think a bit more about this though.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/