ALSA HDA problem with 64-bit kernels
Heip! I recently moved to 64-bit kernel, but mixed sounds (ie. mpegs played with a media player) don't work with optical S/PDIF connection. AC3/DTS passthrough still works, and I can hear the mixed sounds on analog connector. And yes, I have unmuted the IEC958 mixer setting. Tested kernels: ALSA 1.0.14: 2.6.23.1 32bit: works 2.6.23.1 64bit: broken 2.6.23.12 64bit: broken 2.6.23.12 64bit kernel, 32bit userspace: broken ALSA 1.0.15: 2.6.24-rc6 64bit: broken (and half of the mixer settings are missing) The soundcard is integrated to the motherboard (Abit IP35 Pro) and I can't find any more information on it than it is "7.1 CH HD Audio CODEC". Relevant part of dmesg (it is the same for 32/64 bit versions, expect that the interrput goes to IRQ 18): ===cut dmesg Advanced Linux Sound Architecture Driver Version 1.0.14 (Fri Jul 20 09:12:58 2007 UTC). ACPI: PCI Interrupt :00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22 PCI: Setting latency timer of device :00:1b.0 to 64 hda_codec: Unknown model for ALC883, trying auto-probe from BIOS... usbcore: registered new interface driver snd-usb-audio ALSA device list: #0: HDA Intel at 0xfdff4000 irq 22 ===cut lspci 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 02) Subsystem: ABIT Computer Corp. Unknown device [147b:1083] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
Heip! (commit: "r8169: merge with version 6.001.00 of Realtek's r8169 driver") In current 2.6.23-rc8 snapshot r8169 send performance is bad, around 32MB/s. In 2.6.22 it was around 83MB/s. Interestingly, the receive performance has increased from around 85MB/s to 96MB/s at the same time! Git bisect gave commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 as the culprit, and reverting it from the 2.6.23-rc8 increases send speed back to .22 level. (It didn't revert cleanly and the file needed some cleaning up by hand.) Performance data: (The other end of iperf is machine with kernel 2.6.22.6 and nForce3 built-in nic.) 2.6.22 (and 2.6.23-rc8 with that change reverted) ===cut $ iperf -m -l32k -c gw -r Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) Client connecting to gw, TCP port 5001 TCP window size: 64.0 KByte (default) [ 5] local 10.0.0.1 port 36068 connected with 10.0.0.254 port 5001 [ 5] 0.0-10.0 sec832 MBytes696 Mbits/sec [ 5] MSS size 7148 bytes (MTU 7188 bytes, unknown interface) [ 4] local 10.0.0.1 port 5001 connected with 10.0.0.254 port 59713 [ 4] 0.0-10.2 sec825 MBytes678 Mbits/sec [ 4] MSS size 7148 bytes (MTU 7188 bytes, unknown interface) $ vmstat 2 procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 0 0 0 1960780 2948 3294800 23611 48 327 2 3 86 9 0 0 0 1960660 2948 3297200 0 0 94 944 0 0 100 0 0 0 0 1960752 2952 329960014 0 90 233 0 0 100 0 0 0 0 1960776 2952 3299600 0 0 89 964 0 0 100 0 1 0 0 1959544 3044 3378800 42052 154 458 0 1 97 2 0 0 0 1940288 3080 3470400 43434 16075 2198 0 2 98 0 0 0 0 1940116 3080 3470400 0 0 16464 2835 0 1 99 0 0 0 0 1940020 3080 3470400 058 16590 2194 0 1 99 0 0 0 0 1940316 3080 3470400 0 0 16489 2887 0 1 99 0 0 0 0 1940268 3080 3470400 0 0 16505 2990 0 1 99 0 0 0 0 1957936 3080 3470400 0 4 23482 24903 0 2 98 0 0 0 0 1957720 3080 3470400 0 0 24270 29139 0 2 98 0 0 0 0 1957980 3080 3470400 0 4 22045 27621 0 2 98 0 1 0 0 1958004 3080 3470400 0 0 24383 30106 0 2 98 0 0 0 0 1957956 3080 3470400 0 0 21984 27709 0 2 98 0 0 0 0 1958112 3080 3470400 0 0 3083 5826 0 0 100 0 0 0 0 1958168 3080 3470400 0 0 83 2392 0 0 100 0 ===cut 2.6.23-rc8 without changes ===cut $ iperf -m -l32k -c gw -r Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) Client connecting to gw, TCP port 5001 TCP window size: 73.0 KByte (default) [ 5] local 10.0.0.1 port 55265 connected with 10.0.0.254 port 5001 [ 5] 0.0-10.1 sec328 MBytes272 Mbits/sec [ 5] MSS size 7148 bytes (MTU 7188 bytes, unknown interface) [ 4] local 10.0.0.1 port 5001 connected with 10.0.0.254 port 41340 [ 4] 0.0-10.0 sec964 MBytes805 Mbits/sec [ 4] MSS size 7148 bytes (MTU 7188 bytes, unknown interface) $ vmstat 2 procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 0 0 0 1961244 3756 3158000 29213 52 331 2 4 84 10 0 0 0 1959916 3756 3236800 436 0 186 893 0 0 99 0 0 0 0 1944668 3756 3250400 0 0 7141 2223 0 2 98 0 0 0 0 1948260 3756 3250400 0 0 7012 2213 0 2 98 0 1 0 0 1946532 3756 3250400 0 0 7001 0 1 99 0 1 0 0 1942276 3756 3250400 0 0 6996 2168 0 2 98 0 1 0 0 1943336 3756 3250400 0 0 6946 2181 0 0 100 0 2 0 0 1959144 3848 3329600 42052 19020 24412 0 2 96 2 1 0 0 1959064 3884 3334400 082 21825 30835 0 3 97 0 0 0 0 1959152 3884 3334400 0 0 21816 32094 0 2 98 0 0 0 0 1959040 3884 3334400 0 6 21850 31934 0 3 96 0 2 0 0 1959072 3884 3334400 0 0 21812 32068 0 2 98 0 0 0 0 1959104 3884 3334400
Re: commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
On Wed, 26 Sep 2007, Francois Romieu wrote: > The patch below is scheduled for inclusion before 2.6.23. Please try it and > see if it makes a difference on top of 2.6.23-rc8 (full dmesg will be welcome > too). Thanks for the quick reply and fix. Unfortunately the fix didn't help in my case. Iperf readings (send+receive) from 2.6.23-git (just before 6dccd... commit) [ 5] 0.0-10.0 sec830 MBytes694 Mbits/sec [ 4] 0.0-10.0 sec842 MBytes706 Mbits/sec 2.3.23-rc8 (clean) [ 4] 0.0-10.0 sec323 MBytes270 Mbits/sec [ 5] 0.0-10.0 sec961 MBytes802 Mbits/sec 2.3.23-rc8 and your patch [ 5] 0.0-10.1 sec326 MBytes270 Mbits/sec [ 4] 0.0-10.0 sec958 MBytes802 Mbits/sec 2.3.23-rc8 and 6dccd... reverted [ 5] 0.0-10.1 sec830 MBytes692 Mbits/sec [ 4] 0.0-10.0 sec803 MBytes673 Mbits/sec and full dmesg from 2.3.23-rc8+your patch below. Dmesg from other versions differed only by random noise caused by minor variations on bogomips scores, async initializations etc. I can send them to you too, if you think they are useful. ===cut Linux version 2.6.23-rc8-fix ([EMAIL PROTECTED]) (gcc version 4.2.0 (Gentoo 4.2.0 p1.4)) #2 SMP Wed Sep 26 21:24:43 EEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009e400 (usable) BIOS-e820: 0009e400 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 7fee (usable) BIOS-e820: 7fee - 7fee3000 (ACPI NVS) BIOS-e820: 7fee3000 - 7fef (ACPI data) BIOS-e820: 7fef - 7ff0 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - 0001 (reserved) 1150MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000f3640 NX (Execute Disable) protection: active Entering add_active_range(0, 0, 524000) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 HighMem229376 -> 524000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -> 524000 On node 0 totalpages: 524000 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 HighMem zone: 2301 pages used for memmap HighMem zone: 292323 pages, LIFO batch:31 Movable zone: 0 pages used for memmap DMI 2.5 present. ACPI: RSDP 000F77F0, 0014 (r0 IntelR) ACPI: RSDT 7FEE3000, 0034 (r1 IntelR AWRDACPI 42302E31 AWRD0) ACPI: FACP 7FEE3080, 0074 (r1 IntelR AWRDACPI 42302E31 AWRD0) ACPI: DSDT 7FEE3100, 4D1C (r1 INTELR AWRDACPI 1000 MSFT 300) ACPI: FACS 7FEE, 0040 ACPI: MCFG 7FEE7F00, 003C (r1 IntelR AWRDACPI 42302E31 AWRD0) ACPI: APIC 7FEE7E40, 0084 (r1 IntelR AWRDACPI 42302E31 AWRD0) ACPI: SSDT 7FEE8860, 0380 (r1 PmRefCpuPm 3000 INTL 20041203) ACPI: PM-Timer IO Port: 0x408 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x03] enabled) Processor #3 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) Processor #2 6:15 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1]) ACPI: IOAPIC (id[0x04] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 4, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 8000 (gap: 7ff0:6010) Built 1 zonelists in Zone order. Total pages: 519907 Kernel command line: ro root=/dev/sdb2 [EMAIL PROTECTED]/eth0,[EMAIL PROTECTED]/ video=vesafb:ypan,mtrr:3 vga=0x0376 netconsole: local port 2001 netconsole: local IP 10.0.0.1 netconsole: interface eth0 netconsole: remote port 2001 netconsole: remote IP 10.0.0.254 netconsole: remote ethernet address ff:ff:ff:ff:ff:ff mapped APIC to b000 (fee0) mapped IOAPIC to a000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 2403.193 MHz processor. Console: colour dummy device 80x25 console [tty0] enabled Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 2072204k
Re: commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
On Wed, 26 Sep 2007, Willy Tarreau wrote: > On Wed, Sep 26, 2007 at 09:52:02PM +0300, Timo Jantunen wrote: > > On Wed, 26 Sep 2007, Francois Romieu wrote: > > > The patch below is scheduled for inclusion before 2.6.23. Please try it > > > and > > > see if it makes a difference on top of 2.6.23-rc8 (full dmesg will be > > > welcome > > > too). > > Thanks for the quick reply and fix. Unfortunately the fix didn't help in my > > case. > > In another thread on LKML today, there has been some discussion about a > similar problem, which is caused by a locking bug in iperf which makes > it spin at 100% CPU. Ingo has posted a fix for this, please check the list. I noticed the problem originally with another program (playback of 720p video to remote X using mplayer). And in my case the CPU usage is 2-3% systime, <1% userspace so it doesn't seem to be anything to do with the scheduler (I did try that "echo 1 > /proc/sys/kernel/sched_compat_yield" workaround, too.) //T > Regards, > Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
On Wed, 26 Sep 2007, Francois Romieu wrote: > Apply and try each patch of the attached tarball on top of 2.6.23-git > until the behavior changes (assuming it does). > > Patch #000n applies on top of patch #000(n - 1). I tested the series on top of -rc8 and 0005 did the trick. And if I use 0005 only, I can get 93MB/s send and 97MB/s receive, so there is a nice increase on send too since .22! iperf numbers (send/receive): revert.0001:[ 4] 0.0-10.1 sec234 MBytes194 Mbits/sec revert.0001:[ 5] 0.0-10.0 sec445 MBytes373 Mbits/sec revert.0002:[ 5] 0.0-10.0 sec325 MBytes272 Mbits/sec revert.0002:[ 4] 0.0-10.1 sec969 MBytes802 Mbits/sec revert.0003:[ 4] 0.0-10.1 sec328 MBytes272 Mbits/sec revert.0003:[ 5] 0.0-10.0 sec742 MBytes622 Mbits/sec revert.0004:[ 4] 0.0-10.2 sec329 MBytes271 Mbits/sec revert.0004:[ 5] 0.0-10.0 sec759 MBytes637 Mbits/sec revert.0005:[ 4] 0.0-10.1 sec829 MBytes691 Mbits/sec revert.0005:[ 5] 0.0-10.0 sec772 MBytes647 Mbits/sec revert.0005-only:[ 5] 0.0-10.0 sec933 MBytes780 Mbits/sec revert.0005-only:[ 4] 0.0-10.1 sec970 MBytes806 Mbits/sec //T > Good night. // / ....Timo Jantunen .. ZZZ (Used to represent :Kuunsäde 8 A 28: Email: [EMAIL PROTECTED] : the sound of a person snoring.) :FIN-02210 Espoo: http://iki.fi/jeti : Webster's Encyclopedic Unabridged :Finland: GSM+358-40-5763131 : Dictionary of the English Language :...::
Re: Linux 2.6.23-rc9 and a heads-up for the 2.6.24 series..
On Mon, 1 Oct 2007, Linus Torvalds wrote:
> So there's a final -rc out there, and right now my plan is to make this
> series really short, and release 2.6.23 in a few days. So please do give
> it a last good testing, and holler about any issues you find!
The r8169 nic performance regression is still there.
2.6.22: send 82MB/s, receive 86MB/s
2.6.23-rc9: send 32MB/s, receive 98MB/s
I debugged this with Francois Romieu but haven't heard from him since
testing his fixes.
I attached a patch from him which is a partial revert of commit
6dccd16b7c2703e8bbf8bca62b5cf248332afbe2.
With this patch I get 93MB send and 97MB receive and I have been running it
for a week but I don't know if the patch has any downsides on other
systems.
//T
> Linus
>From 34875931ba2e473e2867d941980131edd609dbe4 Mon Sep 17 00:00:00 2001
From: Francois Romieu <[EMAIL PROTECTED]>
Date: Wed, 26 Sep 2007 23:44:03 +0200
Subject: [PATCH] r8169: more revert
Part of 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index cb4c412..6d8611c 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1905,7 +1905,11 @@ static void rtl_hw_start_8169(struct net_device *dev)
rtl_set_rx_max_size(ioaddr);
- rtl_set_rx_tx_config_registers(tp);
+ if ((tp->mac_version == RTL_GIGA_MAC_VER_01) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_02) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_03) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_04))
+ rtl_set_rx_tx_config_registers(tp);
tp->cp_cmd |= rtl_rw_cpluscmd(ioaddr) | PCIMulRW;
@@ -1926,6 +1930,14 @@ static void rtl_hw_start_8169(struct net_device *dev)
rtl_set_rx_tx_desc_registers(tp, ioaddr);
+ if ((tp->mac_version != RTL_GIGA_MAC_VER_01) &&
+ (tp->mac_version != RTL_GIGA_MAC_VER_02) &&
+ (tp->mac_version != RTL_GIGA_MAC_VER_03) &&
+ (tp->mac_version != RTL_GIGA_MAC_VER_04)) {
+ RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
+ rtl_set_rx_tx_config_registers(tp);
+ }
+
RTL_W8(Cfg9346, Cfg9346_Lock);
/* Initially a 10 us delay. Turned it into a PCI commit. - FR */
@@ -1940,8 +1952,6 @@ static void rtl_hw_start_8169(struct net_device *dev)
/* Enable all known interrupts by setting the interrupt mask. */
RTL_W16(IntrMask, tp->intr_event);
-
- RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
}
static void rtl_hw_start_8168(struct net_device *dev)
--
1.5.3.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.22.1: hang with forcedeth driver?
Heip! I have had few total hangs with 2.6.22.1 kernel. Everything suddenly freezes and nothing works (SysRq keys, pinging the machine from the network.) Neither syslog nor netconsole have any relevant messages. I'm 99% sure this didn't happen in 2.6.21.x kernels. All hangs happened with relatively high network traffic (twice with mplayer using remote display, once with high network fs activity). I copied gigabytes of files over nfs but couldn't dupicatate the problem that way, but OTOH I have also watched hours of video without problems so the problem doesn't occur often. (In the mplayer case, the file I play is usually on remote nfs disk, too.) I started using mplayer from a text console and today I finally managed to catch first bit of information. The machine hanged like before (even SysRq keys don't print anything) but there was one console message: eth0: too many iterations (6) in nv_nic_irq. Looking at the sources, it seems when too much works happens in a single interrupt, the driver tries to disable device interrupts (and prints above message). It doesn't seem to be expecting the machine to hang afterwards. I guess the quick fix for me is to increase max_interrupt_work value so it doesn't get hit as easily. I have nForce3 board and Athlon 64 X2 CPU (but using 32-bit kernel). I'm using the built in ethernet with forcedeth driver. I also have ATI/AMD binary drivers loaded, and at least in some of the cases, VMware host drivers, too. parts of .config (full .config available on request) ===cut CONFIG_NO_HZ=y CONFIG_SMP=y # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_FORCEDETH=y # CONFIG_FORCEDETH_NAPI is not set CONFIG_DETECT_SOFTLOCKUP=y ===cut lspci ===cut 00:00.0 Host bridge: nVidia Corporation nForce3 250Gb Host Bridge (rev a1) 00:01.0 ISA bridge: nVidia Corporation nForce3 250Gb LPC Bridge (rev a2) 00:01.1 SMBus: nVidia Corporation nForce 250Gb PCI System Management (rev a1) 00:02.0 USB Controller: nVidia Corporation CK8S USB Controller (rev a1) 00:02.1 USB Controller: nVidia Corporation CK8S USB Controller (rev a1) 00:02.2 USB Controller: nVidia Corporation nForce3 EHCI USB 2.0 Controller (rev a2) 00:05.0 Bridge: nVidia Corporation CK8S Ethernet Controller (rev a2) 00:06.0 Multimedia audio controller: nVidia Corporation nForce3 250Gb AC'97 Audio Controller (rev a1) 00:08.0 IDE interface: nVidia Corporation CK8S Parallel ATA Controller (v2.5) (rev a2) 00:09.0 IDE interface: nVidia Corporation CK8S Serial ATA Controller (v2.5) (rev a2) 00:0a.0 IDE interface: nVidia Corporation CK8S Serial ATA Controller (v2.5) (rev a2) 00:0b.0 PCI bridge: nVidia Corporation nForce3 250Gb AGP Host to PCI Bridge (rev a2) 00:0e.0 PCI bridge: nVidia Corporation nForce3 250Gb PCI-to-PCI Bridge (rev a2) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:00.0 VGA compatible controller: ATI Technologies Inc R420 JP [Radeon X800XT] 01:00.1 Display controller: ATI Technologies Inc R420 [X800XT-PE] (Secondary) 02:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) ===cut lspci -vvv, only eth0 device ===cut 00:05.0 Bridge: nVidia Corporation CK8S Ethernet Controller (rev a2) Subsystem: Micro-Star International Co., Ltd. Unknown device 0250 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22.1: hang with forcedeth driver?
On Fri, 3 Aug 2007, Andrew Morton wrote: > On Thu, 2 Aug 2007 11:57:21 +0300 (EEST) > Timo Jantunen <[EMAIL PROTECTED]> wrote: > > > Heip! > > > > I have had few total hangs with 2.6.22.1 kernel. Everything suddenly > > freezes and nothing works (SysRq keys, pinging the machine from the > > network.) Neither syslog nor netconsole have any relevant messages. I'm 99% > > sure this didn't happen in 2.6.21.x kernels. > > Try enabling the NMI watchdog? (boot with nmi_watchdog=1 on the kernel > command line) (or maybe nmi_watchdog=2). nmi_watchdog=1 got me (in dmesg) Testing NMI watchdog ... CPU#0: NMI appears to be stuck (0->0)! CPU#1: NMI appears to be stuck (0->0)! nmi_watchdog=2 got me Testing NMI watchdog ... OK. In both cases, when the machine hanged, nothing happened and nothing more was written to console, syslog or netconsole (with console Loglevel set to 9.) > otoh, I think NMI watchdog is always enabled on x86_64. But the counts > aren't going up. I forget what the story is there, apart from > lets-be-as-different-from-i386-as-we-can :( Like I said later I'm using i386 kernel. > > All hangs happened with relatively high network traffic (twice with mplayer > > using remote display, once with high network fs activity). I copied > > gigabytes of files over nfs but couldn't dupicatate the problem that way, > > but OTOH I have also watched hours of video without problems so the problem > > doesn't occur often. (In the mplayer case, the file I play is usually on > > remote nfs disk, too.) > > > > I started using mplayer from a text console and today I finally managed to > > catch first bit of information. The machine hanged like before (even SysRq > > keys don't print anything) but there was one console message: > > > > eth0: too many iterations (6) in nv_nic_irq. > > > > Looking at the sources, it seems when too much works happens in a single > > interrupt, the driver tries to disable device interrupts (and prints above > > message). It doesn't seem to be expecting the machine to hang afterwards. > > > > I guess the quick fix for me is to increase max_interrupt_work value so it > > doesn't get hit as easily. > > Well. A Key piece of information would be: did that help? I added forcedeth.max_interrupt_work=16 to the command line, and haven't seen the problem after that. But I did hit the problem about once a week so I can't say if it is gone for good yet. For the tests with NMI I used forcedeth.max_interrupt_work=2 and managed to reproduce the problem in few minutes by copying from /dev/zero to nfs disk. I also did it without any binary drivers loaded. As I see it there is two separate problems: that "too many iterations" message and the fact the machine hangs after it. Since the same test was in the previous kernel but I don't remember ever seeing it it is possible that 2.6.22 changed timings or something like that which made hitting the default max_interrupt_work limit more likely. I can try to get 2.6.21.x hang with forcedeth.max_interrupt_work=2 if you think that information is useful. > > I have nForce3 board and Athlon 64 X2 CPU (but using 32-bit kernel). I'm > > using the built in ethernet with forcedeth driver. I also have ATI/AMD > > binary drivers loaded, and at least in some of the cases, VMware host > > drivers, too. //T - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix random hang in forcedeth driver when using netconsole
Heip! If the forcedeth driver receives too much work in an interrupt, it assumes it has a broken hardware with stuck IRQ. It works around the problem by disabling interrupts on the nic but makes a printk while holding device spinlog - which isn't smart thing to do if you have netconsole on the same nic. This patch moves the printk's out of the spinlock protected area. Without this patch the machine hangs hard. With this patch everything still works even when there is significant increase on CPU usage while using the nic. //T Signed-off-by: Timo Jantunen <[EMAIL PROTECTED]> diff -uprN -X linux-2.6.22.2/Documentation/dontdiff linux-2.6.22.2.original/drivers/net/forcedeth.c linux-2.6.22.2/drivers/net/forcedeth.c --- linux-2.6.22.2.original/drivers/net/forcedeth.c 2007-08-10 08:20:27.761813671 +0300 +++ linux-2.6.22.2/drivers/net/forcedeth.c 2007-08-14 21:03:14.109056661 +0300 @@ -3067,8 +3067,8 @@ static irqreturn_t nv_nic_irq(int foo, v np->nic_poll_irq = np->irqmask; mod_timer(&np->nic_poll, jiffies + POLL_WAIT); } - printk(KERN_DEBUG "%s: too many iterations (%d) in nv_nic_irq.\n", dev->name, i); spin_unlock(&np->lock); + printk(KERN_DEBUG "%s: too many iterations (%d) in nv_nic_irq.\n", dev->name, i); break; } @@ -3185,8 +3185,8 @@ static irqreturn_t nv_nic_irq_optimized( np->nic_poll_irq = np->irqmask; mod_timer(&np->nic_poll, jiffies + POLL_WAIT); } - printk(KERN_DEBUG "%s: too many iterations (%d) in nv_nic_irq.\n", dev->name, i); spin_unlock(&np->lock); + printk(KERN_DEBUG "%s: too many iterations (%d) in nv_nic_irq.\n", dev->name, i); break; } @@ -3232,8 +3232,8 @@ static irqreturn_t nv_nic_irq_tx(int foo np->nic_poll_irq |= NVREG_IRQ_TX_ALL; mod_timer(&np->nic_poll, jiffies + POLL_WAIT); } - printk(KERN_DEBUG "%s: too many iterations (%d) in nv_nic_irq_tx.\n", dev->name, i); spin_unlock_irqrestore(&np->lock, flags); + printk(KERN_DEBUG "%s: too many iterations (%d) in nv_nic_irq_tx.\n", dev->name, i); break; } @@ -3347,8 +3347,8 @@ static irqreturn_t nv_nic_irq_rx(int foo np->nic_poll_irq |= NVREG_IRQ_RX_ALL; mod_timer(&np->nic_poll, jiffies + POLL_WAIT); } - printk(KERN_DEBUG "%s: too many iterations (%d) in nv_nic_irq_rx.\n", dev->name, i); spin_unlock_irqrestore(&np->lock, flags); + printk(KERN_DEBUG "%s: too many iterations (%d) in nv_nic_irq_rx.\n", dev->name, i); break; } } @@ -3420,8 +3420,8 @@ static irqreturn_t nv_nic_irq_other(int np->nic_poll_irq |= NVREG_IRQ_OTHER; mod_timer(&np->nic_poll, jiffies + POLL_WAIT); } - printk(KERN_DEBUG "%s: too many iterations (%d) in nv_nic_irq_other.\n", dev->name, i); spin_unlock_irqrestore(&np->lock, flags); + printk(KERN_DEBUG "%s: too many iterations (%d) in nv_nic_irq_other.\n", dev->name, i); break; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel BUG at inode.c:889!
Heip! While I was looking unused partitions to be used for ReiserFS testing (paranoia is a way of life when dealing with my data ;-), I did mount /dev/hda5 /mnt/tmp to a partition which I thought to be unused (just to be sure). This resulted in a Really Weird(tm) /mnt/tmp _file_ which didn't have any permissions to anyone. When checking kernel messages, I found "EXT2-fs warning: checktime reached, running e2fsck is recommended" line. Then I tried to unmount the partition. It checkfaulted. Messages had following entries. ---cut Jan 31 19:46:30 limbo kernel: EXT2-fs error (device ide0(3,5)): free_inode: reserved inode or nonexistent inode Jan 31 19:46:30 limbo kernel: kernel BUG at inode.c:889! Jan 31 19:46:30 limbo kernel: invalid operand: Jan 31 19:46:30 limbo kernel: CPU:0 Jan 31 19:46:30 limbo kernel: EIP:0010:[iput+205/336] Jan 31 19:46:30 limbo kernel: EFLAGS: 00010282 Jan 31 19:46:30 limbo kernel: eax: 001b ebx: c7ce7180 ecx: cd536000 edx: c023a328 Jan 31 19:46:30 limbo kernel: esi: c023dde0 edi: c023dde0 ebp: c023de18 esp: c7c69f20 Jan 31 19:46:30 limbo kernel: ds: 0018 es: 0018 ss: 0018 Jan 31 19:46:30 limbo kernel: Process umount (pid: 1076, stackpage=c7c69000) Jan 31 19:46:30 limbo kernel: Stack: c020954b c02095eb 0379 c80b48c0 c7ce7180 c01413fe c7ce7180 cbb04e00 Jan 31 19:46:30 limbo kernel:c80b48c0 c01352ff c80b48c0 c88ed0c0 cbb04e00 080526c0 c013466a Jan 31 19:46:30 limbo kernel:c0135731 cbb04e00 c88ed0c0 c023ce8c cd07a000 c0135803 Jan 31 19:46:30 limbo kernel: Call Trace: [dput+238/336] [kill_super+63/304] [remove_vfsmnt+138/144] [do_umount+433/448] [sys_umount+195/240] [sys_munmap+43/64] [sys_oldumount+12/16] Jan 31 19:46:30 limbo kernel:[system_call+51/56] Jan 31 19:46:30 limbo kernel: Jan 31 19:46:30 limbo kernel: Code: 0f 0b 83 c4 0c eb 6c 39 1b 74 38 f6 83 ec 00 00 00 07 75 26 ---cut I couldn't unmount that partition, but SysRqsaved all other partitions. After reboot I fsck'd /dev/hda5 and it was seriously messed up. Actually it was very likely once part of RAID array tests I did a while back (/dev/hda5 was 5GB but fsck said ext2 was a 6GB filesystem). So ok, I did try to mount a seriously messed up filesystem, but it shouldn't be possible in the first place or at least it shouldn't do that when I try to umount. // / ....Timo Jantunen .. ZZZ (Used to represent :Kuunsäde 8 A 28: Email: [EMAIL PROTECTED] : the sound of a person snoring.) :02210 Espoo: http://iki.fi/jeti : Webster's Encyclopedic Unabridged :Finland: GSM+358-40-5763131 : Dictionary of the English Language :...:: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at inode.c:889!
On Wed, 31 Jan 2001, Marcelo Tosatti wrote: >> While I was looking unused partitions to be used for ReiserFS testing > Haven't you forgot to inform which kernel version are you using? Ah, sorry! 2.4.1 (Is anybody using anything else but the newest ;-) // / ....Timo Jantunen .. ZZZ (Used to represent :Kuunsäde 8 A 28: Email: [EMAIL PROTECTED] : the sound of a person snoring.) :02210 Espoo: http://iki.fi/jeti : Webster's Encyclopedic Unabridged :Finland: GSM+358-40-5763131 : Dictionary of the English Language :...:: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at inode.c:889!
On Wed, 31 Jan 2001, Andreas Dilger wrote: > Below is a patch which should fix this. It _should_ prevent you from > mounting this filesystem in the first place, and should also stop the BUG > in inode.c. I'm not 100% sure of correctness, however: I tried to reproduce the BUG message, but I was unable to get to the same situation again. (I tried to create several different RAID0 partitions, format them to ext2 and tried mounting the partitions alone. I did get some weird messages from partitions I did manage to mount (what you would expect from mounting such partitions) but no more BUG messages.) So unfortunately I can't help you to check if your fix works. // / ....Timo Jantunen .. ZZZ (Used to represent :Kuunsäde 8 A 28: Email: [EMAIL PROTECTED] : the sound of a person snoring.) :02210 Espoo: http://iki.fi/jeti : Webster's Encyclopedic Unabridged :Finland: GSM+358-40-5763131 : Dictionary of the English Language :...:: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
BUG: soft lockup with kernel 2.6.23.12 (x86-64)
Heip! I did something like "dd if=/dev/sda1 bs=256M of=dump" and the whole system hanged after a while. Netconsole captured following soft lockup: ===cut BUG: soft lockup - CPU#3 stuck for 11s! [metalog:4767] CPU 3: Modules linked in: fglrx(P) cinergyT2 Pid: 4767, comm: metalog Tainted: P D 2.6.23.12 #6 RIP: 0010:[] [] _spin_lock+0x7/0x10 RSP: 0018:810128dd9b00 EFLAGS: 0286 RAX: RBX: 8100c5341b70 RCX: RDX: 81012aa50720 RSI: 8061df23 RDI: 8069bce0 RBP: 8100c5341b70 R08: R09: R10: 1000 R11: 1000 R12: 8100c5341b70 R13: 810108421a00 R14: 0001 R15: 00010b84002c FS: 2b9a1ba83b00() GS:81012fc0f200() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 8900757b0600 CR3: 00012c223000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Call Trace: [] __mark_inode_dirty+0x65/0x1b0 [] reiserfs_file_write+0x1b9/0x1b90 [] free_poll_entry+0x11/0x20 [] poll_freewait+0x30/0x90 [] do_sys_poll+0x170/0x3f0 [] __pollwait+0x0/0x130 [] __d_lookup+0x98/0x120 [] do_lookup+0x8f/0x220 [] dput+0xab/0x140 [] __link_path_walk+0xc83/0xe40 [] mntput_no_expire+0x27/0xb0 [] link_path_walk+0x80/0xf0 [] do_path_lookup+0x89/0x1f0 [] getname+0xf5/0x200 [] _atomic_dec_and_lock+0x48/0x70 [] mntput_no_expire+0x27/0xb0 [] cp_new_stat+0xe5/0x100 [] vfs_write+0xc8/0x170 [] sys_write+0x53/0x90 [] system_call+0x7e/0x83 BUG: soft lockup - CPU#0 stuck for 11s! [pdflush:290] CPU 0: Modules linked in: fglrx(P) cinergyT2 Pid: 290, comm: pdflush Tainted: P D 2.6.23.12 #6 RIP: 0010:[] [] _spin_lock+0x7/0x10 RSP: :81012ff5de58 EFLAGS: 0286 RAX: 0001 RBX: 81004c854070 RCX: RDX: 0001 RSI: 0282 RDI: 8069bce0 RBP: 81012fc9 R08: 81012ff5c000 R09: R10: 0080 R11: R12: 81012ff5a000 R13: 8023a590 R14: 000103f4afa4 R15: 00200200 FS: () GS:806ff000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: f6509000 CR3: 0001221ad000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Call Trace: [] writeback_inodes+0xa4/0xf0 [] wb_kupdate+0xa6/0x120 [] pdflush+0x0/0x1e0 [] pdflush+0x110/0x1e0 [] wb_kupdate+0x0/0x120 [] kthread+0x4b/0x80 [] child_rip+0xa/0x12 [] kthread+0x0/0x80 [] child_rip+0x0/0x12 BUG: soft lockup - CPU#2 stuck for 11s! [pdflush:289] CPU 2: Modules linked in: fglrx(P) cinergyT2 Pid: 289, comm: pdflush Tainted: P D 2.6.23.12 #6 RIP: 0010:[] [] _spin_lock+0x7/0x10 RSP: :81012ff59e38 EFLAGS: 0286 RAX: 0001 RBX: 81004c854070 RCX: 0001fcc6 RDX: RSI: 0282 RDI: 8069bce0 RBP: 81012fc9 R08: 000c5c60 R09: 81012ff59eb0 R10: 28f5c28f5c28f5c3 R11: R12: 81012ff54720 R13: 8023a590 R14: 000103f4afa3 R15: 00200200 FS: () GS:81012fc0f180() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 2b1e07aee000 CR3: 4d4a7000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Call Trace: [] writeback_inodes+0xa4/0xf0 [] background_writeout+0xa7/0xd0 [] pdflush+0x0/0x1e0 [] pdflush+0x110/0x1e0 [] background_writeout+0x0/0xd0 [] kthread+0x4b/0x80 [] child_rip+0xa/0x12 [] kthread+0x0/0x80 [] child_rip+0x0/0x12 BUG: soft lockup - CPU#1 stuck for 11s! [boinc:5597] CPU 1: Modules linked in: fglrx(P) cinergyT2 Pid: 5597, comm: boinc Tainted: P D 2.6.23.12 #6 RIP: 0010:[] [] _spin_lock+0xa/0x10 RSP: 0018:810127f33b50 EFLAGS: 0286 RAX: 11d0 RBX: 8100056d1680 RCX: 0012 RDX: f095 RSI: 8100056d1680 RDI: 8069bce0 RBP: R08: 000a R09: R10: R11: 802f05e0 R12: 0010 R13: 810127f33de0 R14: 810127f33dd8 R15: 810127f33dd0 FS: () GS:81012fc0f100(0063) knlGS:f7f696c0 CS: 0010 DS: 002b ES: 002b CR0: 80050033 CR2: f654c000 CR3: 000127c2f000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Call Trace: [] ifind_fast+0x27/0xa0 [] iget_locked+0x44/0x180 [] proc_get_inode+0x26/0x140 [] proc_lookup+0x95/0x110 [] do_lookup+0x17a/0x220 [] __link_path_walk+0x80d/0xe40 [] dput+0xab/0x140 [] __link_path_
