Re: List of Networking enhancements and bug fixes in a particular release

On Thu, Jun 14, 2018 at 1:21 PM, Joe Smith wrote: > > What is the best and authoritative mechanism to find out networking > enhancements in a Linux release? > Joe, there usually is a good summary a few days after a kernel release on the Kernel Newbies site. Here is a recent one:

3c59x: Transmit timeouts

Steffen, I am getting mostly transmit errors on a 3c597 Fast Ethernet card. It is EISA, not PCI. Here is some of the logs with verbosity turned up a bit: eth3: using default media 100baseTX [372] eth3: Initial media type 100baseTX. eth3: setting half-duplex. [372] eth3: vortex_up() irq 9 media

Re: [PATCH net] 8139too: revisit napi_complete_done() usage

On Mon, Sep 18, 2017 at 11:57 PM, David Miller wrote: > From: Eric Dumazet > Date: Mon, 18 Sep 2017 13:03:43 -0700 > >> From: Eric Dumazet >> >> It seems we have to be more careful in napi_complete_done() >> use. This patch is

Re: [PATCHv3] 3c59x: fix missing dma_mapping_error check and bad ring refill logic

On Wed, Jan 3, 2018 at 1:44 PM, David Miller wrote: > From: Neil Horman > Date: Wed, 3 Jan 2018 13:09:23 -0500 > >> A few spots in 3c59x missed calls to dma_mapping_error checks, casuing >> WARN_ONS to trigger. Clean those up. While we're at it,

3c59x: pci_unmap_single() oops

In the 4.15.0-rc5 kernel (and likely earlier) I get the following oops. 3c59x :00:0c.0 enp0s12: renamed from eth0 enp0s12: setting half-duplex. [ cut here ] 3c59x :00:0c.0: DMA-API: device driver failed to check map error[device address=0x09e1b040]

Re: Thoughts on staging and on fixing up drivers?

> > Larry, you've migrated a bunch of staging code, and tried various > approaches. Do you have any lessons on what has worked and what hasn't > and if there is anything we can do to make the process better? I am also quite interested in such work. We asked for a Birds of Feather discussion at

Re: [regression v4.11] 617f01211baf ("8139too: use napi_complete_done()")

On Sat, Apr 8, 2017 at 6:23 AM, Francois Romieu wrote: > David Miller : > [...] >> One theory is that the interrupt masking isn't working properly >> and interrupts are still arriving and hitting the NAPI state even >> when we are actively polling NAPI.