Re: [PATCH] Configurable tap interface MTU

On 9/11/07, Herbert Xu [EMAIL PROTECTED] wrote: Please make it 65535 without an Ethernet header and 65521 with an Ethernet header. Here is a revised patch that allows MTUs up to 65535 for tap interfaces and up to 65521 for tun interfaces. (If I set the MTU to 65521 on a tun interface, ping

[PATCH] forcedeth: power down phy when interface is down

Bring the physical link down when the interface is down, by placing the PHY in power-down state. This mirrors the behavior of other drivers including e1000 and tg3. Signed-off-by: Ed Swierk [EMAIL PROTECTED] forcedeth-phy-power-down.patch Description: Binary data

[PATCH] forcedeth: no link is informational

Log no link during initialization at KERN_INFO as it's not an error, and occurs every time the interface comes up (when the forcedeth-phy-power-down patch is applied). Signed-off-by: Ed Swierk [EMAIL PROTECTED] forcedeth-open-no-link-printk.patch Description: Binary data

[updated PATCH] forcedeth: power down phy when interface is down

On 9/19/07, Ayaz Abdulla [EMAIL PROTECTED] wrote: It seems that you are powering down the phy even if WOL is enabled. Right; I've updated the patch to skip powering down the phy when wol is enabled. Secondly, can you powerdown the phy at the same time you start performing autoneg restart?

[PATCH] Configurable tap interface MTU

the value used by the e1000 driver, so it seems like a safe upper limit. Signed-off-by: Ed Swierk [EMAIL PROTECTED] --- tap-change-mtu.patch Description: Binary data

Longer command line for kexec on i386

I'm attempting to get kexec to pass a command line longer than 256 bytes to the new kernel, using kexec-tools-testing-20070330 and kernel 2.6.22.1. The new kernel is a bzImage, and I'm using kexec to tack on a command line and an initrd. I made the following change to kexec: ---

Re: Longer command line for kexec on i386

Ed Swierk eswierk at arastra.com writes: I made the following change to kexec: [deleted] but I'm now seeing intermittent corruption of the initrd in the new kernel--a few bytes at different locations each time. I suspect I've neglected some other important changes to the boot protocol

[PATCH] ethtool: Extend ethtool plugin module eeprom API to phylib

call the equivalent ethtool_ops functions provided by network drivers with built-in phy support. Signed-off-by: Ed Swierk eswi...@skyportsystems.com --- include/linux/phy.h | 9 + net/core/ethtool.c | 45 ++--- 2 files changed, 43 insertions(+), 11

Re: [RFC PATCH urcu on mips, parisc] Fix: compat_futex should work-around futex signal-restart kernel bug

I believe e967ef02 "MIPS: Fix restart of indirect syscalls" should be backported to all stable kernels. It would be a surprising coincidence if parisc suffers from the same problem. --Ed On Thu, Dec 17, 2015 at 4:54 AM, Mathieu Desnoyers wrote: > - On Dec

[PATCH v5 4/4] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

hether any commands are immune to being blocked by this process. So it seems safest to ignore the chip's reported command durations, and use a value much higher than any observed duration, like 180 sec (which is the duration this chip reports for "long" commands). Signed-off-by: Ed Swierk <esw

[PATCH v5 1/4] tpm_tis: Improve reporting of IO errors

Mysterious TPM behavior can be difficult to track down through all the layers of software. Add error messages for conditions that should never happen. Also include the manufacturer ID along with other chip data printed during init. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Re

[PATCH v5 0/4] tpm: Command duration logging and chip-specific override

durations as well as protocol timeouts - overrides ST19NP18 TPM command duration to avoid lockups Ed Swierk (4): tpm_tis: Improve reporting of IO errors tpm: Add optional logging of TPM command durations tpm: Allow TPM chip drivers to override reported command durations tpm_tis: Increase

[PATCH v5 3/4] tpm: Allow TPM chip drivers to override reported command durations

-by: Ed Swierk <eswi...@skyportsystems.com> --- drivers/char/tpm/tpm-interface.c | 177 +-- drivers/char/tpm/tpm_tis.c | 35 ++-- include/linux/tpm.h | 3 +- 3 files changed, 106 insertions(+), 109 deletions(-) diff --git a/drivers/ch

[PATCH v5 2/4] tpm: Add optional logging of TPM command durations

red with DYNAMIC_DEBUG=y. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> --- drivers/char/tpm/tpm-interface.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/char/tpm/tp

[PATCH v4 3/4] tpm: Allow TPM chip drivers to override reported command durations

-by: Ed Swierk <eswi...@skyportsystems.com> --- drivers/char/tpm/tpm-interface.c | 177 +-- drivers/char/tpm/tpm_tis.c | 35 ++-- include/linux/tpm.h | 3 +- 3 files changed, 106 insertions(+), 109 deletions(-) diff --git a/drivers/ch

[PATCH v4 4/4] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

hether any commands are immune to being blocked by this process. So it seems safest to ignore the chip's reported command durations, and use a value much higher than any observed duration, like 180 sec (which is the duration this chip reports for "long" commands). Signed-off-by: Ed Swierk <esw

[PATCH v4 2/4] tpm: Add optional logging of TPM command durations

red with DYNAMIC_DEBUG=y. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> --- drivers/char/tpm/tpm-interface.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/char/tpm/tp

[PATCH v4 1/4] tpm_tis: Improve reporting of IO errors

Mysterious TPM behavior can be difficult to track down through all the layers of software. Add error messages for conditions that should never happen. Also include the manufacturer ID along with other chip data printed during init. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Re

[PATCH v4 0/4] tpm: Command duration logging and chip-specific override

ST19NP18 TPM command duration to avoid lockups Ed Swierk (4): tpm_tis: Improve reporting of IO errors tpm: Add optional logging of TPM command durations tpm: Allow TPM chip drivers to override reported command durations tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

Re: [PATCH v5 3/4] tpm: Allow TPM chip drivers to override reported command durations

On Fri, Jun 10, 2016 at 5:19 AM, Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> wrote: > On Wed, Jun 08, 2016 at 04:00:17PM -0700, Ed Swierk wrote: >> Some TPM chips report bogus command durations in their capabilities, >> just as others report incorrect timeouts. Re

[PATCH v6 3/5] tpm: Factor out reading of timeout and duration capabilities

Factor sending the TPM_GetCapability command and validating the result from tpm_get_timeouts() into a new function. Return all errors to the caller rather than swallowing them (e.g. when tpm_transmit_cmd() returns nonzero). Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> --- driver

[PATCH v6 4/5] tpm: Allow TPM chip drivers to override reported command durations

-by: Ed Swierk <eswi...@skyportsystems.com> --- drivers/char/tpm/tpm-interface.c | 139 +-- drivers/char/tpm/tpm_tis.c | 35 +++--- include/linux/tpm.h | 3 +- 3 files changed, 85 insertions(+), 92 deletions(-) diff --git a/drivers/ch

[PATCH v6 0/5] tpm: Command duration logging and chip-specific override

reporting - adds optional logging of TPM command durations - allows chip-specific override of command durations as well as protocol timeouts - overrides ST19NP18 TPM command duration to avoid lockups Ed Swierk (5): tpm_tis: Improve reporting of IO errors tpm: Add optional logging of TPM command

[PATCH v6 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

hether any commands are immune to being blocked by this process. So it seems safest to ignore the chip's reported command durations, and use a value much higher than any observed duration, like 180 sec (which is the duration this chip reports for "long" commands). Signed-off-by: Ed Swierk <esw

[PATCH v6 2/5] tpm: Add optional logging of TPM command durations

red with DYNAMIC_DEBUG=y. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> --- drivers/char/tpm/tpm-interface.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/char/tpm/tp

Re: [PATCH v5 3/4] tpm: Allow TPM chip drivers to override reported command durations

On Fri, Jun 10, 2016 at 12:42 PM, Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> wrote: > On Fri, Jun 10, 2016 at 10:34:15AM -0700, Ed Swierk wrote: >> On Fri, Jun 10, 2016 at 5:19 AM, Jarkko Sakkinen >> <jarkko.sakki...@linux.intel.com> wrote: >> > On Wed,

[PATCH v6 1/5] tpm_tis: Improve reporting of IO errors

Mysterious TPM behavior can be difficult to track down through all the layers of software. Add error messages for conditions that should never happen. Also include the manufacturer ID along with other chip data printed during init. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Re

Re: [tpmdd-devel] [PATCH v4 3/4] tpm: Allow TPM chip drivers to override reported command durations

On Wed, Jun 8, 2016 at 12:05 PM, Jason Gunthorpe <jguntho...@obsidianresearch.com> wrote: > On Tue, Jun 07, 2016 at 05:45:39PM -0700, Ed Swierk wrote: >> + case 0x32041114: /* Atmel 3204 */ >> + chip->vendor.timeout_a = TIS_SHORT_TIMEOUT * HZ / 100

[PATCH v8 1/5] tpm_tis: Improve reporting of IO errors

Mysterious TPM behavior can be difficult to track down through all the layers of software. Add error messages for conditions that should never happen. Also include the manufacturer ID along with other chip data printed during init. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Re

[PATCH v8 4/5] tpm: Allow TPM chip drivers to override reported command durations

-by: Ed Swierk <eswi...@skyportsystems.com> --- drivers/char/tpm/tpm-interface.c | 143 +-- drivers/char/tpm/tpm_tis.c | 35 +++--- include/linux/tpm.h | 3 +- 3 files changed, 88 insertions(+), 93 deletions(-) diff --git a/drivers/ch

[PATCH v8 0/5] tpm: Command duration logging and chip-specific override

both timeouts and durations via a single callback. This series - improves TPM command error reporting - adds optional logging of TPM command durations - allows chip-specific override of command durations as well as protocol timeouts - overrides ST19NP18 TPM command duration to avoid lockups Ed

[PATCH v8 2/5] tpm: Add optional logging of TPM command durations

red with DYNAMIC_DEBUG=y. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> --- drivers/char/tpm/tpm-interface.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/char/tpm/tp

[PATCH v8 3/5] tpm: Clean up reading of timeout and duration capabilities

Call tpm_getcap() from tpm_get_timeouts() to eliminate redundant code. Return all errors to the caller rather than swallowing them (e.g. when tpm_transmit_cmd() returns nonzero). Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> --- drivers/char/tpm/tpm-interface.

[PATCH v8 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

hether any commands are immune to being blocked by this process. So it seems safest to ignore the chip's reported command durations, and use a value much higher than any observed duration, like 180 sec (which is the duration this chip reports for "long" commands). Signed-off-by: Ed Swierk <esw

Re: [PATCH v7 3/5] tpm: Clean up reading of timeout and duration capabilities

On Mon, Jun 20, 2016 at 6:54 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > --- a/drivers/char/tpm/tpm-interface.c > +++ b/drivers/char/tpm/tpm-interface.c > @@ -461,9 +461,19 @@ ssize_t tpm_getcap(struct device *dev, __be32 subcap_id

[PATCH v7 0/5] tpm: Command duration logging and chip-specific override

a single callback. This series - improves TPM command error reporting - adds optional logging of TPM command durations - allows chip-specific override of command durations as well as protocol timeouts - overrides ST19NP18 TPM command duration to avoid lockups Ed Swierk (5): tpm_tis: Improve

[PATCH v7 4/5] tpm: Allow TPM chip drivers to override reported command durations

-by: Ed Swierk <eswi...@skyportsystems.com> --- drivers/char/tpm/tpm-interface.c | 143 +-- drivers/char/tpm/tpm_tis.c | 35 +++--- include/linux/tpm.h | 3 +- 3 files changed, 88 insertions(+), 93 deletions(-) diff --git a/drivers/ch

[PATCH v7 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

hether any commands are immune to being blocked by this process. So it seems safest to ignore the chip's reported command durations, and use a value much higher than any observed duration, like 180 sec (which is the duration this chip reports for "long" commands). Signed-off-by: Ed Swierk <esw

[PATCH v7 2/5] tpm: Add optional logging of TPM command durations

red with DYNAMIC_DEBUG=y. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> --- drivers/char/tpm/tpm-interface.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/char/tpm/tp

[PATCH v7 1/5] tpm_tis: Improve reporting of IO errors

Mysterious TPM behavior can be difficult to track down through all the layers of software. Add error messages for conditions that should never happen. Also include the manufacturer ID along with other chip data printed during init. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Re

[PATCH v7 3/5] tpm: Clean up reading of timeout and duration capabilities

Call tpm_getcap() from tpm_get_timeouts() to eliminate redundant code. Return all errors to the caller rather than swallowing them (e.g. when tpm_transmit_cmd() returns nonzero). Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> --- drivers/char/tpm/tpm-interface.

Re: [PATCH v9 0/5] tpm: Command duration logging and chip-specific override

On Wed, Jul 13, 2016 at 9:19 AM, Ed Swierk <eswi...@skyportsystems.com> wrote: > v9: Include command duration in existing error messages rather than > logging an extra debug message. Rebase onto Jarkko's tree. Incidentally, with Jarkko's tree the tpm_tis module refuses t

[PATCH v9 2/5] tpm: Add optional logging of TPM command durations

red with DYNAMIC_DEBUG=y. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> --- drivers/char/tpm/tpm-interface.c | 19 +-- 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/drivers/char/tpm/tp

[PATCH v9 4/5] tpm: Allow TPM chip drivers to override reported command durations

-by: Ed Swierk <eswi...@skyportsystems.com> --- drivers/char/tpm/tpm-interface.c | 148 ++- drivers/char/tpm/tpm_tis_core.c | 32 +++-- include/linux/tpm.h | 3 +- 3 files changed, 94 insertions(+), 89 deletions(-) diff --git a/drivers/ch

[PATCH v9 3/5] tpm: Clean up reading of timeout and duration capabilities

Call tpm_getcap() from tpm_get_timeouts() to eliminate redundant code. Return all errors to the caller rather than swallowing them (e.g. when tpm_transmit_cmd() returns nonzero). Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> --- drivers/char/tpm/tpm-interface.

[PATCH v9 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

hether any commands are immune to being blocked by this process. So it seems safest to ignore the chip's reported command durations, and use a value much higher than any observed duration, like 180 sec (which is the duration this chip reports for "long" commands). Signed-off-by: Ed Swierk <esw

[PATCH v9 1/5] tpm_tis: Improve reporting of IO errors

Mysterious TPM behavior can be difficult to track down through all the layers of software. Add error messages for conditions that should never happen. Also include the manufacturer ID along with other chip data printed during init. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Re

[PATCH v9 0/5] tpm: Command duration logging and chip-specific override

-specific override of command durations as well as protocol timeouts - overrides ST19NP18 TPM command duration to avoid lockups Ed Swierk (5): tpm_tis: Improve reporting of IO errors tpm: Add optional logging of TPM command durations tpm: Clean up reading of timeout and duration capabilities

Re: [PATCH v9 0/5] tpm: Command duration logging and chip-specific override

On Wed, Jul 13, 2016 at 10:36 AM, Jason Gunthorpe wrote: > I think your bios is broken? The BIOS is broken in many ways. I already have to pass memmap=256M$0x8000, otherwise PCIe extended config space (MMCONFIG) is inaccessible. Also I found

Re: [PATCH v2 00/11] staging: octeon: multi rx group (queue) support

On 8/31/16 13:57, Aaro Koskinen wrote: > This series implements multiple RX group support that should improve > the networking performance on multi-core OCTEONs. Basically we register > IRQ and NAPI for each group, and ask the HW to select the group for > the incoming packets based on hash. > >

Re: [PATCH 0/9] staging: octeon: multi rx group (queue) support

On 8/31/16 14:20, Aaro Koskinen wrote: > On Wed, Aug 31, 2016 at 09:20:07AM -0700, Ed Swierk wrote: >> Here's my workaround: > > [...] > >> -static int cvm_oct_poll(struct oct_rx_group *rx_group, int budget) >> +static int cvm_oct_poll(int group, int budget) >&g

Re: [PATCH 0/9] staging: octeon: multi rx group (queue) support

Hi Aaro, On Tue, Aug 30, 2016 at 11:47 AM, Aaro Koskinen wrote: > This series implements multiple RX group support that should improve > the networking performance on multi-core OCTEONs. Basically we register > IRQ and NAPI for each group, and ask the HW to select the group

Re: [PATCH 0/9] staging: octeon: multi rx group (queue) support

Aaro Koskinen wrote: > Oops, looks like I tested without CONFIG_NET_POLL_CONTROLLER enabled > and that seems to be broken. Sorry. I'm not using CONFIG_NET_POLL_CONTROLLER either; the problem is in the normal cvm_oct_napi_poll() path. Here's my workaround: ---

Re: [PATCH] xenbus: don't look up transaction IDs for ordinary writes

On Tue, Aug 16, 2016 at 3:07 AM, Juergen Gross wrote: > On 15/08/16 17:02, Jan Beulich wrote: >> This should really only be done for XS_TRANSACTION_END messages, or >> else at least some of the xenstore-* tools don't work anymore. >> >> Fixes: 0beef634b8 ("xenbus: don't BUG() on

Disable all network protocols on an interface?

I have a Linux kernel 4.4 system hosting a number of kvm VMs. Physical interface eth0 connects to an 802.1Q trunk port on an external switch. Each VM has a virtual interface (e1000 or virtio-net) connected to the physical NIC through a macvtap interface and a VLAN interface; traffic between the

[PATCH] thermal: intel_pch_thermal: Fix enable check on Broadwell-DE

to configure it, and the dynamic shutdown state should not prevent the driver from loading. The ETS flag itself indicates whether the thermal sensor is enabled, so use it instead of the TSDSS flag on all hardware platforms. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> --- drivers/t

[PATCH] thermal: intel_pch_thermal: Read large temp values correctly

On all supported platforms, the TS Reading (TSR) field in the Temperature (TEMP) register is 9 bits wide. Values above 0x100 (78 degrees C) are plausible, so don't mask out the topmost bit. And the register itself is 16 bits wide, so use readw() rather than readl(). Signed-off-by: Ed Swierk <e

Which came first, hard kernel lockup or SATA errors?

I'm trying to untangle a series of problems that suddenly occurred on a dual-socket Xeon server system that had been running a bunch of KVM workloads just fine for over 6 weeks (4.4.52-grsec kernel, Debian-derived userspace). Here are the highlights, with timestamps in seconds: [3851435] NMI

Re: Which came first, hard kernel lockup or SATA errors?

Continuing the conversation with the voices in my head... On Mon, Oct 9, 2017 at 10:45 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > Based on the addresses in the stack and registers, here's what I think > happened. > > On cpu 13: > > - task_numa_fault() calls ta

sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

Ping for Peter, Ingo and other sched maintainers: I'd appreciate any feedback on this hard lockup issue, which occurred on a system running kernel 4.4.52-grsec. To recap: a dual-socket Xeon (E5 v4) server system had been running a bunch of KVM workloads just fine for over 6 weeks. Suddenly hard

Re: Which came first, hard kernel lockup or SATA errors?

On Fri, Oct 6, 2017 at 6:25 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > I'm trying to untangle a series of problems that suddenly occurred on > a dual-socket Xeon server system that had been running a bunch of KVM > workloads just fine for over 6 weeks (4.4.52-grsec k

Re: sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

to reproduce the problem with an upstream kernel or any other, yet to my limited understanding of the evidence it appears there may indeed be a real problem lurking in there. I will follow up with the grsec folks. > On Thu, Nov 2, 2017 at 5:51 PM, Ed Swierk <eswi...@skyportsystems.com>

Re: sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

Ping? On Wed, Oct 25, 2017 at 9:35 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > > Ping? > > On Mon, Oct 16, 2017 at 4:11 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > > > > Ping for Peter, Ingo and other sched maintainers: > > > >

Re: sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

On Mon, Oct 16, 2017 at 4:11 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > To recap: a dual-socket Xeon (E5 v4) server system had been running a > bunch of KVM workloads just fine for over 6 weeks. Suddenly hard > lockups occurred on cpu 13 in task_numa_migrate(), and cpu 0 in

Re: sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

Ping? On Mon, Oct 16, 2017 at 4:11 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > > Ping for Peter, Ingo and other sched maintainers: > > I'd appreciate any feedback on this hard lockup issue, which occurred > on a system running kernel 4.4.52-grsec. > > To re

Longer command line for kexec on i386

I'm attempting to get kexec to pass a command line longer than 256 bytes to the new kernel, using kexec-tools-testing-20070330 and kernel 2.6.22.1. The new kernel is a bzImage, and I'm using kexec to tack on a command line and an initrd. I made the following change to kexec: ---

Re: Longer command line for kexec on i386

Ed Swierk arastra.com> writes: > I made the following change to kexec: > > [deleted] > > but I'm now seeing intermittent corruption of the initrd in the new kernel--a > few bytes at different locations each time. > > I suspect I've neglected some other important c

[PATCH] Configurable tap interface MTU

the value used by the e1000 driver, so it seems like a safe upper limit. Signed-off-by: Ed Swierk <[EMAIL PROTECTED]> --- tap-change-mtu.patch Description: Binary data

Re: [PATCH] Configurable tap interface MTU

On 9/11/07, Herbert Xu <[EMAIL PROTECTED]> wrote: > Please make it 65535 without an Ethernet header and 65521 > with an Ethernet header. Here is a revised patch that allows MTUs up to 65535 for tap interfaces and up to 65521 for tun interfaces. (If I set the MTU to 65521 on a tun interface, ping

[PATCH] forcedeth: power down phy when interface is down

Bring the physical link down when the interface is down, by placing the PHY in power-down state. This mirrors the behavior of other drivers including e1000 and tg3. Signed-off-by: Ed Swierk <[EMAIL PROTECTED]> forcedeth-phy-power-down.patch Description: Binary data

[PATCH] forcedeth: "no link" is informational

Log "no link during initialization" at KERN_INFO as it's not an error, and occurs every time the interface comes up (when the forcedeth-phy-power-down patch is applied). Signed-off-by: Ed Swierk <[EMAIL PROTECTED]> forcedeth-open-no-link-printk.patch Description: Binary data

[updated PATCH] forcedeth: power down phy when interface is down

On 9/19/07, Ayaz Abdulla <[EMAIL PROTECTED]> wrote: > It seems that you are powering down the phy even if WOL is enabled. Right; I've updated the patch to skip powering down the phy when wol is enabled. > Secondly, can you powerdown the phy at the same time you start > performing autoneg

Which came first, hard kernel lockup or SATA errors?

I'm trying to untangle a series of problems that suddenly occurred on a dual-socket Xeon server system that had been running a bunch of KVM workloads just fine for over 6 weeks (4.4.52-grsec kernel, Debian-derived userspace). Here are the highlights, with timestamps in seconds: [3851435] NMI

sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

Ping for Peter, Ingo and other sched maintainers: I'd appreciate any feedback on this hard lockup issue, which occurred on a system running kernel 4.4.52-grsec. To recap: a dual-socket Xeon (E5 v4) server system had been running a bunch of KVM workloads just fine for over 6 weeks. Suddenly hard

Re: sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

Ping? On Wed, Oct 25, 2017 at 9:35 PM, Ed Swierk wrote: > > Ping? > > On Mon, Oct 16, 2017 at 4:11 PM, Ed Swierk wrote: > > > > Ping for Peter, Ingo and other sched maintainers: > > > > I'd appreciate any feedback on this hard lockup issue, which occ

Re: sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

ream kernel or any other, yet to my limited understanding of the evidence it appears there may indeed be a real problem lurking in there. I will follow up with the grsec folks. > On Thu, Nov 2, 2017 at 5:51 PM, Ed Swierk wrote: >> Ping? >> >> On Wed, Oct 25, 2017 at 9:35

[PATCH] thermal: intel_pch_thermal: Fix enable check on Broadwell-DE

to configure it, and the dynamic shutdown state should not prevent the driver from loading. The ETS flag itself indicates whether the thermal sensor is enabled, so use it instead of the TSDSS flag on all hardware platforms. Signed-off-by: Ed Swierk --- drivers/thermal/intel_pch_thermal.c | 4 ++-- 1 file

[PATCH] thermal: intel_pch_thermal: Read large temp values correctly

On all supported platforms, the TS Reading (TSR) field in the Temperature (TEMP) register is 9 bits wide. Values above 0x100 (78 degrees C) are plausible, so don't mask out the topmost bit. And the register itself is 16 bits wide, so use readw() rather than readl(). Signed-off-by: Ed Swierk

Re: sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

On Mon, Oct 16, 2017 at 4:11 PM, Ed Swierk wrote: > To recap: a dual-socket Xeon (E5 v4) server system had been running a > bunch of KVM workloads just fine for over 6 weeks. Suddenly hard > lockups occurred on cpu 13 in task_numa_migrate(), and cpu 0 in > idle_balance(). That conditi

Re: Which came first, hard kernel lockup or SATA errors?

On Fri, Oct 6, 2017 at 6:25 PM, Ed Swierk wrote: > I'm trying to untangle a series of problems that suddenly occurred on > a dual-socket Xeon server system that had been running a bunch of KVM > workloads just fine for over 6 weeks (4.4.52-grsec kernel, > Debian-derived userspace).

Re: Which came first, hard kernel lockup or SATA errors?

Continuing the conversation with the voices in my head... On Mon, Oct 9, 2017 at 10:45 PM, Ed Swierk wrote: > Based on the addresses in the stack and registers, here's what I think > happened. > > On cpu 13: > > - task_numa_fault() calls task_numa_migrate(), which selects the

Re: sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

Ping? On Mon, Oct 16, 2017 at 4:11 PM, Ed Swierk wrote: > > Ping for Peter, Ingo and other sched maintainers: > > I'd appreciate any feedback on this hard lockup issue, which occurred > on a system running kernel 4.4.52-grsec. > > To recap: a dual-socket Xeon (E5 v4) s

[PATCH] ethtool: Extend ethtool plugin module eeprom API to phylib

call the equivalent ethtool_ops functions provided by network drivers with built-in phy support. Signed-off-by: Ed Swierk --- include/linux/phy.h | 9 + net/core/ethtool.c | 45 ++--- 2 files changed, 43 insertions(+), 11 deletions(-) diff --git

Re: [PATCH 0/9] staging: octeon: multi rx group (queue) support

Hi Aaro, On Tue, Aug 30, 2016 at 11:47 AM, Aaro Koskinen wrote: > This series implements multiple RX group support that should improve > the networking performance on multi-core OCTEONs. Basically we register > IRQ and NAPI for each group, and ask the HW to select the group for > the incoming

Re: [PATCH 0/9] staging: octeon: multi rx group (queue) support

Aaro Koskinen wrote: > Oops, looks like I tested without CONFIG_NET_POLL_CONTROLLER enabled > and that seems to be broken. Sorry. I'm not using CONFIG_NET_POLL_CONTROLLER either; the problem is in the normal cvm_oct_napi_poll() path. Here's my workaround: ---

Disable all network protocols on an interface?

I have a Linux kernel 4.4 system hosting a number of kvm VMs. Physical interface eth0 connects to an 802.1Q trunk port on an external switch. Each VM has a virtual interface (e1000 or virtio-net) connected to the physical NIC through a macvtap interface and a VLAN interface; traffic between the

Re: [PATCH 0/9] staging: octeon: multi rx group (queue) support

On 8/31/16 14:20, Aaro Koskinen wrote: > On Wed, Aug 31, 2016 at 09:20:07AM -0700, Ed Swierk wrote: >> Here's my workaround: > > [...] > >> -static int cvm_oct_poll(struct oct_rx_group *rx_group, int budget) >> +static int cvm_oct_poll(int group, int budget) >&g

Re: [PATCH v2 00/11] staging: octeon: multi rx group (queue) support

On 8/31/16 13:57, Aaro Koskinen wrote: > This series implements multiple RX group support that should improve > the networking performance on multi-core OCTEONs. Basically we register > IRQ and NAPI for each group, and ask the HW to select the group for > the incoming packets based on hash. > >

Re: [PATCH] xenbus: don't look up transaction IDs for ordinary writes

On Tue, Aug 16, 2016 at 3:07 AM, Juergen Gross wrote: > On 15/08/16 17:02, Jan Beulich wrote: >> This should really only be done for XS_TRANSACTION_END messages, or >> else at least some of the xenstore-* tools don't work anymore. >> >> Fixes: 0beef634b8 ("xenbus: don't BUG() on user mode induced

Re: [PATCH v7 3/5] tpm: Clean up reading of timeout and duration capabilities

On Mon, Jun 20, 2016 at 6:54 PM, Ed Swierk wrote: > --- a/drivers/char/tpm/tpm-interface.c > +++ b/drivers/char/tpm/tpm-interface.c > @@ -461,9 +461,19 @@ ssize_t tpm_getcap(struct device *dev, __be32 subcap_id, > cap_t *cap, > tpm_cmd.params.getcap_in.subcap_size

[PATCH v8 1/5] tpm_tis: Improve reporting of IO errors

Mysterious TPM behavior can be difficult to track down through all the layers of software. Add error messages for conditions that should never happen. Also include the manufacturer ID along with other chip data printed during init. Signed-off-by: Ed Swierk Reviewed-by: Jarkko Sakkinen

[PATCH v8 4/5] tpm: Allow TPM chip drivers to override reported command durations

-by: Ed Swierk --- drivers/char/tpm/tpm-interface.c | 143 +-- drivers/char/tpm/tpm_tis.c | 35 +++--- include/linux/tpm.h | 3 +- 3 files changed, 88 insertions(+), 93 deletions(-) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers

[PATCH v8 0/5] tpm: Command duration logging and chip-specific override

both timeouts and durations via a single callback. This series - improves TPM command error reporting - adds optional logging of TPM command durations - allows chip-specific override of command durations as well as protocol timeouts - overrides ST19NP18 TPM command duration to avoid lockups Ed

[PATCH v8 2/5] tpm: Add optional logging of TPM command durations

red with DYNAMIC_DEBUG=y. Signed-off-by: Ed Swierk Reviewed-by: Jarkko Sakkinen --- drivers/char/tpm/tpm-interface.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index c50637d..cc1e5bc 100

[PATCH v8 3/5] tpm: Clean up reading of timeout and duration capabilities

Call tpm_getcap() from tpm_get_timeouts() to eliminate redundant code. Return all errors to the caller rather than swallowing them (e.g. when tpm_transmit_cmd() returns nonzero). Signed-off-by: Ed Swierk --- drivers/char/tpm/tpm-interface.c | 74 +++- 1 file

[PATCH v8 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

hether any commands are immune to being blocked by this process. So it seems safest to ignore the chip's reported command durations, and use a value much higher than any observed duration, like 180 sec (which is the duration this chip reports for "long" commands). Signed-off-by: Ed Swierk -

[PATCH v9 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

hether any commands are immune to being blocked by this process. So it seems safest to ignore the chip's reported command durations, and use a value much higher than any observed duration, like 180 sec (which is the duration this chip reports for "long" commands). Signed-off-by: Ed Swierk -

[PATCH v9 1/5] tpm_tis: Improve reporting of IO errors

Mysterious TPM behavior can be difficult to track down through all the layers of software. Add error messages for conditions that should never happen. Also include the manufacturer ID along with other chip data printed during init. Signed-off-by: Ed Swierk Reviewed-by: Jarkko Sakkinen

[PATCH v9 0/5] tpm: Command duration logging and chip-specific override

-specific override of command durations as well as protocol timeouts - overrides ST19NP18 TPM command duration to avoid lockups Ed Swierk (5): tpm_tis: Improve reporting of IO errors tpm: Add optional logging of TPM command durations tpm: Clean up reading of timeout and duration capabilities

[PATCH v9 4/5] tpm: Allow TPM chip drivers to override reported command durations

-by: Ed Swierk --- drivers/char/tpm/tpm-interface.c | 148 ++- drivers/char/tpm/tpm_tis_core.c | 32 +++-- include/linux/tpm.h | 3 +- 3 files changed, 94 insertions(+), 89 deletions(-) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers

  1   2   >