Re: wol for xl(4)

2011-07-09 Thread Stefan Sperling 
On Sat, Jul 09, 2011 at 04:54:56PM +0200, Thomas Gerlach wrote:
  hi stefan,
 
  /etc/hostname.xl0:
 
  inet 192.168.0.2 255.255.255.0 192.168.0.255 wol (without )
  
  What happens if you put wol on a separate line, like this?
  
  inet 192.168.0.2 255.255.255.0 192.168.0.255
  wol
 
 ok, i don't know how you got this idea, but it's indeed working!!!
 thanksfor this...easy solution. :D

This means there is a problem with timing somewhere.
I'll try to figure out a fix.

Re: wol for xl(4)

2011-07-09 Thread Henning Brauer 
* Stefan Sperling s...@stsp.name [2011-07-09 17:44]:
 On Sat, Jul 09, 2011 at 04:54:56PM +0200, Thomas Gerlach wrote:
   hi stefan,
   /etc/hostname.xl0:
   inet 192.168.0.2 255.255.255.0 192.168.0.255 wol (without )
   What happens if you put wol on a separate line, like this?
   inet 192.168.0.2 255.255.255.0 192.168.0.255
   wol
  ok, i don't know how you got this idea, but it's indeed working!!!
  thanksfor this...easy solution. :D

that is no solution. it barely qualifies as workaround.

 This means there is a problem

indeed!

 I'll try to figure out a fix.

:)

-- 
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting

Re: wol for xl(4)

2011-07-09 Thread Claudio Jeker 
On Sat, Jul 09, 2011 at 05:41:56PM +0200, Stefan Sperling wrote:
 On Sat, Jul 09, 2011 at 04:54:56PM +0200, Thomas Gerlach wrote:
   hi stefan,
  
   /etc/hostname.xl0:
  
   inet 192.168.0.2 255.255.255.0 192.168.0.255 wol (without )
   
   What happens if you put wol on a separate line, like this?
   
   inet 192.168.0.2 255.255.255.0 192.168.0.255
   wol
  
  ok, i don't know how you got this idea, but it's indeed working!!!
  thanksfor this...easy solution. :D
 
 This means there is a problem with timing somewhere.
 I'll try to figure out a fix.

It could very well be that the wol ioctl is issued before the card is up.
ifconfig is strange when flags are set while configuring address.

-- 
:wq Claudio

Re: wol for xl(4)

2011-07-09 Thread Stefan Sperling 
On Sat, Jul 09, 2011 at 07:57:19PM +0200, Claudio Jeker wrote:
  I'll try to figure out a fix.
 
 It could very well be that the wol ioctl is issued before the card is up.
 ifconfig is strange when flags are set while configuring address.

We must not call xl_wol_power() from xl_stop(). If we do the device
can be set into D3 sleep state at the wrong time.
It's only safe to call xl_wol_power() from xl_activate(). We already
call it for DVACT_QUIESCE, now also call it for DVACT_SUSPEND.
This fixes the 'xl0: transmission error: ff and xl0: command never
completed' lockup issue (which I could reproduce).

Also, the interface needs to be running for WOL to work, so set it up
from within xl_wol() if it's not running yet. This makes a hostname.xl0
file that contains just the keyword wol work correctly, without the
need to up the interface just for WOL. Note that as written this
depends on xl_init() to reselect register window 7 before return,
which it currently does.

ok?

Index: xl.c
===
RCS file: /cvs/src/sys/dev/ic/xl.c,v
retrieving revision 1.103
diff -u -p -r1.103 xl.c
--- xl.c8 Jul 2011 18:56:47 -   1.103
+++ xl.c9 Jul 2011 23:49:00 -
@@ -215,6 +215,9 @@ xl_activate(struct device *self, int act
xl_reset(sc);
xl_stop(sc);
}
+#ifndef SMALL_KERNEL
+   xl_wol_power(sc);
+#endif
rv = config_activate_children(self, act);
break;
case DVACT_RESUME:
@@ -2373,10 +2376,6 @@ xl_stop(struct xl_softc *sc)
ifp-if_flags = ~(IFF_RUNNING | IFF_OACTIVE);
 
xl_freetxrx(sc);
-
-#ifndef SMALL_KERNEL
-   xl_wol_power(sc);
-#endif
 }
 
 #ifndef SMALL_KERNEL
@@ -2708,6 +2707,8 @@ xl_wol(struct ifnet *ifp, int enable)
 
XL_SEL_WIN(7);
if (enable) {
+   if (!(ifp-if_flags  IFF_RUNNING))
+   xl_init(sc);
CSR_WRITE_2(sc, XL_W7_BM_PME, XL_BM_PME_MAGIC);
sc-xl_flags |= XL_FLAG_WOL;
} else {

Re: wol for xl(4)

2011-07-08 Thread Stefan Sperling 
On Mon, Jun 27, 2011 at 09:31:26AM +, Thomas Gerlach wrote:
 Tobias Ulmer tobiasu at tmux.org writes:
 
  
  I've lost track which patches need to be applied or not, but once a
  complete patch appears, I'm willing to test it on a machine that has
  three different xl's.
  
  
 
 
 hi tobias,
 
 sorry for any confusion. i think, the recent patches that should work are the
 following:

After spending some time with xl hardware, I fixed several issues and
got WOL to work even without the tiny WOL cable I thought was required.
It seems to send the signal via the PME pin on the PCI connector.

This diff works fine for me, against -current. Testing and OKs welcome.

Index: ic/xl.c
===
RCS file: /cvs/src/sys/dev/ic/xl.c,v
retrieving revision 1.102
diff -u -p -r1.102 xl.c
--- ic/xl.c 21 Jun 2011 16:52:45 -  1.102
+++ ic/xl.c 8 Jul 2011 12:46:21 -
@@ -193,6 +193,7 @@ void xl_miibus_writereg(struct device *,
 void xl_miibus_statchg(struct device *);
 #ifndef SMALL_KERNEL
 int xl_wol(struct ifnet *, int);
+void xl_wol_power(struct xl_softc *);
 #endif
 
 int
@@ -204,6 +205,9 @@ xl_activate(struct device *self, int act
 
switch (act) {
case DVACT_QUIESCE:
+#ifndef SMALL_KERNEL
+   xl_wol_power(sc);
+#endif
rv = config_activate_children(self, act);
break;
case DVACT_SUSPEND:
@@ -2371,11 +2375,22 @@ xl_stop(struct xl_softc *sc)
xl_freetxrx(sc);
 
 #ifndef SMALL_KERNEL
-   /* Call upper layer WOL power routine if WOL is enabled. */
-   if ((sc-xl_flags  XL_FLAG_WOL)  sc-wol_power)
-   sc-wol_power(sc-wol_power_arg);
+   xl_wol_power(sc);
 #endif
 }
+
+#ifndef SMALL_KERNEL
+void
+xl_wol_power(struct xl_softc *sc)
+{
+   /* Re-enable RX and call upper layer WOL power routine
+* if WOL is enabled. */
+   if ((sc-xl_flags  XL_FLAG_WOL)  sc-wol_power) {
+   CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_RX_ENABLE);
+   sc-wol_power(sc-wol_power_arg);
+   }
+}
+#endif
 
 void
 xl_attach(struct xl_softc *sc)
Index: pci/if_xl_pci.c
===
RCS file: /cvs/src/sys/dev/pci/if_xl_pci.c,v
retrieving revision 1.36
diff -u -p -r1.36 if_xl_pci.c
--- pci/if_xl_pci.c 17 Apr 2011 20:52:43 -  1.36
+++ pci/if_xl_pci.c 8 Jul 2011 12:49:22 -
@@ -273,7 +273,7 @@ xl_pci_attach(struct device *parent, str
 * PCI power state for WOL. It will be invoked when the
 * interface stops and WOL was enabled. */
command = pci_conf_read(pc, pa-pa_tag, XL_PCI_PWRMGMTCAP);
-   if (command  XL_PME_CAP_D3_HOT) {
+   if ((command  16)  XL_PME_CAP_D3_HOT) {
sc-wol_power = xl_pci_wol_power;
sc-wol_power_arg = psc; 
}
@@ -365,13 +365,8 @@ xl_pci_intr_ack(struct xl_softc *sc)
 void
 xl_pci_wol_power(void *ppsc)
 {
-   u_int32_t   command;
struct xl_pci_softc *psc = (struct xl_pci_softc*)ppsc;
 
-   /* Make sure power management is enabled, and set the card into
-* D3hot power state so it stays active after system shutdown. */
-   command = pci_conf_read(psc-psc_pc, psc-psc_tag, XL_PCI_PWRMGMTCTRL);
-   command |= XL_PME_EN | XL_PSTATE_D3;
-   pci_conf_write(psc-psc_pc, psc-psc_tag, XL_PCI_PWRMGMTCTRL, command);
+   pci_set_powerstate(psc-psc_pc, psc-psc_tag, PCI_PMCSR_STATE_D3);
 }
 #endif

Re: wol for xl(4)

2011-07-08 Thread Thomas Gerlach 
On 07/08/2011 02:56 PM, Stefan Sperling wrote:
 On Mon, Jun 27, 2011 at 09:31:26AM +, Thomas Gerlach wrote:
 Tobias Ulmer tobiasu at tmux.org writes:

 I've lost track which patches need to be applied or not, but once a
 complete patch appears, I'm willing to test it on a machine that has
 three different xl's.



 hi tobias,

 sorry for any confusion. i think, the recent patches that should work are the
 following:
 After spending some time with xl hardware, I fixed several issues and
 got WOL to work even without the tiny WOL cable I thought was required.
 It seems to send the signal via the PME pin on the PCI connector.

 This diff works fine for me, against -current. Testing and OKs welcome.

 Index: ic/xl.c
 ===
 RCS file: /cvs/src/sys/dev/ic/xl.c,v
 retrieving revision 1.102
 diff -u -p -r1.102 xl.c
 --- ic/xl.c   21 Jun 2011 16:52:45 -  1.102
 +++ ic/xl.c   8 Jul 2011 12:46:21 -
 @@ -193,6 +193,7 @@ void xl_miibus_writereg(struct device *,
  void xl_miibus_statchg(struct device *);
  #ifndef SMALL_KERNEL
  int xl_wol(struct ifnet *, int);
 +void xl_wol_power(struct xl_softc *);
  #endif
  
  int
 @@ -204,6 +205,9 @@ xl_activate(struct device *self, int act
  
   switch (act) {
   case DVACT_QUIESCE:
 +#ifndef SMALL_KERNEL
 + xl_wol_power(sc);
 +#endif
   rv = config_activate_children(self, act);
   break;
   case DVACT_SUSPEND:
 @@ -2371,11 +2375,22 @@ xl_stop(struct xl_softc *sc)
   xl_freetxrx(sc);
  
  #ifndef SMALL_KERNEL
 - /* Call upper layer WOL power routine if WOL is enabled. */
 - if ((sc-xl_flags  XL_FLAG_WOL)  sc-wol_power)
 - sc-wol_power(sc-wol_power_arg);
 + xl_wol_power(sc);
  #endif
  }
 +
 +#ifndef SMALL_KERNEL
 +void
 +xl_wol_power(struct xl_softc *sc)
 +{
 + /* Re-enable RX and call upper layer WOL power routine
 +  * if WOL is enabled. */
 + if ((sc-xl_flags  XL_FLAG_WOL)  sc-wol_power) {
 + CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_RX_ENABLE);
 + sc-wol_power(sc-wol_power_arg);
 + }
 +}
 +#endif
  
  void
  xl_attach(struct xl_softc *sc)
 Index: pci/if_xl_pci.c
 ===
 RCS file: /cvs/src/sys/dev/pci/if_xl_pci.c,v
 retrieving revision 1.36
 diff -u -p -r1.36 if_xl_pci.c
 --- pci/if_xl_pci.c   17 Apr 2011 20:52:43 -  1.36
 +++ pci/if_xl_pci.c   8 Jul 2011 12:49:22 -
 @@ -273,7 +273,7 @@ xl_pci_attach(struct device *parent, str
* PCI power state for WOL. It will be invoked when the
* interface stops and WOL was enabled. */
   command = pci_conf_read(pc, pa-pa_tag, XL_PCI_PWRMGMTCAP);
 - if (command  XL_PME_CAP_D3_HOT) {
 + if ((command  16)  XL_PME_CAP_D3_HOT) {
   sc-wol_power = xl_pci_wol_power;
   sc-wol_power_arg = psc; 
   }
 @@ -365,13 +365,8 @@ xl_pci_intr_ack(struct xl_softc *sc)
  void
  xl_pci_wol_power(void *ppsc)
  {
 - u_int32_t   command;
   struct xl_pci_softc *psc = (struct xl_pci_softc*)ppsc;
  
 - /* Make sure power management is enabled, and set the card into
 -  * D3hot power state so it stays active after system shutdown. */
 - command = pci_conf_read(psc-psc_pc, psc-psc_tag, XL_PCI_PWRMGMTCTRL);
 - command |= XL_PME_EN | XL_PSTATE_D3;
 - pci_conf_write(psc-psc_pc, psc-psc_tag, XL_PCI_PWRMGMTCTRL, command);
 + pci_set_powerstate(psc-psc_pc, psc-psc_tag, PCI_PMCSR_STATE_D3);
  }
  #endif



hi stefan,

nice work! i can confirm it working on my box. :)
haven't spend any thoughts on it for quite a time, since it also worked
with your previous patches. but this seems more like the linux way,
using pci_set_powerstate.

however, there's still the following problem:
if wol is enabled via /etc/hostname.xl0 (by adding the wol keyword),
it's not possible to log into the system, since the error messages xl0:
transmission error: ff and xl0: command never completed are thrown
out all the time.

a workaround to enable wol during startup is using /etc/rc.local by
adding the line ifconfig xl0 wol.

anyway, thanks again for this quite nice solution. :)


cheers,

thomas

Re: wol for xl(4)

2011-07-08 Thread Stefan Sperling 
On Fri, Jul 08, 2011 at 11:18:59PM +0200, Thomas Gerlach wrote:
 however, there's still the following problem:
 if wol is enabled via /etc/hostname.xl0 (by adding the wol keyword),
 it's not possible to log into the system, since the error messages xl0:
 transmission error: ff and xl0: command never completed are thrown
 out all the time.

Hmmm...
What does your hostname.xl0 look like?
What does dmesg | grep xl0 print on your system?

Re: wol for xl(4)

2011-06-27 Thread Thomas Gerlach 
Tobias Ulmer tobiasu at tmux.org writes:

 
 I've lost track which patches need to be applied or not, but once a
 complete patch appears, I'm willing to test it on a machine that has
 three different xl's.
 
 


hi tobias,

sorry for any confusion. i think, the recent patches that should work are the
following:

Index: ic/xl.c
===
RCS file: /cvs/src/sys/dev/ic/xl.c,v
retrieving revision 1.101
diff -u -p -r1.101 xl.c
--- ic/xl.c 17 Apr 2011 20:52:43 - 1.101
+++ ic/xl.c 17 Jun 2011 21:38:21 -
@@ -2373,9 +2373,13 @@ xl_stop(struct xl_softc *sc)
  xl_freetxrx(sc);
 
 #ifndef SMALL_KERNEL
- /* Call upper layer WOL power routine if WOL is enabled. */
- if ((sc-xl_flags  XL_FLAG_WOL)  sc-wol_power)
+ /* Re-enable RX and call upper layer WOL power routine
+ * if WOL is enabled. */
+ if ((sc-xl_flags  XL_FLAG_WOL)  sc-wol_power) {
+ CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_RX_ENABLE);
+ xl_wait(sc);
  sc-wol_power(sc-wol_power_arg);
+ }
 #endif
 }
 
@@ -2694,6 +2698,10 @@ xl_wol(struct ifnet *ifp, int enable)
  struct xl_softc *sc = ifp-if_softc;
 
  XL_SEL_WIN(7);
+
+ /* Clear any pending PME events. */
+ CSR_READ_2(sc, XL_W7_BM_PME);
+
  if (enable) {
  CSR_WRITE_2(sc, XL_W7_BM_PME, XL_BM_PME_MAGIC);
  sc-xl_flags |= XL_FLAG_WOL;

Index: pci/if_xl_pci.c
===
RCS file: /cvs/src/sys/dev/pci/if_xl_pci.c,v
retrieving revision 1.36
diff -u -p -r1.36 if_xl_pci.c
--- pci/if_xl_pci.c 17 Apr 2011 20:52:43 - 1.36
+++ pci/if_xl_pci.c 17 Jun 2011 21:33:35 -
@@ -266,18 +266,6 @@ xl_pci_attach(struct device *parent, str
  pci_conf_write(pc, pa-pa_tag, XL_PCI_LOMEM, mem);
  pci_conf_write(pc, pa-pa_tag, XL_PCI_INTLINE, irq);
  }
-
-#ifndef SMALL_KERNEL
- /* The card is WOL-capable if it supports PME# assertion
- * from D3hot power state. Install a callback to configure
- * PCI power state for WOL. It will be invoked when the
- * interface stops and WOL was enabled. */
- command = pci_conf_read(pc, pa-pa_tag, XL_PCI_PWRMGMTCAP);
- if (command  XL_PME_CAP_D3_HOT) {
- sc-wol_power = xl_pci_wol_power;
- sc-wol_power_arg = psc;
- }
-#endif
  }
 
  /*
@@ -335,6 +323,16 @@ xl_pci_attach(struct device *parent, str
  printf(: %s, intrstr);
 
  xl_attach(sc);
+
+#ifndef SMALL_KERNEL
+ /* If the card is WOL-capable install a callback to configure
+ * PCI power state for WOL. It will be invoked when the
+ * interface stops and WOL was enabled. */
+ if (sc-xl_caps  XL_CAPS_PWRMGMT) {
+ sc-wol_power = xl_pci_wol_power;
+ sc-wol_power_arg = psc;
+ }
+#endif
 }
 
 int

Re: wol for xl(4)

2011-06-25 Thread Tobias Ulmer 
On Fri, Jun 24, 2011 at 06:06:58PM +0200, Thomas Gerlach wrote:
[..]
 this successfully enables wol during startup, without any error messages
 (assuming the patches from stefan are applied, of course).
 
 cheers,
 
 thomas


I've lost track which patches need to be applied or not, but once a
complete patch appears, I'm willing to test it on a machine that has
three different xl's.

Re: wol for xl(4)

2011-06-24 Thread Thomas Gerlach 
On 06/22/2011 03:15 PM, Stefan Sperling wrote:
 On Wed, Jun 22, 2011 at 11:43:27AM +, Thomas Gerlach wrote:
 ...crap! sorry, something went wrong here. :(
 
 I'm not sure what you mean went wrong.
 
 But in an effort to try to wrap this up, can you please try -current
 with just this diff and report back if that works? Thanks!
 
 Index: xl.c
 ===
 RCS file: /cvs/src/sys/dev/ic/xl.c,v
 retrieving revision 1.101
 diff -u -p -r1.101 xl.c
 --- xl.c  17 Apr 2011 20:52:43 -  1.101
 +++ xl.c  22 Jun 2011 13:10:24 -
 @@ -2373,9 +2373,13 @@ xl_stop(struct xl_softc *sc)
   xl_freetxrx(sc);
  
  #ifndef SMALL_KERNEL
 - /* Call upper layer WOL power routine if WOL is enabled. */
 - if ((sc-xl_flags  XL_FLAG_WOL)  sc-wol_power)
 + /* Re-enable RX and call upper layer WOL power routine
 +  * if WOL is enabled. */
 + if ((sc-xl_flags  XL_FLAG_WOL)  sc-wol_power) {
 + CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_RX_ENABLE);
 + xl_wait(sc);
   sc-wol_power(sc-wol_power_arg);
 + }
  #endif
  }
  


hi

for now i managed to solve the problem by adding the following line to
/etc/rc.local:

ifconfig if wol

instead of using /etc/hostname.if to enable wol.


this successfully enables wol during startup, without any error messages
(assuming the patches from stefan are applied, of course).

cheers,

thomas

Re: wol for xl(4)

2011-06-22 Thread Thomas Gerlach 
For me it works as well. :)

Just two more little flaws:

1) If you configure WOL inside /etc/hostname.if, then you get the following
error message during booting:

xl0: command never completed!
xl0: transmission error: ff

and you're not able to login. the problem is:
xl_init is called first, which makes a call to xl_stop. and xl_stop calls
xl_pci_power, which tries to bring the IF into D3 powerstate. more precisely,
the pci_conf_write routine is not able to set the XL_PSTATE_D3 bit (however,
it can set the XL_PME_ENABLE bit. i checked by setting just one of them.)

the initial disable mechanism of xl_attach doesn't work, since xl_init is
called _before_ xl_attach.

2) it would be nice if we push the wol setting stuff inside ONE routine, rather
than spreading it over several ones (that is, all the CSR_WRITE stuff together
into xl_pci_power.

i'm currently working on it...but maybe, stefan might be faster than me again
(if he wants to...). ;)

cheers

Re: wol for xl(4)

2011-06-22 Thread Thomas Gerlach 
as for the pulling toghether, i would suggest something like this (draft,
patches against latest -current files, _without_ stefan's recent patches):

# diff -u xl.c.orig xl.c  xl.c.patch1

--- xl.c.orig   Sun Apr 17 22:52:43 2011
+++ xl.cWed Jun 22 11:53:45 2011
@@ -2373,8 +2373,9 @@
xl_freetxrx(sc);
 
 #ifndef SMALL_KERNEL
-   /* Call upper layer WOL power routine if WOL is enabled. */
-   if ((sc-xl_flags  XL_FLAG_WOL)  sc-wol_power)
+   /* Re-enable RX and call upper layer WOL power routine
+* if WOL power callback is registered. */
+   if (sc-wol_power)
sc-wol_power(sc-wol_power_arg);
 #endif
 }
@@ -2646,6 +2647,7 @@
CSR_WRITE_2(sc, XL_W0_MFG_ID, XL_NO_XCVR_PWR_MAGICBITS);
}
 
+#if 1
 #ifndef SMALL_KERNEL
/* Check availability of WOL. */
if ((sc-xl_caps  XL_CAPS_PWRMGMT) != 0) {
@@ -2654,6 +2656,7 @@
xl_wol(ifp, 0);
}
 #endif
+#endif
 
/*
 * Call MI attach routines.
@@ -2693,12 +2696,9 @@
 {
struct xl_softc *sc = ifp-if_softc;
 
-   XL_SEL_WIN(7);
if (enable) {
-   CSR_WRITE_2(sc, XL_W7_BM_PME, XL_BM_PME_MAGIC);
sc-xl_flags |= XL_FLAG_WOL;
} else {
-   CSR_WRITE_2(sc, XL_W7_BM_PME, 0);
sc-xl_flags = ~XL_FLAG_WOL;
}
return (0); 


# diff -u if_xl_pci.c.orig if_xl_pci.c  if_xl_pci.c.patch1

--- if_xl_pci.c.origSun Apr 17 22:52:43 2011
+++ if_xl_pci.c Wed Jun 22 11:53:06 2011
@@ -266,18 +266,6 @@
pci_conf_write(pc, pa-pa_tag, XL_PCI_LOMEM, mem);
pci_conf_write(pc, pa-pa_tag, XL_PCI_INTLINE, irq);
}
-
-#ifndef SMALL_KERNEL
-   /* The card is WOL-capable if it supports PME# assertion
-* from D3hot power state. Install a callback to configure
-* PCI power state for WOL. It will be invoked when the
-* interface stops and WOL was enabled. */
-   command = pci_conf_read(pc, pa-pa_tag, XL_PCI_PWRMGMTCAP);
-   if (command  XL_PME_CAP_D3_HOT) {
-   sc-wol_power = xl_pci_wol_power;
-   sc-wol_power_arg = psc; 
-   }
-#endif
}
 
/*
@@ -335,6 +323,16 @@
printf(: %s, intrstr);
 
xl_attach(sc);
+
+#ifndef SMALL_KERNEL
+   /* If the card is WOL-capable install a callback to configure
+* PCI power state for WOL. It will be invoked when the
+* interface stops and WOL was enabled. */
+   if (sc-xl_caps  XL_CAPS_PWRMGMT) {
+   sc-wol_power = xl_pci_wol_power;
+   sc-wol_power_arg = psc; 
+   }
+#endif
 }
 
 int
@@ -367,6 +365,22 @@
 {
u_int32_t   command;
struct xl_pci_softc *psc = (struct xl_pci_softc*)ppsc;
+   struct xl_softc *sc = psc-psc_softc;
+
+   XL_SEL_WIN(7);
+
+   /* Clear any pending PME events. */
+   CSR_READ_2(sc, XL_W7_BM_PME);
+
+   /* If WOL flag is not set make sure PME is disabled, and
+* return without doing anything. */
+   if ((sc-xl_flags  XL_FLAG_WOL) == 0) {
+   CSR_WRITE_2(sc, XL_W7_BM_PME, 0);
+   return;
+   }
+
+   CSR_WRITE_2(sc, XL_W7_BM_PME, XL_BM_PME_MAGIC);
+   CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_RX_ENABLE);
 
/* Make sure power management is enabled, and set the card into
 * D3hot power state so it stays active after system shutdown. */

Re: wol for xl(4)

2011-06-22 Thread Stefan Sperling 
On Wed, Jun 22, 2011 at 09:54:07AM +, Thomas Gerlach wrote:
 For me it works as well. :)
 
 Just two more little flaws:
 
 1) If you configure WOL inside /etc/hostname.if, then you get the following
 error message during booting:
 
 xl0: command never completed!
 xl0: transmission error: ff
 
 and you're not able to login. the problem is:
 xl_init is called first, which makes a call to xl_stop. and xl_stop 
 calls
 xl_pci_power, which tries to bring the IF into D3 powerstate. more 
 precisely,
 the pci_conf_write routine is not able to set the XL_PSTATE_D3 bit (however,
 it can set the XL_PME_ENABLE bit. i checked by setting just one of them.)
 
 the initial disable mechanism of xl_attach doesn't work, since xl_init is
 called _before_ xl_attach.

Can you please clarify with which code exactly you're seeing this problem?
What are you running?
Does it happens with the if_xl_pci.c hunk of my proposed diff, or without it?
Or does it always happen even in plain -current?
 
 2) it would be nice if we push the wol setting stuff inside ONE routine, 
 rather
 than spreading it over several ones (that is, all the CSR_WRITE stuff together
 into xl_pci_power.
 
 i'm currently working on it...but maybe, stefan might be faster than me again
 (if he wants to...). ;)

This doesn't sound like a good idea.
The PCI-specific layer of XL and the low-level layer in ic/ have to
cooperate. Else you'd have to call PCI-specific routines from the code
in ic/ which harms use of this driver with other buses.

Re: wol for xl(4)

2011-06-22 Thread Stefan Sperling 
On Wed, Jun 22, 2011 at 10:02:42AM +, Thomas Gerlach wrote:
 as for the pulling toghether, i would suggest something like this (draft,
 patches against latest -current files, _without_ stefan's recent patches):

 +#if 1
  #ifndef SMALL_KERNEL

  #endif
 +#endif

Huh?

 @@ -367,6 +365,22 @@
  {
 u_int32_t   command;
 struct xl_pci_softc *psc = (struct xl_pci_softc*)ppsc;
 +   struct xl_softc *sc = psc-psc_softc;
 +
 +   XL_SEL_WIN(7);
 +
 +   /* Clear any pending PME events. */
 +   CSR_READ_2(sc, XL_W7_BM_PME);
 +
 +   /* If WOL flag is not set make sure PME is disabled, and
 +* return without doing anything. */
 +   if ((sc-xl_flags  XL_FLAG_WOL) == 0) {
 +   CSR_WRITE_2(sc, XL_W7_BM_PME, 0);
 +   return;
 +   }
 +
 +   CSR_WRITE_2(sc, XL_W7_BM_PME, XL_BM_PME_MAGIC);
 +   CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_RX_ENABLE);

I see what you mean now but I don't know if putting these register
writes into the PCI glue code is appropriate.

Re: wol for xl(4)

2011-06-22 Thread Thomas Gerlach 
Stefan Sperling stsp at stsp.name writes:

 
 Can you please clarify with which code exactly you're seeing this problem?
 What are you running?
 Does it happens with the if_xl_pci.c hunk of my proposed diff, or without it?
 Or does it always happen even in plain -current?
 

ok, of course.
1) everything works fine with your latest patches, if i manually do an
ifconfig xl0 wol.

2) now i'd like to set the interface stuff in /etc/hostname.xl0. therefore,
i go with inet 192.168.0.2 255.255.255.0 192.168.0.255 wol.
(re)booting then results in those error messages i presented before

now what i found out so far is, that the problem seems to be with the
pci_conf_write call inside xl_pci_power in if_xl_pci.c
both the XL_PME_EN and XL_PSTATE_D3 state are to be set. i narrowed it down to
that call by try and error. so when you disable pci_conf_write, the error
disappears (of course no WOL then).
the problem is setting the XL_PSTATE_D3 bit.

it think, the error appears, because xl_stop is called inside xl_init
(both in xl.c). and xl_init is called _before_ xl_attach inside
xl_pci_attach (if_xl_pci.c), so the xl_wol(ifp, 0) of xl_attach call to
clear WOL flag doesn't work. somehow, this flag is set, and that's why it goes
down all the chain and pci_conf_write is called. however, since the system is
trying to bring the IF up, there's a conflict b/w bringing up and D3 power
state.
at least that's what i think...

the error appears with your patches only. that is, because -current
(checkout from yesterday) still has

if_xl_pci.c:

 command = pci_conf_read(pc, pa-pa_tag, XL_PCI_PWRMGMTCAP);
 if (command  XL_PME_CAP_D3_HOT) {
   sc-wol_power = xl_pci_wol_power;
   sc-wol_power_arg = psc; 
 }

so it never comes to register xl_pci_wol_power.


 This doesn't sound like a good idea.
 The PCI-specific layer of XL and the low-level layer in ic/ have to
 cooperate. Else you'd have to call PCI-specific routines from the code
 in ic/ which harms use of this driver with other buses.
 
 

i see your point. just got the idea from FreeBSD, it seems less confusing. :)

hope, this clears up the problem i see?


cheers

Re: wol for xl(4)

2011-06-22 Thread t . m . gerlach 
 -

 

 On Wed, Jun 22, 2011 at 10:02:42AM +, Thomas Gerlach
wrote:

  as for the pulling toghether, i would suggest something like
this

 (draft,

  patches against latest -current files, _without_ stefan's
recent

 patches):

 

  +#if 1

   #ifndef SMALL_KERNEL

 

 
#endif

  +#endif

 

 Huh?



 that results from some testing. it's just
a draft, so i forgot to delete this...



  

  @@ -367,6 +365,22 @@

 
{

  u_int32_t   command;

  struct xl_pci_softc *psc
= (struct xl_pci_softc*)ppsc;

  +   struct xl_softc *sc =
amp;psc-psc_softc;

  +

  +   XL_SEL_WIN(7);

  +

  +   /*
Clear any pending PME events. */

  +   CSR_READ_2(sc, XL_W7_BM_PME);


 +

  +   /* If WOL flag is not set make sure PME is disabled, and

 
+* return without doing anything. */

  +   if ((sc-xl_flags
amp; XL_FLAG_WOL) == 0) {

  +   CSR_WRITE_2(sc, XL_W7_BM_PME,
0);

  +   return;

  +   }

  +

  +
CSR_WRITE_2(sc, XL_W7_BM_PME, XL_BM_PME_MAGIC);

  +   CSR_WRITE_2(sc,
XL_COMMAND, XL_CMD_RX_ENABLE);

 

 I see what you mean now but I don't know
if putting these register

 writes into the PCI glue code is appropriate.
...or we can just put it into the low level code? i mean, the power  routine
should only be registered, if power mgmt caps exist...

 ok, but the pci_conf
write is not low level. so maybe we just do it your way. :)







---
Nutzen
Sie freenet Mail optimal angepasst f|r Ihr iPhone, Android oder Nokia Handy
auch von unterwegs.
Alle Infos und Download unter
http://mail.freenet.de/mobile-email/index.html

Re: wol for xl(4)

2011-06-22 Thread Thomas Gerlach 
...crap! sorry, something went wrong here. :(

Re: wol for xl(4)

2011-06-22 Thread Stefan Sperling 
On Wed, Jun 22, 2011 at 11:43:27AM +, Thomas Gerlach wrote:
 ...crap! sorry, something went wrong here. :(

I'm not sure what you mean went wrong.

But in an effort to try to wrap this up, can you please try -current
with just this diff and report back if that works? Thanks!

Index: xl.c
===
RCS file: /cvs/src/sys/dev/ic/xl.c,v
retrieving revision 1.101
diff -u -p -r1.101 xl.c
--- xl.c17 Apr 2011 20:52:43 -  1.101
+++ xl.c22 Jun 2011 13:10:24 -
@@ -2373,9 +2373,13 @@ xl_stop(struct xl_softc *sc)
xl_freetxrx(sc);
 
 #ifndef SMALL_KERNEL
-   /* Call upper layer WOL power routine if WOL is enabled. */
-   if ((sc-xl_flags  XL_FLAG_WOL)  sc-wol_power)
+   /* Re-enable RX and call upper layer WOL power routine
+* if WOL is enabled. */
+   if ((sc-xl_flags  XL_FLAG_WOL)  sc-wol_power) {
+   CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_RX_ENABLE);
+   xl_wait(sc);
sc-wol_power(sc-wol_power_arg);
+   }
 #endif
 }

Re: wol for xl(4)

2011-06-22 Thread Thomas Gerlach 
Stefan Sperling stsp at stsp.name writes:

 
 On Wed, Jun 22, 2011 at 11:43:27AM +, Thomas Gerlach wrote:
  ...crap! sorry, something went wrong here. :(
 
 I'm not sure what you mean went wrong.
 
 But in an effort to try to wrap this up, can you please try -current
 with just this diff and report back if that works? Thanks!
 
 Index: xl.c
 ===
 RCS file: /cvs/src/sys/dev/ic/xl.c,v
 retrieving revision 1.101
 diff -u -p -r1.101 xl.c
 --- xl.c  17 Apr 2011 20:52:43 -  1.101
 +++ xl.c  22 Jun 2011 13:10:24 -
 @@ -2373,9 +2373,13 @@ xl_stop(struct xl_softc *sc)
   xl_freetxrx(sc);
 
  #ifndef SMALL_KERNEL
 - /* Call upper layer WOL power routine if WOL is enabled. */
 - if ((sc-xl_flags  XL_FLAG_WOL)  sc-wol_power)
 + /* Re-enable RX and call upper layer WOL power routine
 +  * if WOL is enabled. */
 + if ((sc-xl_flags  XL_FLAG_WOL)  sc-wol_power) {
 + CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_RX_ENABLE);
 + xl_wait(sc);
   sc-wol_power(sc-wol_power_arg);
 + }
  #endif
  }
 
 


my email-client had a problm with sending the mail. it looked very crappy, i
guess. had nothing to do with the driver...

ok, i will test your patch, likely not before tomorrow morning.
but i guess, -current with only this patch won't enable WOL at all. as i
mentioned before, -current still has the test on XL_PME_CAP_D3_HOT in order
to register xl_pci_wol_power in file if_xl_pci.c. only your latest patch
tests on XL_CAPS_PWRMGMT.

but i will give it a shot, using both test versions. :)

Re: wol for xl(4)

2011-06-22 Thread Thomas Gerlach 
 Stefan Sperling stsp at stsp.name writes:
  Index: xl.c
  ===
  RCS file: /cvs/src/sys/dev/ic/xl.c,v
  retrieving revision 1.101
  diff -u -p -r1.101 xl.c
  --- xl.c17 Apr 2011 20:52:43 -  1.101
  +++ xl.c22 Jun 2011 13:10:24 -
  @@ -2373,9 +2373,13 @@ xl_stop(struct xl_softc *sc)
  xl_freetxrx(sc);
  
   #ifndef SMALL_KERNEL
  -   /* Call upper layer WOL power routine if WOL is enabled. */
  -   if ((sc-xl_flags  XL_FLAG_WOL)  sc-wol_power)
  +   /* Re-enable RX and call upper layer WOL power routine
  +* if WOL is enabled. */
  +   if ((sc-xl_flags  XL_FLAG_WOL)  sc-wol_power) {
  +   CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_RX_ENABLE);
  +   xl_wait(sc);
  sc-wol_power(sc-wol_power_arg);
  +   }
   #endif
   }
  
  

ok, i had to try...and it happens as i expected:

1) applying only the patch listed above, to -current, wol won't work, since
xl_pci_wol_power is not registered.

2) applying the patch to if_xl_pci.c you send me last weekend (with testing on
the XL_PME_CAPS_PWRMGMT bit), xl_pci_wol_power is registered, but the error
messages appear during the boot process...
of course only when adding wol keyword to /etc/hostname.xl0


regards...

Re: wol for xl(4)

2011-06-19 Thread Thomas Gerlach 
Richard Toohey richardtoohey at paradise.net.nz writes:

 
 On 17/06/2011, at 8:40 PM, Thomas Gerlach wrote:
 
  hello,
 
  i just confirmed wol is working with freebsd 8.2 standard installation on
 my
  box. So it must be the openbsd xl driver, which isn't working properly.
  i will try to fix it starting next week. :)
 
 
  cheers,
 
  thomas
 
 Hi, Thomas.
 
 This is the same point I reached with Stefan.
 
 http://marc.info/?l=openbsd-techm=130337513320970w=2
 
 I didn't have the coding smarts to progress any further ...
 
 Thanks.
 
 

hey guys,

i just had a look into the driver again, and i was able to get wol working now.
:)

basically, the missing point was to enable RX again. it is disabled in the
xl_stop routine (xl.c).
right now it's just a quick hack, and i will provide you with the patches, so
you can test it on your box.

i will attach them asap.


cheers,

thomas

Re: wol for xl(4)

2011-06-19 Thread Stefan Sperling 
On Sun, Jun 19, 2011 at 08:14:11PM +, Thomas Gerlach wrote:
 hey guys,
 
 i just had a look into the driver again, and i was able to get wol working 
 now.
 :)
 
 basically, the missing point was to enable RX again. it is disabled in the
 xl_stop routine (xl.c).
 right now it's just a quick hack, and i will provide you with the patches, so
 you can test it on your box.
 
 i will attach them asap.
 
 
 cheers,
 
 thomas

Didn't you see this patch I mailed you yesterday for testing? :)

Index: ic/xl.c
===
RCS file: /cvs/src/sys/dev/ic/xl.c,v
retrieving revision 1.101
diff -u -p -r1.101 xl.c
--- ic/xl.c 17 Apr 2011 20:52:43 -  1.101
+++ ic/xl.c 17 Jun 2011 21:38:21 -
@@ -2373,9 +2373,13 @@ xl_stop(struct xl_softc *sc)
xl_freetxrx(sc);
 
 #ifndef SMALL_KERNEL
-   /* Call upper layer WOL power routine if WOL is enabled. */
-   if ((sc-xl_flags  XL_FLAG_WOL)  sc-wol_power)
+   /* Re-enable RX and call upper layer WOL power routine
+* if WOL is enabled. */
+   if ((sc-xl_flags  XL_FLAG_WOL)  sc-wol_power) {
+   CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_RX_ENABLE);
+   xl_wait(sc);
sc-wol_power(sc-wol_power_arg);
+   }
 #endif
 }
 
@@ -2694,6 +2698,10 @@ xl_wol(struct ifnet *ifp, int enable)
struct xl_softc *sc = ifp-if_softc;
 
XL_SEL_WIN(7);
+
+   /* Clear any pending PME events. */
+   CSR_READ_2(sc, XL_W7_BM_PME);
+
if (enable) {
CSR_WRITE_2(sc, XL_W7_BM_PME, XL_BM_PME_MAGIC);
sc-xl_flags |= XL_FLAG_WOL;
Index: pci/if_xl_pci.c
===
RCS file: /cvs/src/sys/dev/pci/if_xl_pci.c,v
retrieving revision 1.36
diff -u -p -r1.36 if_xl_pci.c
--- pci/if_xl_pci.c 17 Apr 2011 20:52:43 -  1.36
+++ pci/if_xl_pci.c 17 Jun 2011 21:33:35 -
@@ -266,18 +266,6 @@ xl_pci_attach(struct device *parent, str
pci_conf_write(pc, pa-pa_tag, XL_PCI_LOMEM, mem);
pci_conf_write(pc, pa-pa_tag, XL_PCI_INTLINE, irq);
}
-
-#ifndef SMALL_KERNEL
-   /* The card is WOL-capable if it supports PME# assertion
-* from D3hot power state. Install a callback to configure
-* PCI power state for WOL. It will be invoked when the
-* interface stops and WOL was enabled. */
-   command = pci_conf_read(pc, pa-pa_tag, XL_PCI_PWRMGMTCAP);
-   if (command  XL_PME_CAP_D3_HOT) {
-   sc-wol_power = xl_pci_wol_power;
-   sc-wol_power_arg = psc; 
-   }
-#endif
}
 
/*
@@ -335,6 +323,16 @@ xl_pci_attach(struct device *parent, str
printf(: %s, intrstr);
 
xl_attach(sc);
+
+#ifndef SMALL_KERNEL
+   /* If the card is WOL-capable install a callback to configure
+* PCI power state for WOL. It will be invoked when the
+* interface stops and WOL was enabled. */
+   if (sc-xl_caps  XL_CAPS_PWRMGMT) {
+   sc-wol_power = xl_pci_wol_power;
+   sc-wol_power_arg = psc; 
+   }
+#endif
 }
 
 int

Re: wol for xl(4)

2011-06-19 Thread Thomas Gerlach 
Stefan Sperling stsp at stsp.name writes:

hi stefan,

oh, sorry, no. i just got back from the german southside festival this evening.
should explain why i missed it... ;)

seems you came to the same conclusion. fine. :) so i will test it then...

Re: wol for xl(4)

2011-06-19 Thread Stefan Sperling 
On Sun, Jun 19, 2011 at 08:55:17PM +, Thomas Gerlach wrote:
 Stefan Sperling stsp at stsp.name writes:
 
 hi stefan,
 
 oh, sorry, no. i just got back from the german southside festival this 
 evening.
 should explain why i missed it... ;)
 
 seems you came to the same conclusion. fine. :) so i will test it then...

It would be interesting to know if just the first hunk, which
re-enables RX, is enough.

I don't have working xl wol hardware, so what I did was compare
our driver to the FreeBSD driver taking blind guesses as to what
could be wrong.

So the diff I sent may be larger than needed.
If you could help trim down the diff to the absolute minimum needed
based on testing with hardware that would be great. Cheers!

Re: wol for xl(4)

2011-06-19 Thread Thomas Gerlach 
Stefan Sperling stsp at stsp.name writes:

 It would be interesting to know if just the first hunk, which
 re-enables RX, is enough.
 
 I don't have working xl wol hardware, so what I did was compare
 our driver to the FreeBSD driver taking blind guesses as to what
 could be wrong.
 
 So the diff I sent may be larger than needed.
 If you could help trim down the diff to the absolute minimum needed
 based on testing with hardware that would be great. Cheers!
 
 

I did exactly the same, I compared it to the FreeBSD driver. And I also
cleared the PME events by using CSR_READ_2. I think we're on the safe side if
we keep it.

Maybe we can omit the xl_wait(sc) calls, at least I don't see it in the
FreeBSD driver.


Regards...

Re: wol for xl(4)

2011-06-17 Thread Thomas Gerlach 
hello,

i just confirmed wol is working with freebsd 8.2 standard installation on my
box. So it must be the openbsd xl driver, which isn't working properly.
i will try to fix it starting next week. :)


cheers,

thomas

Re: wol for xl(4)

2011-06-17 Thread Richard Toohey 
On 17/06/2011, at 8:40 PM, Thomas Gerlach wrote:

 hello,

 i just confirmed wol is working with freebsd 8.2 standard installation on
my
 box. So it must be the openbsd xl driver, which isn't working properly.
 i will try to fix it starting next week. :)


 cheers,

 thomas

Hi, Thomas.

This is the same point I reached with Stefan.

http://marc.info/?l=openbsd-techm=130337513320970w=2

I didn't have the coding smarts to progress any further ...

Thanks.

Re: wol for xl(4)

2011-06-14 Thread Thomas Gerlach 
Stefan Sperling stsp at openbsd.org writes:

 
 This is an attempt to add wol support to xl(4).
 
 Unfortunately, while I have an xl(4) card to test with none of the
 motherboards I have will do WOL with it since they all lack an
 on-board WOL connector :(
 
 So test reports are needed.
 Please also check whether WOL is disabled by default.
 

hi
i have an old ASUS A7N8X DELUXE Rev.2 motherboard with an on-board 3Com
3C920B-EMB NIC. i'm running the latest -current.
i tried wol, but it won't work with openbsd (although it works perfectly with
gentoo on the same box).

i had a look into the driver, and tried several approaches, none successful so
far.

1) first, the driver never put the NIC into D3 power state, since the test on
PXL_PME_CAP_D3_HOT was negative. 

---
if_xl_pci.c
if (command  XL_PME_CAP_D3_HOT) {
sc-wol_power = xl_pci_wol_power;
sc-wol_power_arg = psc; 
}
---

so i simply disabled the if above.
= xl_pci_wol_power is called now on shutdown.

2) next i had a look into xl_pci_wol_power. i realized that it does the power
state switch differently from the linux driver. thus, i tried to use
pci_set_powerstate (with proper arguments) instead. i took if_sf_pci.c as
an example (there you can see how pci_set_powerstate must be called).
= unfortunately no effect either.

3) i compared the register window write calls to that of the linux driver (set
win 5 / 7, set and enable rx filter with flags to accept broadcast frames,
etc.). i found nothing wrong about that. the only thing that IMO is different,
is that while the openbsd driver does all those things in different functions,
the linux driver does all within acpi_set_WOL.

4) a note on setting the rx filter (grep on rxfilt): the xl driver does this in
iff_905x (?) (sorry, don't have the sources available right now...) in file
xl.c. i checked and by default, this routine is never called in my case. thus,
i put the rxfilt-code into xl_wol (xl.c) right into the if (enable)
block...
= again no functional WOL...

i hope this helps, i will investigate further.
if you need any more specific detail, please let me know!


cheers,

thomas

Re: wol for xl(4)

2011-04-19 Thread Stefan Sperling 
On Tue, Apr 19, 2011 at 02:03:54AM +0200, Tobias Ulmer wrote:
 On Mon, Apr 18, 2011 at 10:17:33AM +0200, Stefan Sperling wrote:
  On Mon, Apr 18, 2011 at 04:18:01AM +0200, Tobias Ulmer wrote:
   On Sun, Apr 17, 2011 at 11:05:38AM +0200, Stefan Sperling wrote:
On Thu, Mar 31, 2011 at 06:54:44PM +0200, Stefan Sperling wrote:
 This is an attempt to add wol support to xl(4).

 Unfortunately, while I have an xl(4) card to test with none of the
 motherboards I have will do WOL with it since they all lack an
 on-board WOL connector :(

 So test reports are needed.
 Please also check whether WOL is disabled by default.
   
I haven't received any test reports yet.
   
   The (commited) diff has no effect on my onboard xl(4).
   The hardware supports this (BIOS setting checked):
   http://support.dell.com/support/edocs/systems/dvol/en/vol_mt/SETUP.HTM#Wakeup
   %20On%20LAN
  
  Please elaborate on no effect.
  
  Does WOL work at all? Or does it not work at all?
 
 I've done tests with the integrated NIC and one in a PCI slot connected
 to the WOL connector. WOL does not work in any configuration I've tried.
 
  Can it be enabled from the BIOS but not, independently, from ifconfig?
 
 The BIOS has 3 WOL settings: Off, Integrated NIC, WOL Connector. I've
 configured this according to which card was tested. WOL still did not
 work.
 
  Can it be disabled via ifconfig even if enabled in the BIOS?
 
 I've tried enabling WOL using ifconfig for the PCI NIC and set the BIOS
 to WOL mainboard connector. WOL did not work.
 
 shutdowns were always done with halt -p
 
 No idea what else I could do...

Thanks. I'll have to take another look at the FreeBSD driver so.

Can you check whether WOL works with FreeBSD?

Re: wol for xl(4)

2011-04-18 Thread Stefan Sperling 
On Mon, Apr 18, 2011 at 04:18:01AM +0200, Tobias Ulmer wrote:
 On Sun, Apr 17, 2011 at 11:05:38AM +0200, Stefan Sperling wrote:
  On Thu, Mar 31, 2011 at 06:54:44PM +0200, Stefan Sperling wrote:
   This is an attempt to add wol support to xl(4).
  
   Unfortunately, while I have an xl(4) card to test with none of the
   motherboards I have will do WOL with it since they all lack an
   on-board WOL connector :(
  
   So test reports are needed.
   Please also check whether WOL is disabled by default.
 
  I haven't received any test reports yet.
 
 The (commited) diff has no effect on my onboard xl(4).
 The hardware supports this (BIOS setting checked):
 http://support.dell.com/support/edocs/systems/dvol/en/vol_mt/SETUP.HTM#Wakeup
 %20On%20LAN

Please elaborate on no effect.

Does WOL work at all? Or does it not work at all?
Can it be enabled from the BIOS but not, independently, from ifconfig?
Can it be disabled via ifconfig even if enabled in the BIOS?

I have a similar problem with an on-board vr(4) where tweaking the WOL
configuration registers before reboot shows the registers have changed,
but the changes do not survive a reboot.
I guess the BIOS writes to these registers on boot clobbering whatever
the operating system did before it shut down. This way, WOL works with any
operating system when configured from the BIOS, but the OS cannot configure it.

So far I've only seen this behaviour with on-board cards, but not with
cards sitting in PCI slots.

Re: wol for xl(4)

2011-04-17 Thread Stefan Sperling 
On Thu, Mar 31, 2011 at 06:54:44PM +0200, Stefan Sperling wrote:
 This is an attempt to add wol support to xl(4).
 
 Unfortunately, while I have an xl(4) card to test with none of the
 motherboards I have will do WOL with it since they all lack an
 on-board WOL connector :(
 
 So test reports are needed.
 Please also check whether WOL is disabled by default.

I haven't received any test reports yet.

If someone could donate a motherboard with a wol connector, preferrably
with suitable cpu and ram, that would help with getting wol support for
this and some other drivers for similarly old hardware.
It doesn't need to be a fast machine. I just need a board that has a connector.

 
 Index: ic/xl.c
 ===
 RCS file: /cvs/src/sys/dev/ic/xl.c,v
 retrieving revision 1.99
 diff -u -p -r1.99 xl.c
 --- ic/xl.c   22 Sep 2010 08:49:14 -  1.99
 +++ ic/xl.c   31 Mar 2011 15:48:36 -
 @@ -191,6 +191,9 @@ void xl_testpacket(struct xl_softc *);
  int xl_miibus_readreg(struct device *, int, int);
  void xl_miibus_writereg(struct device *, int, int, int);
  void xl_miibus_statchg(struct device *);
 +#ifndef SMALL_KERNEL
 +int xl_wol(struct ifnet *, int);
 +#endif
  
  int
  xl_activate(struct device *self, int act)
 @@ -2368,6 +2371,12 @@ xl_stop(struct xl_softc *sc)
   ifp-if_flags = ~(IFF_RUNNING | IFF_OACTIVE);
  
   xl_freetxrx(sc);
 +
 +#ifndef SMALL_KERNEL
 + /* Call upper layer WOL power routine if WOL is enabled. */
 + if ((sc-xl_flags  XL_FLAG_WOL)  sc-wol_power)
 + sc-wol_power(sc-wol_power_arg);
 +#endif
  }
  
  void
 @@ -2637,6 +2646,15 @@ xl_attach(struct xl_softc *sc)
   CSR_WRITE_2(sc, XL_W0_MFG_ID, XL_NO_XCVR_PWR_MAGICBITS);
   }
  
 +#ifndef SMALL_KERNEL
 + /* Check availability of WOL. */
 + if ((sc-xl_caps  XL_CAPS_PWRMGMT) != 0) {
 + ifp-if_capabilities |= IFCAP_WOL;
 + ifp-if_wol = xl_wol;
 + xl_wol(ifp, 0);
 + }
 +#endif
 +
   /*
* Call MI attach routines.
*/
 @@ -2668,6 +2686,24 @@ xl_detach(struct xl_softc *sc)
  
   return (0);
  }
 +
 +#ifndef SMALL_KERNEL
 +int
 +xl_wol(struct ifnet *ifp, int enable)
 +{
 + struct xl_softc *sc = ifp-if_softc;
 +
 + XL_SEL_WIN(7);
 + if (enable) {
 + CSR_WRITE_2(sc, XL_W7_BM_PME, XL_BM_PME_MAGIC);
 + sc-xl_flags |= XL_FLAG_WOL;
 + } else {
 + CSR_WRITE_2(sc, XL_W7_BM_PME, 0);
 + sc-xl_flags = ~XL_FLAG_WOL;
 + }
 + return (0); 
 +}
 +#endif
  
  struct cfdriver xl_cd = {
   0, xl, DV_IFNET
 Index: ic/xlreg.h
 ===
 RCS file: /cvs/src/sys/dev/ic/xlreg.h,v
 retrieving revision 1.26
 diff -u -p -r1.26 xlreg.h
 --- ic/xlreg.h21 Sep 2010 01:05:12 -  1.26
 +++ ic/xlreg.h31 Mar 2011 15:42:36 -
 @@ -411,6 +411,12 @@
  #define XL_W7_BM_LEN 0x06
  #define XL_W7_BM_STATUS  0x0B
  #define XL_W7_BM_TIMEr   0x0A
 +#define XL_W7_BM_PME 0x0C
 +
 +#define  XL_BM_PME_WAKE  0x0001
 +#define  XL_BM_PME_MAGIC 0x0002
 +#define  XL_BM_PME_LINKCHG   0x0004
 +#define  XL_BM_PME_WAKETIMER 0x0008
  
  /*
   * bus master control registers
 @@ -571,6 +577,7 @@ struct xl_mii_frame {
  #define XL_FLAG_NO_XCVR_PWR  0x0080
  #define XL_FLAG_USE_MMIO 0x0100
  #define XL_FLAG_NO_MMIO  0x0200
 +#define XL_FLAG_WOL  0x0400
  
  #define XL_NO_XCVR_PWR_MAGICBITS 0x0900
  
 @@ -604,6 +611,8 @@ struct xl_softc {
   caddr_t sc_listkva;
   bus_dmamap_tsc_rx_sparemap;
   bus_dmamap_tsc_tx_sparemap;
 + void (*wol_power)(void *);
 + void *wol_power_arg;
  };
  
  #define xl_rx_goodframes(x) \
 @@ -740,6 +749,13 @@ struct xl_stats {
  #define XL_PSTATE_D3 0x0003
  #define XL_PME_EN0x0010
  #define XL_PME_STATUS0x8000
 +
 +/* Bits in the XL_PCI_PWRMGMTCAP register */
 +#define XL_PME_CAP_D00x0800
 +#define XL_PME_CAP_D10x1000
 +#define XL_PME_CAP_D20x2000
 +#define XL_PME_CAP_D3_HOT0x4000
 +#define XL_PME_CAP_D3_COLD   0x8000
  
  extern int xl_intr(void *);
  extern void xl_attach(struct xl_softc *);
 Index: pci/if_xl_pci.c
 ===
 RCS file: /cvs/src/sys/dev/pci/if_xl_pci.c,v
 retrieving revision 1.34
 diff -u -p -r1.34 if_xl_pci.c
 --- pci/if_xl_pci.c   19 Sep 2010 09:22:58 -  1.34
 +++ pci/if_xl_pci.c   31 Mar 2011 15:43:05 -
 @@ -92,10 +92,14 @@ int xl_pci_match(struct device *, void *
  void xl_pci_attach(struct device *, struct device *, void *);
  int xl_pci_detach(struct device *, int);
  void xl_pci_intr_ack(struct xl_softc *);
 +#ifndef SMALL_KERNEL
 +void xl_pci_wol_power(void

Re: wol for xl(4)

2011-04-17 Thread Tobias Ulmer 
On Sun, Apr 17, 2011 at 11:05:38AM +0200, Stefan Sperling wrote:
 On Thu, Mar 31, 2011 at 06:54:44PM +0200, Stefan Sperling wrote:
  This is an attempt to add wol support to xl(4).
 
  Unfortunately, while I have an xl(4) card to test with none of the
  motherboards I have will do WOL with it since they all lack an
  on-board WOL connector :(
 
  So test reports are needed.
  Please also check whether WOL is disabled by default.

 I haven't received any test reports yet.

The (commited) diff has no effect on my onboard xl(4).
The hardware supports this (BIOS setting checked):
http://support.dell.com/support/edocs/systems/dvol/en/vol_mt/SETUP.HTM#Wakeup
%20On%20LAN

OpenBSD 4.9-current (GENERIC.MP) #0: Mon Apr 18 02:39:32 CEST 2011
tobi...@boron.tmux.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel Pentium III (GenuineIntel 686-class, 512KB L2 cache) 499 MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,
SSE
real mem  = 2147049472 (2047MB)
avail mem = 2101751808 (2004MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 01/11/02, BIOS32 rev. 0 @ 0xffe90,
SMBIOS rev. 2.2 @ 0xfb1b0 (83 entries)
bios0: vendor Dell Computer Corporation version A11 date 01/11/02
bios0: Dell Computer Corporation Precision WorkStation 610 MT
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC
acpi0: wakeup devices PCI0(S5) USB0(S5) PCI1(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0: invalid, skipping
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (PCI1)
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 99MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel Pentium III (GenuineIntel 686-class, 512KB L2 cache) 499 MHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,
SSE
mpbios0: bus 0 is type PCI
mpbios0: bus 1 is type PCI
mpbios0: bus 2 is type PCI
mpbios0: bus 3 is type ISA
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
bios0: ROM list: 0xc/0xc000 0xcc000/0x9800 0xd5800/0x800 0xd6000/0x2000
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel 82440BX AGP rev 0x00
intelagp0 at pchb0
agp0 at intelagp0: aperture at 0xf000, size 0x400
ppb0 at pci0 dev 1 function 0 Intel 82440BX AGP rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 Trident Blade 3D rev 0x3a
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
piixpcib0 at pci0 dev 7 function 0 Intel 82371AB PIIX4 ISA rev 0x02
pciide0 at pci0 dev 7 function 1 Intel 82371AB IDE rev 0x01: DMA, channel 0
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: SAMSUNG SP1604N
wd0: 16-sector PIO, LBA48, 152626MB, 312579695 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
wd1 at pciide0 channel 1 drive 0: WDC WD1200BB-00DWA0
wd1: 16-sector PIO, LBA48, 114473MB, 234441648 sectors
wd1(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
uhci0 at pci0 dev 7 function 2 Intel 82371AB USB rev 0x01: apic 2 int 19
(irq 11)
piixpm0 at pci0 dev 7 function 3 Intel 82371AB Power rev 0x02: SMI
iic0 at piixpm0
admtemp0 at iic0 addr 0x2b: adm1021
iic0: addr 0x2d 06=40 09=50 14=53 1a=02 20=cf 21=bd 22=b9 23=7c 24=7d 25=bb
26=3b 27=1d 28=ff 29=50 2a=ff 2b=db 2c=c2 2d=d0 2e=a7 2f=d0 30=a7 31=83 32=77
33=83 34=77 35=c9 36=ae 37=70 38=12 39=4b 3a=46 3b=9a 3c=fa 3d=40 40=03 41=40
42=08 43=50 44=b8 46=40 47=f1 48=2d 49=c0 4a=fa 4b=c0 4c=c0 4d=c0 50=03 53=50
54=b8 56=40 57=f1 58=2d 59=c0 5a=c0 5b=c0 5c=c0 5d=c0 5e=c0 60=cf 61=bd 62=b9
63=7c 64=7d 65=bb 66=3b 67=1d 68=ff 69=50 6a=ff 6b=db 6c=c2 6d=d0 6e=a7 6f=d0
70=a7 71=83 72=77 73=83 74=77 75=c9 76=ae 77=70 78=12 79=4b 7a=46 7b=9a 7c=fa
7d=40 86=40 89=50 94=53 9a=02 a0=cf a1=bd a2=b9 a3=7c a4=7d a5=bb a6=3b a7=1d
a8=ff a9=50 aa=ff ab=db ac=c2 ad=d0 ae=a7 af=d0 b0=a7 b1=83 b2=77 b3=83 b4=77
b5=c9 b6=ae b7=70 b8=12 b9=4b ba=46 bb=9a bc=fa bd=40 c0=03 c3=50 c4=b8 c6=40
c7=f1 c8=2d c9=c0 ca=c0 cb=c0 cc=c0 cd=c0 ce=c0 d0=03 d3=50 d4=b8 d6=40 d7=f1
d8=2d d9=c0 da=c0 db=c0 dc=c0 dd=c0 de=c0 e0=cf e1=bd e2=b9 e3=7c e4=7d e5=bb
e6=3b e7=1d e8=ff e9=50 ea=ff eb=db ec=c2 ed=d0 ee=a7 ef=d0 f0=a7 f1=83 f2=77
f3=83 f4=77 f5=c9 f6=ae f7=70 f8=12 f9=4b fa=46 fb=9a fc=fa fd=40 words
00=0080 01=0080 02=0080 03=0080 04=0080 05=0080 06=4080 07=0080
admtemp1 at iic0 addr 0x4e: adm1021
spdmem0 at iic0 addr 0x50: 512MB SDRAM non-parity PC133CL3
spdmem1 at iic0 addr 0x51: 512MB SDRAM non-parity PC133CL3
spdmem2 at iic0 addr 0x52: 512MB SDRAM non-parity PC133CL3
spdmem3 at iic0 addr 0x53: 512MB SDRAM non-parity PC133CL3
xl0 at pci0 dev 13 function 0 3Com 3c905C 100Base-TX rev 0x78: apic 2 int 16
(irq 10), address 00:04:75:b1:00:7d
exphy0 at xl0 phy 24: 3Com internal media interface
rl0 at pci0 dev 14 function 0 Realtek 8139 rev 0x10: apic 2

wol for xl(4)

2011-03-31 Thread Stefan Sperling 
This is an attempt to add wol support to xl(4).

Unfortunately, while I have an xl(4) card to test with none of the
motherboards I have will do WOL with it since they all lack an
on-board WOL connector :(

So test reports are needed.
Please also check whether WOL is disabled by default.

Index: ic/xl.c
===
RCS file: /cvs/src/sys/dev/ic/xl.c,v
retrieving revision 1.99
diff -u -p -r1.99 xl.c
--- ic/xl.c 22 Sep 2010 08:49:14 -  1.99
+++ ic/xl.c 31 Mar 2011 15:48:36 -
@@ -191,6 +191,9 @@ void xl_testpacket(struct xl_softc *);
 int xl_miibus_readreg(struct device *, int, int);
 void xl_miibus_writereg(struct device *, int, int, int);
 void xl_miibus_statchg(struct device *);
+#ifndef SMALL_KERNEL
+int xl_wol(struct ifnet *, int);
+#endif
 
 int
 xl_activate(struct device *self, int act)
@@ -2368,6 +2371,12 @@ xl_stop(struct xl_softc *sc)
ifp-if_flags = ~(IFF_RUNNING | IFF_OACTIVE);
 
xl_freetxrx(sc);
+
+#ifndef SMALL_KERNEL
+   /* Call upper layer WOL power routine if WOL is enabled. */
+   if ((sc-xl_flags  XL_FLAG_WOL)  sc-wol_power)
+   sc-wol_power(sc-wol_power_arg);
+#endif
 }
 
 void
@@ -2637,6 +2646,15 @@ xl_attach(struct xl_softc *sc)
CSR_WRITE_2(sc, XL_W0_MFG_ID, XL_NO_XCVR_PWR_MAGICBITS);
}
 
+#ifndef SMALL_KERNEL
+   /* Check availability of WOL. */
+   if ((sc-xl_caps  XL_CAPS_PWRMGMT) != 0) {
+   ifp-if_capabilities |= IFCAP_WOL;
+   ifp-if_wol = xl_wol;
+   xl_wol(ifp, 0);
+   }
+#endif
+
/*
 * Call MI attach routines.
 */
@@ -2668,6 +2686,24 @@ xl_detach(struct xl_softc *sc)
 
return (0);
 }
+
+#ifndef SMALL_KERNEL
+int
+xl_wol(struct ifnet *ifp, int enable)
+{
+   struct xl_softc *sc = ifp-if_softc;
+
+   XL_SEL_WIN(7);
+   if (enable) {
+   CSR_WRITE_2(sc, XL_W7_BM_PME, XL_BM_PME_MAGIC);
+   sc-xl_flags |= XL_FLAG_WOL;
+   } else {
+   CSR_WRITE_2(sc, XL_W7_BM_PME, 0);
+   sc-xl_flags = ~XL_FLAG_WOL;
+   }
+   return (0); 
+}
+#endif
 
 struct cfdriver xl_cd = {
0, xl, DV_IFNET
Index: ic/xlreg.h
===
RCS file: /cvs/src/sys/dev/ic/xlreg.h,v
retrieving revision 1.26
diff -u -p -r1.26 xlreg.h
--- ic/xlreg.h  21 Sep 2010 01:05:12 -  1.26
+++ ic/xlreg.h  31 Mar 2011 15:42:36 -
@@ -411,6 +411,12 @@
 #define XL_W7_BM_LEN   0x06
 #define XL_W7_BM_STATUS0x0B
 #define XL_W7_BM_TIMEr 0x0A
+#define XL_W7_BM_PME   0x0C
+
+#defineXL_BM_PME_WAKE  0x0001
+#defineXL_BM_PME_MAGIC 0x0002
+#defineXL_BM_PME_LINKCHG   0x0004
+#defineXL_BM_PME_WAKETIMER 0x0008
 
 /*
  * bus master control registers
@@ -571,6 +577,7 @@ struct xl_mii_frame {
 #define XL_FLAG_NO_XCVR_PWR0x0080
 #define XL_FLAG_USE_MMIO   0x0100
 #define XL_FLAG_NO_MMIO0x0200
+#define XL_FLAG_WOL0x0400
 
 #define XL_NO_XCVR_PWR_MAGICBITS   0x0900
 
@@ -604,6 +611,8 @@ struct xl_softc {
caddr_t sc_listkva;
bus_dmamap_tsc_rx_sparemap;
bus_dmamap_tsc_tx_sparemap;
+   void (*wol_power)(void *);
+   void *wol_power_arg;
 };
 
 #define xl_rx_goodframes(x) \
@@ -740,6 +749,13 @@ struct xl_stats {
 #define XL_PSTATE_D3   0x0003
 #define XL_PME_EN  0x0010
 #define XL_PME_STATUS  0x8000
+
+/* Bits in the XL_PCI_PWRMGMTCAP register */
+#define XL_PME_CAP_D0  0x0800
+#define XL_PME_CAP_D1  0x1000
+#define XL_PME_CAP_D2  0x2000
+#define XL_PME_CAP_D3_HOT  0x4000
+#define XL_PME_CAP_D3_COLD 0x8000
 
 extern int xl_intr(void *);
 extern void xl_attach(struct xl_softc *);
Index: pci/if_xl_pci.c
===
RCS file: /cvs/src/sys/dev/pci/if_xl_pci.c,v
retrieving revision 1.34
diff -u -p -r1.34 if_xl_pci.c
--- pci/if_xl_pci.c 19 Sep 2010 09:22:58 -  1.34
+++ pci/if_xl_pci.c 31 Mar 2011 15:43:05 -
@@ -92,10 +92,14 @@ int xl_pci_match(struct device *, void *
 void xl_pci_attach(struct device *, struct device *, void *);
 int xl_pci_detach(struct device *, int);
 void xl_pci_intr_ack(struct xl_softc *);
+#ifndef SMALL_KERNEL
+void xl_pci_wol_power(void *);
+#endif
 
 struct xl_pci_softc {
struct xl_softc psc_softc;
pci_chipset_tag_t   psc_pc;
+   pcitag_tpsc_tag;
bus_size_t  psc_iosize;
bus_size_t  psc_funsize;
 };
@@ -156,9 +160,11 @@ xl_pci_attach(struct device *parent, str
u_int32_t command;
 
psc-psc_pc = pc;
+   psc-psc_tag = pa-pa_tag;
sc-sc_dmat = pa-pa_dmat;
 
sc-xl_flags = 0;
+   sc