Tobias Diedrich | 1 Jun 01:20 2008

Re: [PATCH 6/4] Fix forcedeth hibernate/wake-on-lan problems

From: Tobias Diedrich <ranma+kernel <at>>

This patch is the minimal amount of code needed to support
wake-on-lan in platform mode properly (i.e. "ethtool -s eth0 wol g"
is sufficient, no additional magic needed) for me.

This is derived from David Brownells patch
However I decided to move the hook into pci-acpi.c since the other
two pci hooks also live there and pci and acpi are the only users of
the platform_enable_wakeup-hook.

As a 'side-effect' this also makes wake on usb activity work for me
and I had to disable usb wakeup (which is enabled by default) using
the power/wakeup sysfs functionality ("echo disabled >

(BTW I first thought the 'immediate reboot because of usb wake' effect is
caused by the optical mouse generating a wake event, but it rather
seems to be a problem with a flaky secondary usb host controller,
which sees a connected device where nothing is attached)

Signed-off-by: Tobias Diedrich <ranma+kernel <at>>

Index: linux-2.6.26-rc4.forcedwol/drivers/pci/pci-acpi.c
--- linux-2.6.26-rc4.forcedwol.orig/drivers/pci/pci-acpi.c	2008-06-01 00:40:23.000000000 +0200
+++ linux-2.6.26-rc4.forcedwol/drivers/pci/pci-acpi.c	2008-06-01 00:46:55.000000000 +0200
 <at>  <at>  -315,6 +315,25  <at>  <at> 
(Continue reading)

Grant Grundler | 1 Jun 01:54 2008

Re: PATCH for [Bug 8952] tulip driver oops in tulip_interrupt when hibernating with swsusp/suspend2

On Fri, May 30, 2008 at 10:09:35PM -0400, Jeff Garzik wrote:
> Grant Grundler wrote:
>> Jeff,
>> The following patch is seems to fix the tulip suspend/resume panic:
>> My attempts at a cleaner patch failed and Pavel thinks this is OK.
>> Since suspend/resume is getting an overhaul in 2.6.27 (per comment
>> #49 by  Rafael J. Wysocki), it makes sense to invest more time as
>> part of that rework and apply the known fix to 2.6.26.
>> hth,
>> grant
>> Original from:  kernelbugs <at>
>> Signed-off-by: Grant Grundler <grundler <at>>
>> diff --git a/drivers/net/tulip/tulip_core.c 
>> b/drivers/net/tulip/tulip_core.c
>> index f9d13fa..088d3bf 100644
>> --- a/drivers/net/tulip/tulip_core.c
>> +++ b/drivers/net/tulip/tulip_core.c
>>  <at>  <at>  -1729,12 +1729,15  <at>  <at>  static int tulip_suspend (struct pci_dev *pdev, 
>> pm_message_t state)
>>  	if (!dev)
>>  		return -EINVAL;
>>  -	if (netif_running(dev))
>> -		tulip_down(dev);
>> +	if (!netif_running(dev))
>> +		goto save_state:
>> +
>> +	tulip_down(dev);
> how could this be tested if it doesn't even compile?
(Continue reading)

Bill Fink | 1 Jun 01:57 2008

Re: [PATCH] net: add ability to clear stats via ethtool - e1000/pcnet32

On Sat, 31 May 2008, Alan Cox wrote:

> > When diagnosing network problems, the ability to zero counters is
> > a major aid in diagnosis.  Writing scripts is not a general solution
> > since often several systems are involved and it's not simple to do
> > this via a script.  Saving stats output and running beforeafter on
> > a number of systems is a royal pain when troubleshooting.
> Zeroing them is not a general solution either - you break all the other
> tools monitoring the same stats in parallel - like network usage monitors.
> This is a user space tools problem, scripts or otherwise.

Two points.  One, if I as a Linux network administrator, make a
deliberate decision to zero counters, I will be making that decision
taking into account any other effects it might have.

Second, I already expressed support for the preferred option of
the zeroing of counters actually just doing a snapshot of the stats,
and subsequent requests for the stats doing a diff from the snapshot.
There could also be a mechanism for getting the absolute values of
the stats that for example SNMP monitoring would utilize.

Perhaps a user space tool such as ifstat can be part of the solution
(I haven't had a chance to check it out yet).  But it would be
difficult I believe to make a general user space tool for dealing
with the device specific stats reported by "ethtool -S" since they
are quite specific to an individual device driver.

Yes, every individual Linux network administrator can re-create the
(Continue reading)

Ben Hutchings | 1 Jun 03:46 2008

Re: [PATCH] net: add ability to clear stats via ethtool - e1000/pcnet32

Bill Fink wrote:
> Yes, every individual Linux network administrator can re-create the
> wheel by devising their own scripts, but it makes much more sense
> to me to implement a simple general kernel mechanism once that could
> be used generically, than to have hundreds (or thousands) of Linux
> network administrators each having to do it themselves (perhaps
> multiple times if they have a variety of types of systems and types
> of NICs).

The ethtool interface is pretty generic, even if the names aren't.
Here's some Python code I just knocked up which demonstrates how
to get a set of named stats.  It shouldn't be terribly hard to
extend this to saving and subtracting stat sets.


import array, fcntl, os, socket, struct



ETHTOOL_GSTATS = 0x0000001d

def ethtool(sock, name, buf):
    ifreq = struct.pack('16sP', name, buf.buffer_info()[0])
(Continue reading)

Arjan van de Ven | 1 Jun 03:46 2008

[PATCH] net: via-velocity.c fix sleep-with-spinlock bug during MTU change

From: Arjan van de Ven <arjan <at>>
Subject: [PATCH] net: via-velocity.c fix sleep-with-spinlock bug during MTU change

The via-velocity.c driver reinitializes (frees/allocates) several
metadata structures during an MTU change. Unfortunately the allocations
of the new versions of the metadata is done with GFP_KERNEL, even
though this change of datastructures is (and needs to be) done while
holding a spinlock (with irqs off).

Clearly that isn't a good thing, and has trapped a large
deal of the resulting warnings. The fix is to use GFP_ATOMIC.
While not elegant, avoiding the lock is going to be extremely complex.
In addition, this is a "static", long lived allocation (after all, how
often do you actually change your mtu) and not something that happens
on an ongoing basis.

Signed-off-by: Arjan van de Ven <arjan <at>>
 drivers/net/via-velocity.c |   12 +++++++++---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c
index 6b8d882..4bf08fd 100644
--- a/drivers/net/via-velocity.c
+++ b/drivers/net/via-velocity.c
 <at>  <at>  -1,4 +1,4  <at>  <at> 
(Continue reading)

Arjan van de Ven | 1 Jun 03:54 2008

Re: howto use ioremap_wc?

On Sat, 31 May 2008 11:02:54 +0200
Brice Goglin <brice <at>> wrote:

> Hello,
> We're looking at using ioremap_wc() in myri10ge. No drivers seem to be
> using it yet, so I'd like to get some clarification regarding
> ioremap_wc failures, MTRR and so on.
> What we currently do is mtrr_add() and then ioremap. Depending on the
> mtrr_add() success, we use the "wc_fifo" or regular PIO with fences to
> submit requests to the NIC. 

Ok this leads to a question: since write combining is effectively an
extension (eg relaxation) to uncached, how much do you care if you
actually get uncached? Eg can you just use the "WC" function even for
the case where you get an uncached mapping ?

> How are we supposed to switch this to
> ioremap_wc?
> Are we sure that if the arch supports _wc, it does not return success
> when the underlying plain ioremap worked but setting up _wc() failed?

why would it not return success? You asked for a mapping with a set of
guarantees, and you got something that adheres to those guarantees (and
then some ;(...

Would you expect ioremap_cache() to fail if you couldn't get a cachable
mapping? That would suck (hint: on PC's it will then fail 99.9% of the
(Continue reading)

Alan Stern | 1 Jun 04:51 2008

Re: [linux-pm] [PATCH 0/4] Fix forcedeth hibernate/wake-on-lan problems

On Sun, 1 Jun 2008, Tobias Diedrich wrote:

> Ok, after another long debugging session I finally found out the
> reason for the immediate reboot (after finding the place that
> suspends the serial console (drivers/pnp) and disabling that suspend
> path):
> The system is woken up by USB activity! (Optical mouse, anyone?)
> Lo and behold:
> drivers/usb/core/hcd-pci.c tries it's best to activate 'wake on
> usb', which I didn't know since it apparently also never worked.
> However, after applying the 'use platform_enable_wakeup'-patch,
> not only forcedeth wake starts working, also usb wake.
> If I prevent usb wake:
> |echo disabled > /sys/devices/pci0000\:00/0000\:00\:02.0/power/wakeup'
> |echo disabled > /sys/devices/pci0000\:00/0000\:00\:02.1/power/wakeup'
> And then hibernate in platform mode, the immediate reboot is gone
> and waking up using magic packets works fine even without setting up
> /proc/acpi/wakeup first.
> Maybe I should try hooking mouse and keyboard onto different usb
> host controllers, so I can disable wakeup for the mouse host
> controller and enable wakeup for the keyboard host controller,
> then it should be possible to wake the system by pressing a key. :)

You don't need to do that.  Wakeup can be set specifically for each 
individual USB device, provided CONFIG_USB_SUSPEND is enabled.

On Sun, 1 Jun 2008, Tobias Diedrich wrote:

(Continue reading)

Arjan van de Ven | 1 Jun 05:11 2008

PATCH] net: b44.c fix sleeping-with-spinlock-helt during resume

From: Arjan van de Ven <arjan <at>>
Subject: [PATCH] net: b44.c fix sleeping-with-spinlock-helt during resume
CC: Michael Buesch <mb <at>>

The b44.c driver calls b44_chip_reset() from the resume path,
with the device spinlock held.
Unfortunately, b44_chip_reset() calls ssb_pcicore_dev_irqvecs_enable()
which is a sleeping function (and calls might_sleep), if and only if
the device hasn't been enabled yet.

Not having this hardware, the safest solution seems to be to enable
the irqvec before taking the spinlock...

Signed-off-by: Arjan van de Ven
 drivers/net/b44.c |   12 ++++++++++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 59dce6a..6028129 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
 <at>  <at>  -1278,6 +1278,7  <at>  <at>  static void b44_chip_reset(struct b44 *bp, int reset_kind)
 		bw32(bp, B44_DMARX_CTRL, 0);
 		bp->rx_prod = bp->rx_cons = 0;
 	} else
+		/* this function sleeps! */
(Continue reading)

Ilpo Järvinen | 1 Jun 07:51 2008

Re: [bug] stuck localhost TCP connections, v2.6.26-rc3+

On Sat, 31 May 2008, Patrick McManus wrote:

> On Sat, 2008-05-31 at 18:35 +0200, Ingo Molnar wrote:
> > * Ilpo Järvinen <ilpo.jarvinen <at>> wrote:
> > 
> > > ...setsockopt(listenfd, SOL_TCP, TCP_DEFER_ACCEPT, &val, sizeof(val)) 
> > > seems to be the magic trick that is interestion here.
> > 
> > seems to be used:
> > 
> >  22003 write(3, "distccd[22003] (dcc_listen_by_ad"..., 62) = 62
> >  22003 listen(4, 10)                     = 0
> >  22003 setsockopt(4, SOL_TCP, TCP_DEFER_ACCEPT, [1], 4) = 0
> > 
> > i'll queue up your reverts for testing in -tip.
> So the code you will revert came from my fingers. The circumstances here
> make me nervous; while I'm at a loss to explain what might be going on
> in particular, let me offer an apology in advance should the revert help
> resolve the issue.

Yes, don't worry just yet. It far from proven yet that this is the cause 
(or contributes to easiness of reproducal in any way). The patch was just 
for Ingo's testing in his -tip branch. I didn't even bother to cc you yet 
because it's more or less a stab into dark, but it's definately worth of 
testing still even though Ingo probably comes back soon and tells that it 
didn't help any because it's clearly related :-).

(Continue reading)

Matti Linnanvuori | 1 Jun 07:59 2008

Re: [PATCH v1.2.26] wan: new driver retina

2008/5/30 Krzysztof Halasa <khc <at>>:
> "Matti Linnanvuori" <mattilinn <at>> writes:
>>>> +static int fepci_char_open(struct inode *inode, struct file *filp)
>>>> +{
>>>> +     unsigned int minor = MINOR(inode->i_rdev);
>>>> +     if (unlikely(minor >= find_cnt || card_privates[minor].pci_dev == NULL))
>>>> +             return -ENXIO;
>>>> +     filp->f_op = &fepci_char_fops;
>>>> +     if (unlikely(!try_module_get(THIS_MODULE)))
>>>> +             return -EBUSY;
>>> That won't work race-free, use owner field.
>> You mean the f_op assignment? I have removed that.
> Actually I meant try_module_get() from within the driver, for example
> your module may get unloaded while in this function, before this
> try_module_get(), and that would be fatal.

I don't think the module can finish getting unloaded while in that
function because the module cleanup function unregisters the
character device.

> Yes, I thought stream mode = character device but now I see it's
> another flavour of network device(?), which is never up and exists
> only for the ability to receive netdev ioctls (though it also uses
> char dev ioctls).
> Did I get this right?

(Continue reading)