Re: tg3 kernel bug in 2.6.18-mm3 and 2.6.19-rc2-mm2
On Sat, 21 Oct 2006 12:38:14 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Norbert Preining [EMAIL PROTECTED] Date: Sat, 21 Oct 2006 15:22:39 +0200 [c010469d] dump_stack+0x12/0x14 [c0141cb3] softlockup_tick+0xaa/0xc1 [c0129bad] update_process_times+0x3b/0x5e [c01362a1] handle_update_profile+0x14/0x1e [c0115956] smp_apic_timer_interrupt+0x49/0x5b [c0103998] apic_timer_interrupt+0x28/0x30 DWARF2 unwinder stuck at apic_timer_interrupt+0x28/0x30 Leftover inexact backtrace: [c01d03af] delay_tsc+0xb/0x13 [c01d03e0] __delay+0x6/0x7 It's OOPS'ing by softlockup'ing in udelay() and then we get a corrupt backtrace. The unwinder-based backtrace is screwed up (yet again) but the old-style backtrace is there, in all its messy glory. Weeding out the crap, I think it's this: [c01d03af] delay_tsc+0xb/0x13 [c01d03e0] __delay+0x6/0x7 [c022c240] _tw32_flush+0x3f/0x51 [c022da97] tg3_switch_clocks+0x8f/0x93 I assume tg3_init_hw() got inlined [c0237673] tg3_open+0x250/0x520 [c02d3263] dev_open+0x2b/0x62 [c02d1dd8] dev_change_flags+0x47/0xe4 [c0307fcc] devinet_ioctl+0x252/0x556 [c02d2e5a] dev_ifsioc+0x113/0x38d [c02d29c4] dev_load+0x24/0x4b [c02c9265] sock_ioctl+0x19e/0x1c2 It's strange that the post-2.6.19-rc2 changes triggered this - that code won't have run yet. Norbert, are you really sure? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/1] r8169 driver: corega support
I demand that Francois Romieu may or may not have written... Darren Salt [EMAIL PROTECTED] : [...] It does, but the patch causes the module to report that the reset failed even after reporting that it's done. A fix for this is attached. Oops. Ok with the one below? Yes. [snip patch] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Output less CO2 = avoid massive flooding.TIME IS RUNNING OUT *FAST*. Wagner's music is better than it sounds. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] net: correct-Traffic-shaper-Kconfig
kconfig, correct traffic shaper CBQ is no longer experimental and is located in other subtree. Signed-off-by: Jiri Slaby [EMAIL PROTECTED] --- commit 5ee1f6ff7e1f03ed8edb2461612346e9964b745d tree debfe70d8c8338adb5ef1d860b07e4a00e760081 parent a3d771ef92954ce81363af9e0252490e2741fc21 author Jiri Slaby [EMAIL PROTECTED] Sun, 22 Oct 2006 17:34:59 +0159 committer Jiri Slaby [EMAIL PROTECTED] Sun, 22 Oct 2006 17:34:59 +0159 drivers/net/Kconfig |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 0a999a8..e845df9 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2842,9 +2842,9 @@ config SHAPER these virtual devices. See file:Documentation/networking/shaper.txt for more information. - An alternative to this traffic shaper is the experimental - Class-Based Queuing (CBQ) scheduling support which you get if you - say Y to QoS and/or fair queuing above. + An alternative to this traffic shaper is the Class-Based Queuing + (CBQ) scheduling support which you get if you say Y to + QoS and/or fair queuing in Networking options. To compile this driver as a module, choose M here: the module will be called shaper. If unsure, say N. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tg3 kernel bug in 2.6.18-mm3 and 2.6.19-rc2-mm2
Hi all! On Sam, 21 Okt 2006, Michael Chan wrote: 2.6.19-rc2 works 2.6.19-rc2+patch does not work It doesn't make any sense. This patch is totally benign and cannot cause the No firmware running and lockup that you reported. Can you please double-check? Ok, I cannot reproduce it anymore. No idea why it happened. ANyway, with my current rc2+tg3 patch I have no problems, while with rc2-mm2 I have the problems. Best wishes Norbert --- Dr. Norbert Preining [EMAIL PROTECTED]Università di Siena Debian Developer [EMAIL PROTECTED] Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- SHENANDOAH (n.) The infinite smugness of one who knows they are entitled to a place in a nuclear bunker. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Strange errors from e1000 driver (2.6.18)
I'm getting a lot of these type of errors if I run 2.6.18. If I run the standard Ubuntu Dapper kernel, I don't get them. What do they indicate? Oct 21 18:48:28 localhost kernel: buffer_info[next_to_clean] Oct 21 18:48:28 localhost kernel: time_stamp 7b79d33 Oct 21 18:48:28 localhost kernel: next_to_watch3d Oct 21 18:48:28 localhost kernel: jiffies 7b7a0c1 Oct 21 18:48:28 localhost kernel: next_to_watch.status 0 Oct 21 18:48:30 localhost kernel: Tx Queue 0 Oct 21 18:48:30 localhost kernel: TDH 3d Oct 21 18:48:30 localhost kernel: TDT 44 Oct 21 18:48:30 localhost kernel: next_to_use 44 Oct 21 18:48:30 localhost kernel: next_to_clean39 Oct 21 18:48:30 localhost kernel: buffer_info[next_to_clean] Oct 21 18:48:30 localhost kernel: time_stamp 7b79d33 Oct 21 18:48:30 localhost kernel: next_to_watch3d Oct 21 18:48:30 localhost kernel: jiffies 7b7a2b5 Oct 21 18:48:30 localhost kernel: next_to_watch.status 0 Oct 21 18:48:32 localhost kernel: Tx Queue 0 Oct 21 18:48:32 localhost kernel: TDH 3d Oct 21 18:48:32 localhost kernel: TDT 44 Oct 21 18:48:32 localhost kernel: next_to_use 44 Oct 21 18:48:32 localhost kernel: next_to_clean39 Oct 21 18:48:32 localhost kernel: buffer_info[next_to_clean] Oct 21 18:48:32 localhost kernel: time_stamp 7b79d33 Oct 21 18:48:32 localhost kernel: next_to_watch3d Oct 21 18:48:32 localhost kernel: jiffies 7b7a4a9 Oct 21 18:48:32 localhost kernel: next_to_watch.status 0 Oct 21 18:48:34 localhost kernel: Tx Queue 0 Oct 21 18:48:34 localhost kernel: TDH 3d Oct 21 18:48:34 localhost kernel: TDT 44 Oct 21 18:48:34 localhost kernel: next_to_use 44 Oct 21 18:48:34 localhost kernel: next_to_clean39 Oct 21 18:48:34 localhost kernel: buffer_info[next_to_clean] Oct 21 18:48:34 localhost kernel: time_stamp 7b79d33 Oct 21 18:48:34 localhost kernel: next_to_watch3d Oct 21 18:48:34 localhost kernel: jiffies 7b7a69d Oct 21 18:48:34 localhost kernel: next_to_watch.status 0 Oct 21 18:48:35 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out Oct 21 18:48:36 localhost kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tg3 kernel bug in 2.6.18-mm3 and 2.6.19-rc2-mm2
Hi all! Ok, you will lough at me... On Son, 22 Okt 2006, preining wrote: 2.6.19-rc2works 2.6.19-rc2+patch does not work It doesn't make any sense. This patch is totally benign and cannot cause the No firmware running and lockup that you reported. Can you please double-check? Ok, I cannot reproduce it anymore. No idea why it happened. And again I can reporduce it. How, (again, please don't lough): I booted into windows (sometimes one has too, contract from the EC with macros in Excel tables ... grrr). WinXP didn't mange to get an IP address from my cable modem. Rebooting into linux, same problem as reported, and, but no idea whether this is related: the modem just looses sync and need several resets until it find back into syncronization. I will do some more experiments with Win-different linux kernel switching. Sorry for the chaos, no idea what has happened here!!! Best wishes Norbert --- Dr. Norbert Preining [EMAIL PROTECTED]Università di Siena Debian Developer [EMAIL PROTECTED] Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- `We've got to find out what people want from fire, how they relate to it, what sort of image it has for them.' The crowd were tense. They were expecting something wonderful from Ford. `Stick it up your nose,' he said. `Which is precisely the sort of thing we need to know,' insisted the girl, `Do people want fire that can be fitted nasally?' --- Ford debating what to do with fire with a marketing --- girl. --- Douglas Adams, The Hitchhikers Guide to the Galaxy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Fw: [Bugme-new] [Bug 7398] New: Preferred source address selection (src field) broken with multicast addresses
Begin forwarded message:
Date: Sun, 22 Oct 2006 05:28:33 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 7398] New: Preferred source address selection (src
field) broken with multicast addresses
http://bugzilla.kernel.org/show_bug.cgi?id=7398
Summary: Preferred source address selection (src field) broken
with multicast addresses
Kernel Version: 2.6.18
Status: NEW
Severity: low
Owner: [EMAIL PROTECTED]
Submitter: [EMAIL PROTECTED]
Most recent kernel where this bug did not occur: unchecked
Distribution: Debian (unstable)
Hardware Environment: Pentium IV/M/MMX
Software Environment: iproute2-ss060323, VLC 0.8.6 Janus
Problem Description:
Output packets to a multicast destination address are not routed properly if
the matched route features a preferred source address src field: packets are
output through the device corresponding to the src field, instead of the
device that would normally be used.
Steps to reproduce:
(0. Assume eth0 is up and working.)
1. Set up another interface, for instance:
modprobe dummy
ip ad add 10.0.0.1 dummy0
ip link set dummy0 up
2. Set up a route with source address preference:
ip ro add 239.255.1.2 dev eth0 src 10.0.0.1
3. Send packets to multicast address, for instance:
vlc -Irc la_question.mp3 --sout '#std{access=udp,mux=ts,dst=239.255.1.2:1234}'
Packets will go out through dummy0 instead of expected eth0.
Interestingly enough, net/ipv4/route.c contains the following (from line 2419):
if (oldflp-oif == 0
(MULTICAST(oldflp-fl4_dst) || oldflp-fl4_dst == 0x)) {
/* Special hack: user can direct multicasts
and limited broadcast via necessary interface
without fiddling with IP_MULTICAST_IF or IP_PKTINFO.
This hack is not just for fun, it allows
vic,vat and friends to work.
They bind socket to loopback, set ttl to zero
and expect that it will work.
From the viewpoint of routing cache they are broken,
because we are not allowed to build multicast path
with loopback source addr (look, routing cache
cannot know, that ttl is zero, so that packet
will not leave this host and route is valid).
Luckily, this hack is good workaround.
*/
fl.oif = dev_out-ifindex;
goto make_route;
}
Commenting that code out gets the kernel to route packets back in the expected
way (that is, in the previous example, through eth0 with source address
10.0.0.1).
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/8] sundance: remove TxStartThresh and RxEarlyThresh
On Fri, Oct 20, 2006 at 02:42:05PM -0700, [EMAIL PROTECTED] wrote:
From: Jesse Huang [EMAIL PROTECTED]
For patent issue need to remove TxStartThresh and RxEarlyThresh. This patent
is cut-through patent. If use this function, Tx will start to transmit after
few data be move in to Tx FIFO. We are not allow to use those function in
DFE530/DFE550/DFE580/DL10050/IP100/IP100A. It will decrease a little
performance.
[...]
@@ -,6 +1109,7 @@ static irqreturn_t intr_handler(int irq,
int tx_cnt;
int tx_status;
int handled = 0;
+ int i;
What the use here of adding this variable ? Is that actually a part of another
patch ?
do {
@@ -1153,17 +1152,14 @@ static irqreturn_t intr_handler(int irq,
np-stats.tx_fifo_errors++;
if (tx_status 0x02)
np-stats.tx_window_errors++;
+
/*
** This reset has been verified on
** DFE-580TX boards ! [EMAIL PROTECTED]
*/
if (tx_status 0x10) { /* TxUnderrun */
- unsigned short txthreshold;
-
- txthreshold = ioread16 (ioaddr
+ TxStartThresh);
/* Restart Tx FIFO and
transmitter */
sundance_reset(dev,
(NetworkReset|FIFOReset|TxReset) 16);
- iowrite16 (txthreshold, ioaddr
+ TxStartThresh);
I must be dense, but I do not understand how merely preserving the value of
a register across a reset can infringe on any patent
Philippe
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Strange errors from e1000 driver (2.6.18)
Martin J. Bligh wrote: I'm getting a lot of these type of errors if I run 2.6.18. If I run the standard Ubuntu Dapper kernel, I don't get them. What do they indicate? Oct 21 18:48:28 localhost kernel: buffer_info[next_to_clean] Oct 21 18:48:28 localhost kernel: time_stamp 7b79d33 Oct 21 18:48:28 localhost kernel: next_to_watch3d Oct 21 18:48:28 localhost kernel: jiffies 7b7a0c1 Oct 21 18:48:28 localhost kernel: next_to_watch.status 0 Oct 21 18:48:30 localhost kernel: Tx Queue 0 Oct 21 18:48:30 localhost kernel: TDH 3d Oct 21 18:48:30 localhost kernel: TDT 44 Oct 21 18:48:30 localhost kernel: next_to_use 44 Oct 21 18:48:30 localhost kernel: next_to_clean39 Oct 21 18:48:30 localhost kernel: buffer_info[next_to_clean] Oct 21 18:48:30 localhost kernel: time_stamp 7b79d33 Oct 21 18:48:30 localhost kernel: next_to_watch3d Oct 21 18:48:30 localhost kernel: jiffies 7b7a2b5 Oct 21 18:48:30 localhost kernel: next_to_watch.status 0 Oct 21 18:48:32 localhost kernel: Tx Queue 0 Oct 21 18:48:32 localhost kernel: TDH 3d Oct 21 18:48:32 localhost kernel: TDT 44 Oct 21 18:48:32 localhost kernel: next_to_use 44 Oct 21 18:48:32 localhost kernel: next_to_clean39 Oct 21 18:48:32 localhost kernel: buffer_info[next_to_clean] Oct 21 18:48:32 localhost kernel: time_stamp 7b79d33 Oct 21 18:48:32 localhost kernel: next_to_watch3d Oct 21 18:48:32 localhost kernel: jiffies 7b7a4a9 Oct 21 18:48:32 localhost kernel: next_to_watch.status 0 Oct 21 18:48:34 localhost kernel: Tx Queue 0 Oct 21 18:48:34 localhost kernel: TDH 3d Oct 21 18:48:34 localhost kernel: TDT 44 Oct 21 18:48:34 localhost kernel: next_to_use 44 Oct 21 18:48:34 localhost kernel: next_to_clean39 Oct 21 18:48:34 localhost kernel: buffer_info[next_to_clean] Oct 21 18:48:34 localhost kernel: time_stamp 7b79d33 Oct 21 18:48:34 localhost kernel: next_to_watch3d Oct 21 18:48:34 localhost kernel: jiffies 7b7a69d Oct 21 18:48:34 localhost kernel: next_to_watch.status 0 Oct 21 18:48:35 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out Oct 21 18:48:36 localhost kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex Actually, maybe this set is more helpful: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue 0 TDH 6 TDT 1f next_to_use 1f next_to_clean2 buffer_info[next_to_clean] time_stamp 2de8b54 next_to_watch6 jiffies 2de8db7 next_to_watch.status 0 e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue 0 TDH 6 TDT 1f next_to_use 1f next_to_clean2 buffer_info[next_to_clean] time_stamp 2de8b54 next_to_watch6 jiffies 2de8fab next_to_watch.status 0 e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue 0 TDH 6 TDT 1f next_to_use 1f next_to_clean2 buffer_info[next_to_clean] time_stamp 2de8b54 next_to_watch6 jiffies 2de919f next_to_watch.status 0 NETDEV WATCHDOG: eth0: transmit timed out e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Strange errors from e1000 driver (2.6.18)
On 10/22/06, Martin J. Bligh [EMAIL PROTECTED] wrote: Martin J. Bligh wrote: I'm getting a lot of these type of errors if I run 2.6.18. If I run the standard Ubuntu Dapper kernel, I don't get them. What do they indicate? Hi Martin, they indicate that you're getting transmit hangs. Means your hardware is having issues with some of the buffers it is being handed. Because the TDH and TDT noted below are not equal, it means the hardware is hung processing buffers that the driver gave to it. We need the standard bug report particulars, lspci -vv, cat /proc/interrupts, dmesg, ethtool -e eth0, and maybe output of dmidecode, etc. I'm pretty sure you know the drill. Oct 21 18:48:28 localhost kernel: buffer_info[next_to_clean] Oct 21 18:48:28 localhost kernel: time_stamp 7b79d33 Oct 21 18:48:28 localhost kernel: next_to_watch3d Oct 21 18:48:28 localhost kernel: jiffies 7b7a0c1 Oct 21 18:48:28 localhost kernel: next_to_watch.status 0 Oct 21 18:48:30 localhost kernel: Tx Queue 0 Oct 21 18:48:30 localhost kernel: TDH 3d Oct 21 18:48:30 localhost kernel: TDT 44 Oct 21 18:48:30 localhost kernel: next_to_use 44 Oct 21 18:48:30 localhost kernel: next_to_clean39 snip Actually, maybe this set is more helpful: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue 0 TDH 6 TDT 1f next_to_use 1f next_to_clean2 buffer_info[next_to_clean] time_stamp 2de8b54 next_to_watch6 jiffies 2de8db7 next_to_watch.status 0 snip NETDEV WATCHDOG: eth0: transmit timed out e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex only a little. There are so many different pieces of e1000 hardware and so few specifics in this report that I'll be able to tell you lots more when you get us the info requested. Jesse - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Strange errors from e1000 driver (2.6.18)
Jesse Brandeburg wrote: On 10/22/06, Martin J. Bligh [EMAIL PROTECTED] wrote: Martin J. Bligh wrote: I'm getting a lot of these type of errors if I run 2.6.18. If I run the standard Ubuntu Dapper kernel, I don't get them. What do they indicate? Hi Martin, they indicate that you're getting transmit hangs. Means your hardware is having issues with some of the buffers it is being handed. Because the TDH and TDT noted below are not equal, it means the hardware is hung processing buffers that the driver gave to it. We need the standard bug report particulars, Sure. lspci -vv, :00:0a.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Con troller (Copper) (rev 01) Subsystem: Intel Corporation PRO/1000 MT Dual Port Server Adapter Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort - MAbort- SERR- PERR- Latency: 32 (63750ns min), Cache Line Size: 0x08 (32 bytes) Interrupt: pin A routed to IRQ 5 Region 0: Memory at ef02 (64-bit, non-prefetchable) [size=128K] Region 4: I/O ports at a000 [size=64] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot +,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [e4] Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: Data: :00:0a.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Con troller (Copper) (rev 01) Subsystem: Intel Corporation PRO/1000 MT Dual Port Server Adapter Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort - MAbort- SERR- PERR- Latency: 32 (63750ns min), Cache Line Size: 0x08 (32 bytes) Interrupt: pin B routed to IRQ 11 Region 0: Memory at ef00 (64-bit, non-prefetchable) [size=128K] Region 4: I/O ports at a400 [size=64] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot +,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [e4] Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: Data: cat /proc/interrupts, CPU0 0: 146271373 XT-PIC timer 1: 179459 XT-PIC i8042 2: 0 XT-PIC cascade 5:1975991 XT-PIC ehci_hcd:usb2, VIA8237, eth0 6: 2 XT-PIC floppy 10: 0 XT-PIC uhci_hcd:usb4, uhci_hcd:usb5, uhci_hcd:usb6 11: 0 XT-PIC ehci_hcd:usb1, uhci_hcd:usb3, uhci_hcd:usb7, uhci_hcd:usb8 12:2758142 XT-PIC i8042 14:6344745 XT-PIC ide0 15: 20014468 XT-PIC ide1 NMI: 0 LOC: 146264664 ERR: 52805 dmesg Did that bit already. ethtool -e eth0, [EMAIL PROTECTED]:/usr/local/autotest/bin # ethtool -e eth0 Offset Values -- -- 0x 00 07 e9 09 0b 08 30 05 ff ff ff ff ff ff ff ff 0x0010 44 a9 03 98 0b 46 11 10 86 80 10 10 86 80 68 34 0x0020 0c 00 10 10 00 00 02 21 c8 18 ff ff ff ff ff ff 0x0030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x0040 0c c3 61 78 04 50 02 21 c8 08 ff ff ff ff ff ff 0x0050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 02 06 0x0060 2c 00 00 40 07 11 00 00 2c 00 00 40 ff ff ff ff 0x0070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 4f 29 0x0080 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x0090 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x00a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x00b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x00c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x00d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x00e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x00f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x0100 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x0110 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x0120 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x0130 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x0140 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x0150 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x0160 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x0170 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x0180 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x0190 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Re: Strange errors from e1000 driver (2.6.18)
Analysis follows, but I wanted to ask you to bisect back if you can to find the apparent patch to make the difference. Basically at this point I'd say its not likely to be an e1000 issue, but I'd like to follow up and make sure. On 10/22/06, Martin J. Bligh [EMAIL PROTECTED] wrote: :00:0a.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Con troller (Copper) (rev 01) Latency: 32 (63750ns min), Cache Line Size: 0x08 (32 bytes) Interrupt: pin A routed to IRQ 5 Region 0: Memory at ef02 (64-bit, non-prefetchable) [size=128K] Region 4: I/O ports at a000 [size=64] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot +,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [e4] Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: Data: :00:0a.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Con troller (Copper) (rev 01) Subsystem: Intel Corporation PRO/1000 MT Dual Port Server Adapter Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort - MAbort- SERR- PERR- Latency: 32 (63750ns min), Cache Line Size: 0x08 (32 bytes) Interrupt: pin B routed to IRQ 11 Region 0: Memory at ef00 (64-bit, non-prefetchable) [size=128K] Region 4: I/O ports at a400 [size=64] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot +,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [e4] Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: Data: Nothing seems out of order, but the latency may be low, I'd be curious what these looked like before with the old kernel. Some of the other things to compare would have been the lspci -vv output from your chipset with old/new kernel, in case the bridge/system configuration changed. There are no known problems right now with this chipset 82546EB cat /proc/interrupts, CPU0 5:1975991 XT-PIC ehci_hcd:usb2, VIA8237, eth0 NMI: 0 LOC: 146264664 ERR: 52805 shared int, fine, but whats with the ERR: ? dmesg Did that bit already. except you didn't include any of the e1000 load information nor the system's boot information as it came up. ethtool -e eth0, [EMAIL PROTECTED]:/usr/local/autotest/bin # ethtool -e eth0 Offset Values -- -- 0x 00 07 e9 09 0b 08 30 05 ff ff ff ff ff ff ff ff 0x0010 44 a9 03 98 0b 46 11 10 86 80 10 10 86 80 68 34 0x0020 0c 00 10 10 00 00 02 21 c8 18 ff ff ff ff ff ff 0x0030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x0040 0c c3 61 78 04 50 02 21 c8 08 ff ff ff ff ff ff 0x0050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 02 06 0x0060 2c 00 00 40 07 11 00 00 2c 00 00 40 ff ff ff ff nothing out of order here that I can see immediately. and maybe output of dmidecode, etc. Attached. only a little. There are so many different pieces of e1000 hardware and so few specifics in this report that I'll be able to tell you lots more when you get us the info requested. Thanks. Not sure if the bug wasn't there in earlier kernels, or if we just weren't printing anything. I think it may not have been in earlier kernels, but I also don't think this is an e1000 problem, at least initially. snip BIOS Information Vendor: Phoenix Technologies, LTD Version: 6.00 PG Release Date: 09/13/2004 Address: 0xE Runtime Size: 128 kB ROM Size: 256 kB snip Handle 0x0001, DMI type 1, 25 bytes. System Information Manufacturer: VIA Technologies, Inc. Product Name: KT600-8237 Handle 0x0002, DMI type 2, 8 bytes. Base Board Information Manufacturer: Product Name: KT600-8237 Version: Serial Number: This chipset is one of the most frequent common elements in problem reports of TX hangs for e1000. My current theory (we've bought a bunch of these systems and never reproduced the issue) is that there is something either design specific or BIOS specific that causes this chipset to interact very badly with e1000 hardware. Some systems have the issue and some don't. If you could bisect back to a working point it would be interesting to see where that pointed. Handle 0x0004, DMI type 4, 32 bytes. Processor Information Socket Designation: Socket A Type: Central Processor Family: Athlon XP Manufacturer: AMD ID: A0 06 00 00 FF FB 83 03 Signature: Family 6,
Re: Strange errors from e1000 driver (2.6.18)
Jesse Brandeburg wrote: Analysis follows, but I wanted to ask you to bisect back if you can to find the apparent patch to make the difference. Basically at this point I'd say its not likely to be an e1000 issue, but I'd like to follow up and make sure. That's going to be ugly, since I can't reproduce it at will. Maybe if I netperf it to the other box I can push it over. Nothing seems out of order, but the latency may be low, I'd be curious what these looked like before with the old kernel. Some of the other things to compare would have been the lspci -vv output from your chipset with old/new kernel, in case the bridge/system configuration changed. There are no known problems right now with this chipset 82546EB OK. will try later when I have more time. For now I switched to the onboard via rhine controller. shared int, fine, but whats with the ERR: ? Hmm. Having rebooted they look rather lower. but might be a time thing. CPU0 0:1405995 XT-PIC timer 1: 5910 XT-PIC i8042 2: 0 XT-PIC cascade 5: 0 XT-PIC uhci_hcd:usb3 7: 27135 XT-PIC ehci_hcd:usb2, VIA8237, eth0 10: 0 XT-PIC uhci_hcd:usb4, uhci_hcd:usb5, uhci_hcd:usb6 11: 0 XT-PIC ehci_hcd:usb1, uhci_hcd:usb7, uhci_hcd:usb8 12: 157547 XT-PIC i8042 14: 36296 XT-PIC ide0 15: 196690 XT-PIC ide1 NMI: 0 LOC:1406006 ERR: 26 except you didn't include any of the e1000 load information nor the system's boot information as it came up. OK, it had gone since reboot, but I rebooted just now new info attached. This chipset is one of the most frequent common elements in problem reports of TX hangs for e1000. My current theory (we've bought a bunch of these systems and never reproduced the issue) is that there is something either design specific or BIOS specific that causes this chipset to interact very badly with e1000 hardware. Some systems have the issue and some don't. If you could bisect back to a working point it would be interesting to see where that pointed. OK, is going to be hard to bisect, since the other one was an Ubuntu kernel, but I guess I can give 2.6.15 virgin a shot, at least. doesn't seem you're overclocked. Good. Nah, I'm pretty conservative with hardware, get enough problems when it's all running within specs ;-) Thanks for looking at all this. M. Linux version 2.6.18 ([EMAIL PROTECTED]) (gcc version 3.4.6 (Ubuntu 3.4.6-1ubuntu2)) #2 Sun Oct 22 13:45:39 PDT 2006 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3fff (usable) BIOS-e820: 3fff - 3fff3000 (ACPI NVS) BIOS-e820: 3fff3000 - 4000 (ACPI data) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: - 0001 (reserved) Warning only 896MB will be used. Use a HIGHMEM enabled kernel. 896MB LOWMEM available. found SMP MP-table at 000f52b0 On node 0 totalpages: 229376 DMA zone: 4096 pages, LIFO batch:0 Normal zone: 225280 pages, LIFO batch:31 DMI 2.2 present. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 Processor #0 6:10 APIC version 17 I/O APIC #2 Version 17 at 0xFEC0. Enabling APIC mode: Flat. Using 1 I/O APICs Processors: 1 Allocating PCI resources starting at 5000 (gap: 4000:bec0) Detected 1098.980 MHz processor. Built 1 zonelists. Total pages: 229376 Kernel command line: root=/dev/hda1 ro lapic profile=2 kernel profiling enabled (shift: 2) mapped APIC to d000 (fee0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c04e4000 soft=c04e3000 PID hash table entries: 4096 (order: 12, 16384 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 902328k/917504k available (2647k kernel code, 14784k reserved, 1144k data, 160k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 2200.00 BogoMIPS (lpj=4400011) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0383fbff c1c3fbff CPU: After vendor identify, caps: 0383fbff c1c3fbff CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: After all inits, caps: 0383fbff c1c3fbff 0420
Re: Strange errors from e1000 driver (2.6.18)
On Sun, 2006-10-22 at 13:27 -0700, Martin J. Bligh wrote: Jesse Brandeburg wrote: On 10/22/06, Martin J. Bligh [EMAIL PROTECTED] wrote: Martin J. Bligh wrote: I'm getting a lot of these type of errors if I run 2.6.18. If I run the standard Ubuntu Dapper kernel, I don't get them. What do they indicate? Hi Martin, they indicate that you're getting transmit hangs. Means your hardware is having issues with some of the buffers it is being handed. Because the TDH and TDT noted below are not equal, it means the hardware is hung processing buffers that the driver gave to it. We need the standard bug report particulars, Sure. Handle 0x0001, DMI type 1, 25 bytes. System Information Manufacturer: VIA Technologies, Inc. Product Name: KT600-8237 Version: Serial Number: UUID: Not Present Wake-up Type: Power Switch If this matters: I've got the same errors with the fc5 kernel sometime around january, also on an VIA-based motherboard. I only got around to fix it by changing the motherboard... (worked fine with an intel-based mb). -- Cioby - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Strange errors from e1000 driver (2.6.18)
On 10/22/06, Martin J. Bligh [EMAIL PROTECTED] wrote: Jesse Brandeburg wrote: Analysis follows, but I wanted to ask you to bisect back if you can to find the apparent patch to make the difference. Basically at this point I'd say its not likely to be an e1000 issue, but I'd like to follow up and make sure. That's going to be ugly, since I can't reproduce it at will. Maybe if I netperf it to the other box I can push it over. try tbench with 100 sessions (from dbench package) and see if that hurts. Nothing seems out of order, but the latency may be low, I'd be curious what these looked like before with the old kernel. Some of the other things to compare would have been the lspci -vv output from your chipset with old/new kernel, in case the bridge/system configuration changed. There are no known problems right now with this chipset 82546EB OK. will try later when I have more time. For now I switched to the onboard via rhine controller. ouch. shared int, fine, but whats with the ERR: ? Hmm. Having rebooted they look rather lower. but might be a time thing. CPU0 0:1405995 XT-PIC timer 1: 5910 XT-PIC i8042 2: 0 XT-PIC cascade 5: 0 XT-PIC uhci_hcd:usb3 7: 27135 XT-PIC ehci_hcd:usb2, VIA8237, eth0 10: 0 XT-PIC uhci_hcd:usb4, uhci_hcd:usb5, uhci_hcd:usb6 11: 0 XT-PIC ehci_hcd:usb1, uhci_hcd:usb7, uhci_hcd:usb8 12: 157547 XT-PIC i8042 14: 36296 XT-PIC ide0 15: 196690 XT-PIC ide1 NMI: 0 LOC:1406006 ERR: 26 except you didn't include any of the e1000 load information nor the system's boot information as it came up. OK, it had gone since reboot, but I rebooted just now new info attached. This chipset is one of the most frequent common elements in problem reports of TX hangs for e1000. My current theory (we've bought a bunch of these systems and never reproduced the issue) is that there is something either design specific or BIOS specific that causes this chipset to interact very badly with e1000 hardware. Some systems have the issue and some don't. If you could bisect back to a working point it would be interesting to see where that pointed. OK, is going to be hard to bisect, since the other one was an Ubuntu kernel, but I guess I can give 2.6.15 virgin a shot, at least. thanks, I know how difficult and time consuming bisecting is. doesn't seem you're overclocked. Good. Nah, I'm pretty conservative with hardware, get enough problems when it's all running within specs ;-) Thanks for looking at all this. welcome, like to help when I can. Linux version 2.6.18 ([EMAIL PROTECTED]) (gcc version 3.4.6 (Ubuntu 3.4.6-1ubuntu2)) #2 Sun e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue 0 TDH 26 TDT 26 next_to_use 26 next_to_clean39 buffer_info[next_to_clean] time_stamp 77145 next_to_watch3b jiffies 7734f next_to_watch.status 0 NETDEV WATCHDOG: eth0: transmit timed out e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex hey, this one is different. It is actually the common tx hang signature (TDH == TDT) for these kinds of systems. I've come up with a workaround driver, code is still in development. you can try it if you would like. http://sourceforge.net/tracker/download.php?group_id=42302atid=447449file_id=198849aid=1463045 Thanks, Jesse - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] Add tsi108 On Chip Ethernet device driver support
On Thu, 2006-09-21 at 12:46, Jeff Garzik wrote: you should have a chip structure, that contains two structs (one for each interface/port) Jeff, I updated the code according to all your feedback and post it here http://www.spinics.net/lists/netdev/msg17120.html Any comment? Roy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] [CRYPTO] added the code of Camellia cipher algorithm.
Hi, Sun, 22 Oct 2006 15:09:54 +1000 [Subject: Re: [PATCH 2/6] [CRYPTO] added the code of Camellia cipher algorithm.] Herbert Xu [EMAIL PROTECTED] wrote... On Wed, Oct 18, 2006 at 07:16:47AM +, Noriaki TAKAMIYA wrote: +static int +camellia_set_key(struct crypto_tfm *tfm, const u8 *in_key, +unsigned int key_len, u32 *flags) Ugh, this doesn't compile with the current tree since the flags field no longer exists for set_key. I've fixed it up in my tree. The tree I referred might be little bit old... Thank you for your fix. Regards, -- Noriaki TAKAMIYA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] Changeset of Camellia cipher algorithm.
Hi, Sun, 22 Oct 2006 15:07:47 +1000 [Subject: Re: [PATCH 0/6] Changeset of Camellia cipher algorithm.] Herbert Xu [EMAIL PROTECTED] wrote On Wed, Oct 18, 2006 at 07:15:10AM +, Noriaki TAKAMIYA wrote: [PATCH 1/6] [CRYPTO] added Kconfig entry for Camellia. [PATCH 2/6] [CRYPTO] added the code of Camellia cipher algorithm. [PATCH 3/6] [CRYPTO] added the testing code of Camellia cipher algorithm. [PATCH 4/6] [IPSEC] added the definition of Camellia cipher algorithm. [PATCH 5/6] [IPSEC] added the entry of Camellia cipher algorithm to ealg_list[]. [PATCH 6/6] [CRYPTO] added the developer of Camellia cipher algorithm. I've applied all the patches to cryptodev-2.6. Thanks! Thank you! -- Noriaki TAKAMIYA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] skge, sky2, et all. gplv2 only
I don't want my code to downgraded to GPLv3 because of cut-n-pasted the comments. These files which I hold copyright on were started before it was clear what GPLv3 was going to be. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- linux-2.6.orig/drivers/net/irda/stir4200.c 2006-10-22 20:12:25.0 -0700 +++ linux-2.6/drivers/net/irda/stir4200.c 2006-10-22 20:12:33.0 -0700 @@ -15,8 +15,7 @@ * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by -* the Free Software Foundation; either version 2 of the License, or -* (at your option) any later version. +* the Free Software Foundation; either version 2 of the License. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of --- linux-2.6.orig/drivers/net/skge.c 2006-10-22 20:11:36.0 -0700 +++ linux-2.6/drivers/net/skge.c2006-10-22 20:11:50.0 -0700 @@ -11,8 +11,7 @@ * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. + * the Free Software Foundation; either version 2 of the License. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of --- linux-2.6.orig/drivers/net/sky2.c 2006-10-22 20:11:14.0 -0700 +++ linux-2.6/drivers/net/sky2.c2006-10-22 20:11:31.0 -0700 @@ -10,8 +10,7 @@ * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. + * the Free Software Foundation; either version 2 of the License. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of --- linux-2.6.orig/net/sched/sch_netem.c2006-10-22 20:12:04.0 -0700 +++ linux-2.6/net/sched/sch_netem.c 2006-10-22 20:12:11.0 -0700 @@ -4,7 +4,7 @@ * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version - * 2 of the License, or (at your option) any later version. + * 2 of the License. * * Many of the algorithms and ideas for this came from * NIST Net which is not copyrighted. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] atm: fix horizon init section usage
From: Randy Dunlap [EMAIL PROTECTED] Date: Sun, 22 Oct 2006 19:13:09 -0700 From: Randy Dunlap [EMAIL PROTECTED] hrz_init() is called from the probe function, which is __devinit and could be called after init. WARNING: drivers/atm/horizon.o - Section mismatch: reference to .init.text:.hrz_init from .text between '.hrz_probe' (at offset 0x4054) and '.hrz_remove_one' Signed-off-by: Randy Dunlap [EMAIL PROTECTED] It is only called from hrz_init() and thus shouldn't it be thus marked __devinit as well? That seems to be the right way to fix this one. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] atm: fix horizon init section usage
David Miller wrote: From: Randy Dunlap [EMAIL PROTECTED] Date: Sun, 22 Oct 2006 19:13:09 -0700 From: Randy Dunlap [EMAIL PROTECTED] hrz_init() is called from the probe function, which is __devinit and could be called after init. WARNING: drivers/atm/horizon.o - Section mismatch: reference to .init.text:.hrz_init from .text between '.hrz_probe' (at offset 0x4054) and '.hrz_remove_one' Signed-off-by: Randy Dunlap [EMAIL PROTECTED] It is only called from hrz_init() and thus shouldn't it be thus marked __devinit as well? That seems to be the right way to fix this one. Oops, I agree. Want me to send another patch? -- ~Randy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] atm: fix horizon init section usage
From: Randy.Dunlap [EMAIL PROTECTED] Date: Sun, 22 Oct 2006 21:32:20 -0700 David Miller wrote: From: Randy Dunlap [EMAIL PROTECTED] Date: Sun, 22 Oct 2006 19:13:09 -0700 From: Randy Dunlap [EMAIL PROTECTED] hrz_init() is called from the probe function, which is __devinit and could be called after init. WARNING: drivers/atm/horizon.o - Section mismatch: reference to .init.text:.hrz_init from .text between '.hrz_probe' (at offset 0x4054) and '.hrz_remove_one' Signed-off-by: Randy Dunlap [EMAIL PROTECTED] It is only called from hrz_init() and thus shouldn't it be thus marked __devinit as well? That seems to be the right way to fix this one. Oops, I agree. Want me to send another patch? No need, I'll take care of it, thanks Randy. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] netpoll: use sk_buff_head for txq
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Fri, 20 Oct 2006 15:30:27 -0700
+ spin_lock_irqsave(netpoll_txq.lock, flags);
+ for (skb = (struct sk_buff *)netpoll_txq.next;
+ skb != (struct sk_buff *)netpoll_txq; skb = next) {
+ next = skb-next;
+ if (skb-dev == dev)
+ skb_unlink(skb, netpoll_txq);
+ }
+ spin_unlock_irqrestore(netpoll_txq.lock, flags);
}
All SKBs removed here will be leaked, nothing frees them up.
Since #2 and #3 depend upon this patch, I'll hold off on those
until you fix this bug.
Thanks.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TCP socket buffer autotuning
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Sat, 21 Oct 2006 12:36:08 -0700
On Fri, 20 Oct 2006 23:42:28 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
@@ -170,6 +170,8 @@ static int netem_enqueue(struct sk_buff
return NET_XMIT_BYPASS;
}
+ skb_orphan(skb);
+
...
Yeah, that's good. I run netem on an intermediate machine (bridge or router)
when running tests to avoid this and other local feedback scenario's.
I'll put this into 2.6.19 as a fix for now, but I am so tempted
to just kill off that skb_set_owner_w() call in tcp_transmit_skb().
That call is totally pointless, even for the case where we pskb_copy()
a data SKB at the beginning of tcp_transmit_skb(). The socket is
charged for the memory, and the SKB clone itself is transient and
owned by entirely the IP{4,6} output path, queueing layer, and device.
We have discussed before how it probably makes sense for UDP, which
is in a similar situation, because otherwise a very aggressive
UDP socket can essentially flood the device without letting other
sockets to send traffic.
But here in this TCP clone situation, that doesn't apply. The socket
has already had the data charged to it properly.
It is something to seriously consider for 2.6.20, anyways, because it
would kill off some expensive atomics and accounting in our TCP
transmit path as well.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
