On Fri, 2011-09-09 at 05:19 -0700, aopfer@bennett-electric.com wrote:
> Sure thing Ben:
>
> http://pastebin.com/JJ8g4Mmr

This isn't IRC; please include the information directly.

So the content of that file is:

> CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
> 0: 52 52 289 16409 6312192 50123287 IO-APIC-edge timer
> 1: 0 0 0 0 0 2 IO-APIC-edge i8042
> 4: 0 0 0 0 0 6 IO-APIC-edge
> 7: 1 0 0 0 0 0 IO-APIC-edge
> 8: 0 0 0 0 0 1 IO-APIC-edge rtc0
> 9: 0 0 0 0 0 0 IO-APIC-fasteoi acpi
> 12: 0 0 0 0 0 4 IO-APIC-edge i8042
> 14: 0 0 0 0 0 0 IO-APIC-edge pata_atiixp
> 15: 0 0 0 0 0 0 IO-APIC-edge pata_atiixp
> 16: 7 42 157 6961 542243 38981480 IO-APIC-fasteoi ohci_hcd:usb3, ohci_hcd:usb4, HDA Intel
> 17: 0 0 0 0 0 4 IO-APIC-fasteoi pata_marvell, ehci_hcd:usb1
> 18: 0 0 0 0 0 3 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7
> 19: 0 0 0 1 46 2654 IO-APIC-fasteoi firewire_ohci, ehci_hcd:usb2, HDA Intel
> 28: 0 3 10 903 43432 3718580 PCI-MSI-edge ahci
> 29: 47 360 1910 23913 1491588 188573162 PCI-MSI-edge eth0
> 30: 0 0 0 0 0 51 PCI-MSI-edge fglrx[0]@PCI:1:0:0
> NMI: 0 0 0 0 0 0 Non-maskable interrupts
> LOC: 18486745 11884756 9097094 7788478 3638744 12142838 Local timer interrupts
> SPU: 0 0 0 0 0 0 Spurious interrupts
> PMI: 0 0 0 0 0 0 Performance monitoring interrupts
> PND: 0 0 0 0 0 0 Performance pending work
> RES: 9495193 4667612 3159014 2932106 1837591 401851 Rescheduling interrupts
> CAL: 2280 2584 2499 2299 2449 2669 Function call interrupts
> TLB: 165401 206844 265508 388676 233869 273091 TLB shootdowns
> TRM: 0 0 0 0 0 0 Thermal event interrupts
> THR: 0 0 0 0 0 0 Threshold APIC interrupts
> MCE: 0 0 0 0 0 0 Machine check exceptions
> MCP: 569 569 569 569 569 569 Machine check polls
> ERR: 1
> MIS: 0

and there are several devices using IRQ 19. All of them have
widely-used drivers that are unlikely to have a major bug in interrupt
management. I'll have to think about this.

Ben.

--
Ben Hutchings
I say we take off; nuke the site from orbit. It's the only way to be sure.

I figured I'd give this an update: I recently downloaded and installed the
r8168 module from realtek after investigating a different issue involving
network transmission speeds and it solved both issues (also, I can actually
set the MTU to 9000 now). I'll admit to there being a gap in my
understanding here: is there a reason why the r8168 isn't chosen for my set
of hardware? It looks like it isn't included in Debian at all. It's a wonder
I've been running the wrong module all this time!


The full identifier of my ethernet card in lspci is:
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B
PCI Express Gigabit Ethernet controller (rev 03)


Aaron Opfer

--------------------------------------------------
From: "Ben Hutchings" <ben@decadent.org.uk>
Sent: Friday, September 09, 2011 7:58 AM
To: <aopfer@bennett-electric.com>
Cc: <637122@bugs.debian.org>
Subject: RE: Bug#637122: general: Realtek RTL8111 with r8169 module causes
kernel panic on large packets





--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 396AE1716C6442A3B9832F0DADD6DBED@BENNETT">http://lists.debian.org/396AE1716C6442A3B9832F0DADD6DBED@BENNETT

On Tue, Nov 15, 2011 at 01:11:16PM -0500, Aaron Opfer wrote:
> I figured I'd give this an update: I recently downloaded and
> installed the r8168 module from realtek after investigating a
> different issue involving network transmission speeds and it solved
> both issues (also, I can actually set the MTU to 9000 now). I'll
> admit to there being a gap in my understanding here: is there a
> reason why the r8168 isn't chosen for my set of hardware? It looks
> like it isn't included in Debian at all. It's a wonder I've been
> running the wrong module all this time!
[...]

It's not the wrong module. If it didn't support your hardware then it
wouldn't do anything at all.

When Realtek started making chips in the RTL81xx family that attached
to the PCI Express (rather than classic PCI) bus they branched the
driver, with r8169 supporting the old chips and r8168 the new. But
the drivers have a lot of common code. In mainline Linux, support for
the new chips was added to r8169 instead.

All that said, r8168 probably has some fixes that mainline r8169 does
not (yet).

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111115182731.GA3366@decadent.org.uk">http://lists.debian.org/20111115182731.GA3366@decadent.org.uk