[it really is text/plain :P] dual port onboard 82546EB checksum errors
I have a rackmount server that has a dual port onboard 82546EB card. I've googled and seen this card apparently active with other users but I seem to only get checksum errors. [0.194129] Intel(R) PRO/1000 Network Driver - version 7.3.15-k2-NAPI [0.194234] Copyright (c) 1999-2006 Intel Corporation. [0.194405] ACPI: PCI Interrupt :04:09.0[A] -> GSI 51 (level, low) -> IRQ 16 [0.458732] e1000: :04:09.0: e1000_probe: (PCI:66MHz:64-bit) 00:04:23:cd:93:d2 [0.489766] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection [0.489889] ACPI: PCI Interrupt :03:07.0[A] -> GSI 30 (level, low) -> IRQ 17 [0.721071] e1000: :03:07.0: e1000_probe: The EEPROM Checksum Is Not Valid [0.742509] ACPI: PCI interrupt for device :03:07.0 disabled [0.742614] e1000: probe of :03:07.0 failed with error -5 [0.742731] ACPI: PCI Interrupt :03:07.1[B] -> GSI 31 (level, low) -> IRQ 18 [0.973865] e1000: :03:07.1: e1000_probe: The EEPROM Checksum Is Not Valid [0.995304] ACPI: PCI interrupt for device :03:07.1 disabled [0.995405] e1000: probe of :03:07.1 failed with error -5 03:07.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) 03:07.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) 04: 09.0 Ethernet controller: Intel Corporation 82545GM Gigabit Ethernet Controller (rev 04) 03:07.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) Subsystem: Intel Corporation Unknown device 341a Flags: 66MHz, medium devsel, IRQ 17 Memory at fe5c (64-bit, non-prefetchable) [size=128K] I/O ports at 2040 [size=64] Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device Capabilities: [f0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- 03:07.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) Subsystem: Intel Corporation Unknown device 341a Flags: 66MHz, medium devsel, IRQ 18 Memory at fe5e (64-bit, non-prefetchable) [size=128K] I/O ports at 2000 [size=64] Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device Capabilities: [f0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- 04:09.0 Ethernet controller: Intel Corporation 82545GM Gigabit Ethernet Controller (rev 04) Subsystem: Intel Corporation PRO/1000 MT Server Adapter Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 Memory at fe8c (64-bit, non-prefetchable) [size=128K] Memory at fe88 (64-bit, non-prefetchable) [size=256K] I/O ports at 3000 [size=64] Expansion ROM at fe84 [disabled] [size=256K] Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device The 82545GM card comes up fine but the 46EB card does not. This is 2.6.20-gentoo-r6 I'll be happy to fulfill information request if needed. Any suggestions that'd help me get the 46EB working? Thank you, David - 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/
[it really is text/plain :P] dual port onboard 82546EB checksum errors
I have a rackmount server that has a dual port onboard 82546EB card. I've googled and seen this card apparently active with other users but I seem to only get checksum errors. [0.194129] Intel(R) PRO/1000 Network Driver - version 7.3.15-k2-NAPI [0.194234] Copyright (c) 1999-2006 Intel Corporation. [0.194405] ACPI: PCI Interrupt :04:09.0[A] - GSI 51 (level, low) - IRQ 16 [0.458732] e1000: :04:09.0: e1000_probe: (PCI:66MHz:64-bit) 00:04:23:cd:93:d2 [0.489766] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection [0.489889] ACPI: PCI Interrupt :03:07.0[A] - GSI 30 (level, low) - IRQ 17 [0.721071] e1000: :03:07.0: e1000_probe: The EEPROM Checksum Is Not Valid [0.742509] ACPI: PCI interrupt for device :03:07.0 disabled [0.742614] e1000: probe of :03:07.0 failed with error -5 [0.742731] ACPI: PCI Interrupt :03:07.1[B] - GSI 31 (level, low) - IRQ 18 [0.973865] e1000: :03:07.1: e1000_probe: The EEPROM Checksum Is Not Valid [0.995304] ACPI: PCI interrupt for device :03:07.1 disabled [0.995405] e1000: probe of :03:07.1 failed with error -5 03:07.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) 03:07.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) 04: 09.0 Ethernet controller: Intel Corporation 82545GM Gigabit Ethernet Controller (rev 04) 03:07.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) Subsystem: Intel Corporation Unknown device 341a Flags: 66MHz, medium devsel, IRQ 17 Memory at fe5c (64-bit, non-prefetchable) [size=128K] I/O ports at 2040 [size=64] Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device Capabilities: [f0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- 03:07.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) Subsystem: Intel Corporation Unknown device 341a Flags: 66MHz, medium devsel, IRQ 18 Memory at fe5e (64-bit, non-prefetchable) [size=128K] I/O ports at 2000 [size=64] Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device Capabilities: [f0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- 04:09.0 Ethernet controller: Intel Corporation 82545GM Gigabit Ethernet Controller (rev 04) Subsystem: Intel Corporation PRO/1000 MT Server Adapter Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 Memory at fe8c (64-bit, non-prefetchable) [size=128K] Memory at fe88 (64-bit, non-prefetchable) [size=256K] I/O ports at 3000 [size=64] Expansion ROM at fe84 [disabled] [size=256K] Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device The 82545GM card comes up fine but the 46EB card does not. This is 2.6.20-gentoo-r6 I'll be happy to fulfill information request if needed. Any suggestions that'd help me get the 46EB working? Thank you, David - 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/
Forcedeth issues, loss of connectivity. ASUS M2N32-SLI-D w/ AMD64
(please CC me when replying) I just got a motherboard with the dual nic marvell chipset onboard. Splendid board save for the driver issue I'm having :) I'm currently using 2.6.19-gentoo-r4 which doesn't have any forcedeth patch applied, a vanilla kernel seems to give the same results. This board is advertised with the dual nics being capable of failover and teaming and other fancy stuff. I've disabled this gadgetry in BIOS setup however. Every now and then (and the period seems random) the NIC or driver simply stops passing traffic [all the way] to userland or can't pass packets from certain IPs. I see both problems. Sometimes the nic zones out within a minute and sometimes it takes hours. On eth1, the first nic, sits my cable modem. It periodically loses all connectivity and tcpdump only shows the outgoing ARP for the gateway. Restarting dhcpcd on the interface fixes it perfectly. ip link set eth1 down && then up does the same thing. Traffic is immediately seen with no reconfiguration. On eth2, the second nic, I have a desktop switch. The problem I see there is that certain IPs can't be communicated with. I.e. eth2 is 10.0.0.1/24 and my printer is 10.0.0.15/24. It's been 10.0.0.15 for years. If I try to ping it, ping never sees an ICMP answer however tcpdump shows both the echo and echo_reply. Changing the IP to 10.0.0.12 and it is immediately pingable. Restarting the interface has no effect. It doesn't matter what device I put 10.0.0.15 on, it's not reachable. No iptable rules on eth2 and only outbound SNAT to the interface's IP on eth1. That is about the extent of firewalling. No fancy options in /proc and no IP mgt daemons other than standard dhcpcd. There is nothing in dmesg to indicate anything is amiss. There is nothing in dhcp log, syslog, etc, to indicate anything has changed. For the moment I have a 60 second loop to restart eth1 but it's a bit of a bother to have everything stall frequently. Any "me toos" out there, any suggestions? -david 10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.1 69.167.96.0/21 dev eth1 proto kernel scope link src 69.167.97.200 127.0.0.0/8 dev lo scope link default via 69.167.96.1 dev eth1 7: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:18:f3:82:55:01 brd ff:ff:ff:ff:ff:ff inet 69.167.97.200/21 brd 69.167.103.255 scope global eth1 inet6 fe80::218:f3ff:fe82:5501/64 scope link valid_lft forever preferred_lft forever 9: eth2: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:18:f3:82:5e:45 brd ff:ff:ff:ff:ff:ff inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2 inet6 fe80::218:f3ff:fe82:5e45/64 scope link valid_lft forever preferred_lft forever 00:10.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2) Subsystem: ASUSTeK Computer Inc. Unknown device cb84 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- Link [AMC1] -> GSI 20 (level, low) -> IRQ 20 PCI: Setting latency timer of device :00:11.0 to 64 forcedeth: using HIGHDMA eth2: forcedeth.c: subsystem: 01043:cb84 bound to :00:11.0 ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 23 ACPI: PCI Interrupt :00:0e.1[B] -> Link [AAZA] -> GSI 23 (level, low) -> IRQ 23 PCI: Setting latency timer of device :00:0e.1 to 64 - 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/
Forcedeth issues, loss of connectivity. ASUS M2N32-SLI-D w/ AMD64
(please CC me when replying) I just got a motherboard with the dual nic marvell chipset onboard. Splendid board save for the driver issue I'm having :) I'm currently using 2.6.19-gentoo-r4 which doesn't have any forcedeth patch applied, a vanilla kernel seems to give the same results. This board is advertised with the dual nics being capable of failover and teaming and other fancy stuff. I've disabled this gadgetry in BIOS setup however. Every now and then (and the period seems random) the NIC or driver simply stops passing traffic [all the way] to userland or can't pass packets from certain IPs. I see both problems. Sometimes the nic zones out within a minute and sometimes it takes hours. On eth1, the first nic, sits my cable modem. It periodically loses all connectivity and tcpdump only shows the outgoing ARP for the gateway. Restarting dhcpcd on the interface fixes it perfectly. ip link set eth1 down then up does the same thing. Traffic is immediately seen with no reconfiguration. On eth2, the second nic, I have a desktop switch. The problem I see there is that certain IPs can't be communicated with. I.e. eth2 is 10.0.0.1/24 and my printer is 10.0.0.15/24. It's been 10.0.0.15 for years. If I try to ping it, ping never sees an ICMP answer however tcpdump shows both the echo and echo_reply. Changing the IP to 10.0.0.12 and it is immediately pingable. Restarting the interface has no effect. It doesn't matter what device I put 10.0.0.15 on, it's not reachable. No iptable rules on eth2 and only outbound SNAT to the interface's IP on eth1. That is about the extent of firewalling. No fancy options in /proc and no IP mgt daemons other than standard dhcpcd. There is nothing in dmesg to indicate anything is amiss. There is nothing in dhcp log, syslog, etc, to indicate anything has changed. For the moment I have a 60 second loop to restart eth1 but it's a bit of a bother to have everything stall frequently. Any me toos out there, any suggestions? -david 10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.1 69.167.96.0/21 dev eth1 proto kernel scope link src 69.167.97.200 127.0.0.0/8 dev lo scope link default via 69.167.96.1 dev eth1 7: eth1: BROADCAST,MULTICAST,UP,1 mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:18:f3:82:55:01 brd ff:ff:ff:ff:ff:ff inet 69.167.97.200/21 brd 69.167.103.255 scope global eth1 inet6 fe80::218:f3ff:fe82:5501/64 scope link valid_lft forever preferred_lft forever 9: eth2: BROADCAST,MULTICAST,UP,1 mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:18:f3:82:5e:45 brd ff:ff:ff:ff:ff:ff inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2 inet6 fe80::218:f3ff:fe82:5e45/64 scope link valid_lft forever preferred_lft forever 00:10.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2) Subsystem: ASUSTeK Computer Inc. Unknown device cb84 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 (250ns min, 5000ns max) Interrupt: pin A routed to IRQ 21 Region 0: Memory at fe02a000 (32-bit, non-prefetchable) [size=4K] Region 1: I/O ports at b000 [size=8] Region 2: Memory at fe029000 (32-bit, non-prefetchable) [size=256] Region 3: Memory at fe028000 (32-bit, non-prefetchable) [size=16] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable+ DSel=0 DScale=0 PME- Capabilities: [70] MSI-X: Enable- Mask- TabSize=8 Vector table: BAR=2 offset= PBA: BAR=3 offset= Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/3 Enable- Address: Data: Masking: Pending: Capabilities: [6c] HyperTransport: MSI Mapping 00:11.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2) Subsystem: ASUSTeK Computer Inc. Unknown device cb84 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 (250ns min, 5000ns max) Interrupt: pin A routed to IRQ 20 Region 0: Memory at fe027000 (32-bit, non-prefetchable) [size=4K] Region 1: I/O ports at ac00 [size=8] Region 2: Memory at fe026000 (32-bit, non-prefetchable) [size=256] Region 3: Memory at fe025000 (32-bit, non-prefetchable) [size=16] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
quick question; did usb hid change from .12 to .13-rc3 on x86_64?
I've a quick question before I start digging through patches between .12 and .13-rc3, /dev/input/mice (usb mice) stopped yielding data. dmesg indicates removal/re-insertion of the device but no driver registers and nothing comes from /dev/input/mice. I have rc-3 on other machines and the mouse is working fine, so it's got to be something specific to this machine. It's an AMD64 machine. :00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. A7V600 motherboard Flags: bus master, medium devsel, latency 64, IRQ 201 I/O ports at b400 [size=32] Capabilities: [80] Power Management version 2 :00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. A7V600 motherboard Flags: bus master, medium devsel, latency 64, IRQ 201 I/O ports at b800 [size=32] Capabilities: [80] Power Management version 2 :00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. A7V600 motherboard Flags: bus master, medium devsel, latency 64, IRQ 201 I/O ports at c000 [size=32] Capabilities: [80] Power Management version 2 :00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. A7V600 motherboard Flags: bus master, medium devsel, latency 64, IRQ 201 I/O ports at c400 [size=32] Capabilities: [80] Power Management version 2 :00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. A7V600 motherboard Flags: bus master, medium devsel, latency 64, IRQ 201 Memory at fdf0 (32-bit, non-prefetchable) [size=256] Capabilities: [80] Power Management version 2 Scott ~ # zcat /proc/config.gz|egrep -i "^CON.*(_hid|mouse)" CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y CONFIG_USB_HIDDEV=y CONFIG_USB_IDMOUSE=y 2.6.12: usb 3-2: USB disconnect, address 2 usb 3-2: new low speed USB device using uhci_hcd and address 3 midi: probe of 3-2:1.0 failed with error -5 input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-:00:10.1-2 2.6.13-rc3 usb 3-2: USB disconnect, address 2 usb 3-2: new low speed USB device using uhci_hcd and address 3 midi: probe of 3-2:1.0 failed with error -5 david - 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/
quick question; did usb hid change from .12 to .13-rc3 on x86_64?
I've a quick question before I start digging through patches between .12 and .13-rc3, /dev/input/mice (usb mice) stopped yielding data. dmesg indicates removal/re-insertion of the device but no driver registers and nothing comes from /dev/input/mice. I have rc-3 on other machines and the mouse is working fine, so it's got to be something specific to this machine. It's an AMD64 machine. :00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. A7V600 motherboard Flags: bus master, medium devsel, latency 64, IRQ 201 I/O ports at b400 [size=32] Capabilities: [80] Power Management version 2 :00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. A7V600 motherboard Flags: bus master, medium devsel, latency 64, IRQ 201 I/O ports at b800 [size=32] Capabilities: [80] Power Management version 2 :00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. A7V600 motherboard Flags: bus master, medium devsel, latency 64, IRQ 201 I/O ports at c000 [size=32] Capabilities: [80] Power Management version 2 :00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. A7V600 motherboard Flags: bus master, medium devsel, latency 64, IRQ 201 I/O ports at c400 [size=32] Capabilities: [80] Power Management version 2 :00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. A7V600 motherboard Flags: bus master, medium devsel, latency 64, IRQ 201 Memory at fdf0 (32-bit, non-prefetchable) [size=256] Capabilities: [80] Power Management version 2 Scott ~ # zcat /proc/config.gz|egrep -i ^CON.*(_hid|mouse) CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y CONFIG_USB_HIDDEV=y CONFIG_USB_IDMOUSE=y 2.6.12: usb 3-2: USB disconnect, address 2 usb 3-2: new low speed USB device using uhci_hcd and address 3 midi: probe of 3-2:1.0 failed with error -5 input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-:00:10.1-2 2.6.13-rc3 usb 3-2: USB disconnect, address 2 usb 3-2: new low speed USB device using uhci_hcd and address 3 midi: probe of 3-2:1.0 failed with error -5 david - 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/
ALSA bugs with 2.6.12-rc1
It seems that 2.6.12-rc1 introduced an ALSA bug generating an oops for a null pointer. codec_semaphore: semaphore is not ready [0x1][0x300300] codec_read 0: semaphore is not ready for register 0x2c Unable to handle kernel NULL pointer dereference at virtual address printing eip: c01d7746 *pde = Oops: 0002 [#1] PREEMPT Modules linked in: orinoco_cs orinoco hermes pcmcia yenta_socket rsrc_nonstatic pcmcia_core vfat fat nls_base i2c_sensor i2c_core eth1394 ohci1394 ieee1394 i8k CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010202 (2.6.12-rc1) EIP is at memcpy+0x1e/0x39 eax: 0010 ebx: e7608180 ecx: 0004 edx: esi: e13d1ee4 edi: ebp: bf924390 esp: e13d1eb4 ds: 007b es: 007b ss: 0068 Process artsd (pid: 11880, threadinfo=e13d1000 task=e1436590) Stack: ffea ffea e13d1ef4 c02b8793 e13d1ee4 0010 e7608180 c02b954d e7608180 e13d1ee4 0050 0006 0005 0001 8002 Call Trace: [] snd_timer_user_append_to_tqueue+0x40/0x49 [] snd_timer_user_params+0x236/0x245 [] do_ioctl+0x9a/0xa9 [] vfs_ioctl+0x65/0x1e1 [] get_unused_fd+0x2c/0xd2 [] sys_ioctl+0x45/0x6d [] sysenter_past_esp+0x54/0x75 Code: fd 31 c0 c3 31 d2 b8 f2 ff ff ff c3 90 83 ec 0c 8b 44 24 18 8b 54 24 10 89 74 24 04 89 c1 89 7c 24 08 8b 74 24 14 c1 e9 02 89 d7 a5 a8 02 74 02 66 a5 a8 01 74 01 a4 89 d0 8b 74 24 04 8b 7c codec_semaphore: semaphore is not ready [0x1][0x300300] codec_read 1: semaphore is not ready for register 0x54 codec_semaphore: semaphore is not ready [0x1][0x300300] codec_write 1: semaphore is not ready for register 0x54 This happens on multiple machines, 32b and 64bit. I'll be happy to provide further information if needed. -david - 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/
ALSA bugs with 2.6.12-rc1
It seems that 2.6.12-rc1 introduced an ALSA bug generating an oops for a null pointer. codec_semaphore: semaphore is not ready [0x1][0x300300] codec_read 0: semaphore is not ready for register 0x2c Unable to handle kernel NULL pointer dereference at virtual address printing eip: c01d7746 *pde = Oops: 0002 [#1] PREEMPT Modules linked in: orinoco_cs orinoco hermes pcmcia yenta_socket rsrc_nonstatic pcmcia_core vfat fat nls_base i2c_sensor i2c_core eth1394 ohci1394 ieee1394 i8k CPU:0 EIP:0060:[c01d7746]Not tainted VLI EFLAGS: 00010202 (2.6.12-rc1) EIP is at memcpy+0x1e/0x39 eax: 0010 ebx: e7608180 ecx: 0004 edx: esi: e13d1ee4 edi: ebp: bf924390 esp: e13d1eb4 ds: 007b es: 007b ss: 0068 Process artsd (pid: 11880, threadinfo=e13d1000 task=e1436590) Stack: ffea ffea e13d1ef4 c02b8793 e13d1ee4 0010 e7608180 c02b954d e7608180 e13d1ee4 0050 0006 0005 0001 8002 Call Trace: [c02b8793] snd_timer_user_append_to_tqueue+0x40/0x49 [c02b954d] snd_timer_user_params+0x236/0x245 [c016f152] do_ioctl+0x9a/0xa9 [c016f2ef] vfs_ioctl+0x65/0x1e1 [c015bc34] get_unused_fd+0x2c/0xd2 [c016f4b0] sys_ioctl+0x45/0x6d [c0102f87] sysenter_past_esp+0x54/0x75 Code: fd 31 c0 c3 31 d2 b8 f2 ff ff ff c3 90 83 ec 0c 8b 44 24 18 8b 54 24 10 89 74 24 04 89 c1 89 7c 24 08 8b 74 24 14 c1 e9 02 89 d7 f3 a5 a8 02 74 02 66 a5 a8 01 74 01 a4 89 d0 8b 74 24 04 8b 7c codec_semaphore: semaphore is not ready [0x1][0x300300] codec_read 1: semaphore is not ready for register 0x54 codec_semaphore: semaphore is not ready [0x1][0x300300] codec_write 1: semaphore is not ready for register 0x54 This happens on multiple machines, 32b and 64bit. I'll be happy to provide further information if needed. -david - 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: ALPS tapping disabled. WHY?
I would also appreciate the return of good resolution. Blocky mouse startup moves make graphic editing rather difficult. No mouse movement until I have moved my finger a significant distance then the mouse all of a sudden jumps a dozen pixels before it "smoothly" glides along. I would also love to see the sync issues go away. :/ Whatever this patch(es) was supposed to accomplish, it introduced some rather undesirable side effects. a) sync issues, b) tapping, c) fine grain movements, d) loss of scroll sliding as well (moving your finger along the side/bottom of the glidepoint). Not griping, just providing feedback. -david Ian E. Morgan wrote: On Sun, 27 Feb 2005, Vojtech Pavlik wrote: Also, in my tree currently (and planned for 2.6.12) hardware tapping is enabled again, because double taps don't work otherwise (hardware limitation). You should really try to get that squeezed into 2.6.11 before it is released, or else I would anticipate a LOT more people whining about their broken touchpads. Regards, Ian Morgan - 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: ALPS tapping disabled. WHY?
I would also appreciate the return of good resolution. Blocky mouse startup moves make graphic editing rather difficult. No mouse movement until I have moved my finger a significant distance then the mouse all of a sudden jumps a dozen pixels before it smoothly glides along. I would also love to see the sync issues go away. :/ Whatever this patch(es) was supposed to accomplish, it introduced some rather undesirable side effects. a) sync issues, b) tapping, c) fine grain movements, d) loss of scroll sliding as well (moving your finger along the side/bottom of the glidepoint). Not griping, just providing feedback. -david Ian E. Morgan wrote: On Sun, 27 Feb 2005, Vojtech Pavlik wrote: Also, in my tree currently (and planned for 2.6.12) hardware tapping is enabled again, because double taps don't work otherwise (hardware limitation). You should really try to get that squeezed into 2.6.11 before it is released, or else I would anticipate a LOT more people whining about their broken touchpads. Regards, Ian Morgan - 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: OT: Why is usb data many times the cpu hog that firewire is?
use a minimum resolution until you detect motion then switch to high resolution. - 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: OT: Why is usb data many times the cpu hog that firewire is?
use a minimum resolution until you detect motion then switch to high resolution. - 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: Touchpad problems with 2.6.11-rc2
What does one need to do to: a) put tapping back in, and b) fix the severe jerkiness with small movements Thanks - 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: Touchpad problems with 2.6.11-rc2
What does one need to do to: a) put tapping back in, and b) fix the severe jerkiness with small movements Thanks - 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: Linux 2.6.11-rc2
PMTU bug -- or better said, bad firewall admin who blocks all ICMP. http://blue-labs.org/clue/mtu-mss.php -david David Brownell wrote: I'm seeing a problem with TCP as accessed through KMail (SuSE 9.2, x86_64). But oddly enough, only for sending mail, not reading it; and not through other (reading) applications... it's a regression with respect to rc1 and earlier kernels. Basically, it can only send REALLY TINY emails... - 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: Linux 2.6.11-rc2
PMTU bug -- or better said, bad firewall admin who blocks all ICMP. http://blue-labs.org/clue/mtu-mss.php -david David Brownell wrote: I'm seeing a problem with TCP as accessed through KMail (SuSE 9.2, x86_64). But oddly enough, only for sending mail, not reading it; and not through other (reading) applications... it's a regression with respect to rc1 and earlier kernels. Basically, it can only send REALLY TINY emails... - 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: Disaster under heavy network load on 2.4.x
It looks like you don't have 'lo' configured, i.e. your 127.0.0.1 interface. David Michal Margula wrote: >Hello! > >My friend told me to noticed you about problems I had with 2.4.x line of >kernels. I started up from 2.4.3. Under heavy load I was getting >messages from telnet, ping, nmap "No buffer space available". Strace >told me it was error marked as ENOBUFS. > >First thought was it was my fault. I asked many people and nobody could >help me. So I tried 2.4.5. It was a disaster also (should I mention few >oopses?:>). > >Second thought was to try 2.2.19 and it was good choice. Now there are >almost no messags like those above. Only thing that still happens is >"Neihgbour table overflow". > >Some data about my Linux box: > >2 x PIII 800 MHz/1024 MB; 2 x Intel EExpres 100; 3 x 3com 3c900B-Combo. >Summarizing all traffic about 5mbit at the moment. > ># arp -an | wc -l > 1018 > >Any more info needed? > >PS. It would be nice to be CCed with replies, beacause I am not >subscribed to LKML. > - 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: Disaster under heavy network load on 2.4.x
It looks like you don't have 'lo' configured, i.e. your 127.0.0.1 interface. David Michal Margula wrote: Hello! My friend told me to noticed you about problems I had with 2.4.x line of kernels. I started up from 2.4.3. Under heavy load I was getting messages from telnet, ping, nmap No buffer space available. Strace told me it was error marked as ENOBUFS. First thought was it was my fault. I asked many people and nobody could help me. So I tried 2.4.5. It was a disaster also (should I mention few oopses?:). Second thought was to try 2.2.19 and it was good choice. Now there are almost no messags like those above. Only thing that still happens is Neihgbour table overflow. Some data about my Linux box: 2 x PIII 800 MHz/1024 MB; 2 x Intel EExpres 100; 3 x 3com 3c900B-Combo. Summarizing all traffic about 5mbit at the moment. # arp -an | wc -l 1018 Any more info needed? PS. It would be nice to be CCed with replies, beacause I am not subscribed to LKML. - 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: missing sysrq
BTW, you ONLY need to echo 1 > /proc../sysrq if you use a distribution that puts a 0 there on init. By default the kernel initializes with '1'. David >>>I compiled it, and the sysrq is definitely in the config. No doubt at >>>all. I also use make mrproper and config again before dep and actual >>>compile. Maybe it is just a quirk/oddball. >>> >>>D. Stimits, [EMAIL PROTECTED] >>> >>Have you tried "echo 1 > /proc/sys/kernel/sysrq"? >>You need both, compiled in and activation. >> - 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: missing sysrq
BTW, you ONLY need to echo 1 /proc../sysrq if you use a distribution that puts a 0 there on init. By default the kernel initializes with '1'. David I compiled it, and the sysrq is definitely in the config. No doubt at all. I also use make mrproper and config again before dep and actual compile. Maybe it is just a quirk/oddball. D. Stimits, [EMAIL PROTECTED] Have you tried echo 1 /proc/sys/kernel/sysrq? You need both, compiled in and activation. - 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: Linux 2.4.5-ac9
Quite positive it's the right map file. I used -m and specified the exact file. David Jeff Garzik wrote: >David Ford wrote: > >> >>EIP; c01269f9<= >>Trace; c01b1021 >>Trace; c01b1c43 >>Trace; c01b2643 >>Trace; c0137fc0 <__emul_lookup_dentry+a4/fc> >>Trace; c0138871 >>Trace; c0167ccb >>Trace; c012e389 >>Trace; c012e2c2 >> > >This trace looks corrupted to me... are you sure that System.map for the >crashed kernel matches -exactly- with the one ksymoops used to decode >this? It uses /proc/ksyms by default, which is incorrect for most >postmortem ksymoops runs... > >rtl8139_interrupt doesn't call tx_timeout, which doesn't call >read_eeprom, which doesn't call proc_getdata. > - 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: Linux 2.4.5-ac9
2.4.5-ac8 has a brokenness about it.
sshd stalled in [down] with the following, subsequent sshd attempts
which needed a tty resulted in D state the same as the first:
invalid operand:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010086
eax: 001b ebx: c13bf768 ecx: c0345060 edx: 2c76
esi: c0a54000 edi: c0a549aa ebp: c0a549aa esp: c57afe54
ds: 0018 es: 0018 ss: 0018
Process sshd (pid: 3627, stackpage=c57af000)
Stack: c02cab45 04dc 800a c03dc900 c03dc900 1000
0246
c01b1021 0c3c 0007 c03dc900 c01b1c43 000a c03dc900
c03dc900
c13c9e50 000a
c13c9e50
Call Trace: [] [] [] []
[]
[] [] [] [] []
Code: 0f 0b 83 c4 08 89 f6 f6 43 11 04 74 51 b8 a5 c2 0f 17 87 06
>>EIP; c01269f9<=
Trace; c01b1021
Trace; c01b1c43
Trace; c01b2643
Trace; c0137fc0 <__emul_lookup_dentry+a4/fc>
Trace; c0138871
Trace; c0167ccb
Trace; c012e389
Trace; c012e2c2
Trace; c012e5b0
Trace; c0106a93
Code; c01269f9
<_EIP>:
Code; c01269f9<=
0: 0f 0b ud2a <=
Code; c01269fb
2: 83 c4 08 add$0x8,%esp
Code; c01269fe
5: 89 f6 mov%esi,%esi
Code; c0126a00
7: f6 43 11 04 testb $0x4,0x11(%ebx)
Code; c0126a04
b: 74 51 je 5e <_EIP+0x5e> c0126a57
Code; c0126a06
d: b8 a5 c2 0f 17mov$0x170fc2a5,%eax
Code; c0126a0b
12: 87 06 xchg %eax,(%esi)
Alan Cox wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
>
>Intermediate diffs are available from
> http://www.bzimage.org
>
>In terms of going through the code audit almost all the sound drivers still
>need fixing to lock against format changes during a read/write. Poll creating
>and starting a buffer as write does and also mmap during write, write during
>an mmap.
>
>2.4.5-ac9
>
-
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: Linux 2.4.5-ac9
2.4.5-ac8 has a brokenness about it.
sshd stalled in [down] with the following, subsequent sshd attempts
which needed a tty resulted in D state the same as the first:
invalid operand:
CPU:0
EIP:0010:[c01269f9]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010086
eax: 001b ebx: c13bf768 ecx: c0345060 edx: 2c76
esi: c0a54000 edi: c0a549aa ebp: c0a549aa esp: c57afe54
ds: 0018 es: 0018 ss: 0018
Process sshd (pid: 3627, stackpage=c57af000)
Stack: c02cab45 04dc 800a c03dc900 c03dc900 1000
0246
c01b1021 0c3c 0007 c03dc900 c01b1c43 000a c03dc900
c03dc900
c13c9e50 000a
c13c9e50
Call Trace: [c01b1021] [c01b1c43] [c01b2643] [c0137fc0]
[c0138871]
[c0167ccb] [c012e389] [c012e2c2] [c012e5b0] [c0106a93]
Code: 0f 0b 83 c4 08 89 f6 f6 43 11 04 74 51 b8 a5 c2 0f 17 87 06
EIP; c01269f9 proc_getdata+4d/154 =
Trace; c01b1021 read_eeprom+131/1a8
Trace; c01b1c43 rtl8139_tx_timeout+143/148
Trace; c01b2643 rtl8139_interrupt+5f/170
Trace; c0137fc0 __emul_lookup_dentry+a4/fc
Trace; c0138871 open_namei+4d1/560
Trace; c0167ccb leaf_define_dest_src_infos+1a7/1ac
Trace; c012e389 do_readv_writev+15d/228
Trace; c012e2c2 do_readv_writev+96/228
Trace; c012e5b0 sys_pread+bc/d0
Trace; c0106a93 system_call+23/40
Code; c01269f9 proc_getdata+4d/154
_EIP:
Code; c01269f9 proc_getdata+4d/154 =
0: 0f 0b ud2a =
Code; c01269fb proc_getdata+4f/154
2: 83 c4 08 add$0x8,%esp
Code; c01269fe proc_getdata+52/154
5: 89 f6 mov%esi,%esi
Code; c0126a00 proc_getdata+54/154
7: f6 43 11 04 testb $0x4,0x11(%ebx)
Code; c0126a04 proc_getdata+58/154
b: 74 51 je 5e _EIP+0x5e c0126a57
proc_getdata+ab/154
Code; c0126a06 proc_getdata+5a/154
d: b8 a5 c2 0f 17mov$0x170fc2a5,%eax
Code; c0126a0b proc_getdata+5f/154
12: 87 06 xchg %eax,(%esi)
Alan Cox wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
Intermediate diffs are available from
http://www.bzimage.org
In terms of going through the code audit almost all the sound drivers still
need fixing to lock against format changes during a read/write. Poll creating
and starting a buffer as write does and also mmap during write, write during
an mmap.
2.4.5-ac9
-
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: Linux 2.4.5-ac9
Quite positive it's the right map file. I used -m and specified the exact file. David Jeff Garzik wrote: David Ford wrote: EIP; c01269f9 proc_getdata+4d/154 = Trace; c01b1021 read_eeprom+131/1a8 Trace; c01b1c43 rtl8139_tx_timeout+143/148 Trace; c01b2643 rtl8139_interrupt+5f/170 Trace; c0137fc0 __emul_lookup_dentry+a4/fc Trace; c0138871 open_namei+4d1/560 Trace; c0167ccb leaf_define_dest_src_infos+1a7/1ac Trace; c012e389 do_readv_writev+15d/228 Trace; c012e2c2 do_readv_writev+96/228 This trace looks corrupted to me... are you sure that System.map for the crashed kernel matches -exactly- with the one ksymoops used to decode this? It uses /proc/ksyms by default, which is incorrect for most postmortem ksymoops runs... rtl8139_interrupt doesn't call tx_timeout, which doesn't call read_eeprom, which doesn't call proc_getdata. - 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: Selectively refusing TCP connections
Is there an example somewhere of this? David >You can push a BPF (LPF) filter expression onto a LISTEN socket that checks >every incoming packet using SO_ATTACH_FILTER. > - 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: Selectively refusing TCP connections
Is there an example somewhere of this? David You can push a BPF (LPF) filter expression onto a LISTEN socket that checks every incoming packet using SO_ATTACH_FILTER. - 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: [PATCH] drivers/telephony/phonedev.c (brings this code up to date with Quicknet CVS)
Alrighty. That eliminates the patch. I'll rewrite the ixj.c according
to this. ixj.c will be a large patch due to the numerous revisions, I
don't know how well it can be broken up into small pieces. Do you want
small pieces still? The ChangeLog shows all the fixes for the
revisions. There have been 68 revisions since the version listed in the
kernel's tree.
David
Alan Cox wrote:
>>phonedev.diff is against 2.4.4 and brings the file phonedev.c up to date
>>with respect to the Quicknet CVS. Changes are very minor, mostly #if
>>LINUX_VERSION_CODE matching and structure updates. Small off by one
>>fixes and file operation semantics updates.
>>
>
>I intentionally dont keep back compat glue in the mainstream kernel
>
>>@@ -101,20 +134,25 @@
>>
>> if (unit != PHONE_UNIT_ANY) {
>> base = unit;
>>- end = unit + 1; /* enter the loop at least one time */
>>+ end = unit;
>>
>
>This unfixes a bug too.
>
>All rejected
>
-
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: [PATCH] drivers/telephony/phonedev.c (brings this code up to date with Quicknet CVS)
Alrighty. That eliminates the patch. I'll rewrite the ixj.c according
to this. ixj.c will be a large patch due to the numerous revisions, I
don't know how well it can be broken up into small pieces. Do you want
small pieces still? The ChangeLog shows all the fixes for the
revisions. There have been 68 revisions since the version listed in the
kernel's tree.
David
Alan Cox wrote:
phonedev.diff is against 2.4.4 and brings the file phonedev.c up to date
with respect to the Quicknet CVS. Changes are very minor, mostly #if
LINUX_VERSION_CODE matching and structure updates. Small off by one
fixes and file operation semantics updates.
I intentionally dont keep back compat glue in the mainstream kernel
@@ -101,20 +134,25 @@
if (unit != PHONE_UNIT_ANY) {
base = unit;
- end = unit + 1; /* enter the loop at least one time */
+ end = unit;
This unfixes a bug too.
All rejected
-
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] drivers/telephony/phonedev.c (brings this code up to date with Quicknet CVS)
phonedev.diff is against 2.4.4 and brings the file phonedev.c up to date
with respect to the Quicknet CVS. Changes are very minor, mostly #if
LINUX_VERSION_CODE matching and structure updates. Small off by one
fixes and file operation semantics updates.
There is no impact to other files or functions functions.
David
--- drivers/telephony/phonedev.cTue Sep 19 08:31:53 2000
+++ /zip/code/VoIP/ixj/phonedev.c Sat May 12 17:32:05 2001
@@ -12,8 +12,14 @@
*
* Fixes: Mar 01 2000 Thomas Sparr, <[EMAIL PROTECTED]>
* phone_register_device now works with unit!=PHONE_UNIT_ANY
+ *
+ * May 12 2001 David Ford, <[EMAIL PROTECTED]>
+ * brought kernel version up to date with CVS, minor changes
*/
+#if LINUX_VERSION_CODE < 0x020400
+#include
+#endif
#include
#include
#include
@@ -23,13 +29,16 @@
#include
#include
#include
+#if LINUX_VERSION_CODE >= 0x020400
#include
+#endif
#include
#include
#include
+#if LINUX_VERSION_CODE >= 0x020400
#include
-
+#endif
#define PHONE_NUM_DEVICES 256
@@ -38,8 +47,9 @@
*/
static struct phone_device *phone_device[PHONE_NUM_DEVICES];
+#if LINUX_VERSION_CODE >= 0x020400
static DECLARE_MUTEX(phone_lock);
-
+#endif
/*
*Open a phone device.
*/
@@ -49,26 +59,48 @@
unsigned int minor = MINOR(inode->i_rdev);
int err = 0;
struct phone_device *p;
+#if LINUX_VERSION_CODE >= 0x020400
struct file_operations *old_fops, *new_fops = NULL;
-
+#endif
if (minor >= PHONE_NUM_DEVICES)
return -ENODEV;
+#if LINUX_VERSION_CODE >= 0x020400
down(_lock);
+#endif
p = phone_device[minor];
+#if LINUX_VERSION_CODE < 0x020400
+ if (p == NULL) {
+#else
if (p)
new_fops = fops_get(p->f_op);
if (!new_fops) {
+#endif
char modname[32];
+#if LINUX_VERSION_CODE >= 0x020400
up(_lock);
+#endif
sprintf(modname, "char-major-%d-%d", PHONE_MAJOR, minor);
request_module(modname);
+#if LINUX_VERSION_CODE >= 0x020400
down(_lock);
+#endif
p = phone_device[minor];
- if (p == NULL || (new_fops = fops_get(p->f_op)) == NULL)
- {
- err=-ENODEV;
+#if LINUX_VERSION_CODE < 0x020400
+ if (p == NULL)
+ return -ENODEV;
+ }
+ if (p->open) {
+ err = p->open(p, file); /* Tell the device it is open */
+ if (err)
+ return err;
+ }
+ file->f_op = p->f_op;
+ return 0;
+#else
+ if (p == NULL || (new_fops = fops_get(p->f_op)) == NULL) {
+ err = -ENODEV;
goto end;
}
}
@@ -81,9 +113,10 @@
file->f_op = fops_get(old_fops);
}
fops_put(old_fops);
-end:
+ end:
up(_lock);
return err;
+#endif
}
/*
@@ -101,20 +134,25 @@
if (unit != PHONE_UNIT_ANY) {
base = unit;
- end = unit + 1; /* enter the loop at least one time */
+ end = unit;
}
-
+#if LINUX_VERSION_CODE >= 0x020400
down(_lock);
+#endif
for (i = base; i < end; i++) {
if (phone_device[i] == NULL) {
phone_device[i] = p;
p->minor = i;
MOD_INC_USE_COUNT;
+#if LINUX_VERSION_CODE >= 0x020400
up(_lock);
+#endif
return 0;
}
}
+#if LINUX_VERSION_CODE >= 0x020400
up(_lock);
+#endif
return -ENFILE;
}
@@ -124,48 +162,90 @@
void phone_unregister_device(struct phone_device *pfd)
{
+#if LINUX_VERSION_CODE >= 0x020400
down(_lock);
+#endif
if (phone_device[pfd->minor] != pfd)
panic("phone: bad unregister");
phone_device[pfd->minor] = NULL;
+#if LINUX_VERSION_CODE >= 0x020400
up(_lock);
+#endif
MOD_DEC_USE_COUNT;
}
-static struct file_operations phone_fops =
-{
- owner: THIS_MODULE,
- open: phone_open,
+static struct file_operations phone_fops = {
+#if LINUX_VERSION_CODE >= 0x020400
+ owner:THIS_MODULE,
+ open:phone_open,
+#else
+ NULL,
+ NULL,
+ NULL,
+ NULL, /* readdir */
+ NULL,
+ NULL,
+ NULL,
+ phone_open,
+ NULL, /* flush */
+ NULL
+#endif
};
/*
- * Board init functions
+ *Board init functions
*/
-
+
+#if LINUX_VERSION_CODE < 0x020400
+extern int ixj_init(void);
/*
*Initialise Telephony for linux
*/
+int telephony_init(void)
+#else
static int __init telephony_init(void)
+#endif
[PATCH] drivers/telephony/phonedev.c (brings this code up to date with Quicknet CVS)
phonedev.diff is against 2.4.4 and brings the file phonedev.c up to date
with respect to the Quicknet CVS. Changes are very minor, mostly #if
LINUX_VERSION_CODE matching and structure updates. Small off by one
fixes and file operation semantics updates.
There is no impact to other files or functions functions.
David
--- drivers/telephony/phonedev.cTue Sep 19 08:31:53 2000
+++ /zip/code/VoIP/ixj/phonedev.c Sat May 12 17:32:05 2001
@@ -12,8 +12,14 @@
*
* Fixes: Mar 01 2000 Thomas Sparr, [EMAIL PROTECTED]
* phone_register_device now works with unit!=PHONE_UNIT_ANY
+ *
+ * May 12 2001 David Ford, [EMAIL PROTECTED]
+ * brought kernel version up to date with CVS, minor changes
*/
+#if LINUX_VERSION_CODE 0x020400
+#include linux/config.h
+#endif
#include linux/version.h
#include linux/module.h
#include linux/types.h
@@ -23,13 +29,16 @@
#include linux/string.h
#include linux/errno.h
#include linux/phonedev.h
+#if LINUX_VERSION_CODE = 0x020400
#include linux/init.h
+#endif
#include asm/uaccess.h
#include asm/system.h
#include linux/kmod.h
+#if LINUX_VERSION_CODE = 0x020400
#include linux/sem.h
-
+#endif
#define PHONE_NUM_DEVICES 256
@@ -38,8 +47,9 @@
*/
static struct phone_device *phone_device[PHONE_NUM_DEVICES];
+#if LINUX_VERSION_CODE = 0x020400
static DECLARE_MUTEX(phone_lock);
-
+#endif
/*
*Open a phone device.
*/
@@ -49,26 +59,48 @@
unsigned int minor = MINOR(inode-i_rdev);
int err = 0;
struct phone_device *p;
+#if LINUX_VERSION_CODE = 0x020400
struct file_operations *old_fops, *new_fops = NULL;
-
+#endif
if (minor = PHONE_NUM_DEVICES)
return -ENODEV;
+#if LINUX_VERSION_CODE = 0x020400
down(phone_lock);
+#endif
p = phone_device[minor];
+#if LINUX_VERSION_CODE 0x020400
+ if (p == NULL) {
+#else
if (p)
new_fops = fops_get(p-f_op);
if (!new_fops) {
+#endif
char modname[32];
+#if LINUX_VERSION_CODE = 0x020400
up(phone_lock);
+#endif
sprintf(modname, char-major-%d-%d, PHONE_MAJOR, minor);
request_module(modname);
+#if LINUX_VERSION_CODE = 0x020400
down(phone_lock);
+#endif
p = phone_device[minor];
- if (p == NULL || (new_fops = fops_get(p-f_op)) == NULL)
- {
- err=-ENODEV;
+#if LINUX_VERSION_CODE 0x020400
+ if (p == NULL)
+ return -ENODEV;
+ }
+ if (p-open) {
+ err = p-open(p, file); /* Tell the device it is open */
+ if (err)
+ return err;
+ }
+ file-f_op = p-f_op;
+ return 0;
+#else
+ if (p == NULL || (new_fops = fops_get(p-f_op)) == NULL) {
+ err = -ENODEV;
goto end;
}
}
@@ -81,9 +113,10 @@
file-f_op = fops_get(old_fops);
}
fops_put(old_fops);
-end:
+ end:
up(phone_lock);
return err;
+#endif
}
/*
@@ -101,20 +134,25 @@
if (unit != PHONE_UNIT_ANY) {
base = unit;
- end = unit + 1; /* enter the loop at least one time */
+ end = unit;
}
-
+#if LINUX_VERSION_CODE = 0x020400
down(phone_lock);
+#endif
for (i = base; i end; i++) {
if (phone_device[i] == NULL) {
phone_device[i] = p;
p-minor = i;
MOD_INC_USE_COUNT;
+#if LINUX_VERSION_CODE = 0x020400
up(phone_lock);
+#endif
return 0;
}
}
+#if LINUX_VERSION_CODE = 0x020400
up(phone_lock);
+#endif
return -ENFILE;
}
@@ -124,48 +162,90 @@
void phone_unregister_device(struct phone_device *pfd)
{
+#if LINUX_VERSION_CODE = 0x020400
down(phone_lock);
+#endif
if (phone_device[pfd-minor] != pfd)
panic(phone: bad unregister);
phone_device[pfd-minor] = NULL;
+#if LINUX_VERSION_CODE = 0x020400
up(phone_lock);
+#endif
MOD_DEC_USE_COUNT;
}
-static struct file_operations phone_fops =
-{
- owner: THIS_MODULE,
- open: phone_open,
+static struct file_operations phone_fops = {
+#if LINUX_VERSION_CODE = 0x020400
+ owner:THIS_MODULE,
+ open:phone_open,
+#else
+ NULL,
+ NULL,
+ NULL,
+ NULL, /* readdir */
+ NULL,
+ NULL,
+ NULL,
+ phone_open,
+ NULL, /* flush */
+ NULL
+#endif
};
/*
- * Board init functions
+ *Board init functions
*/
-
+
+#if LINUX_VERSION_CODE 0x020400
+extern int ixj_init(void);
/*
*Initialise Telephony for linux
*/
+int telephony_init(void)
+#else
static int
Re: ECN: Volunteers needed
I simply crontab an ECN off period for five minutes every hour and flush the mail queue. David. Holger Lubitz wrote: >"H. Peter Anvin" wrote: > >>I suspect that the main way to get this thing fixed is to make sure >>ECN is enabled on the server side; for example, we have turned on ECN >>on kernel.org. If a user is using a broken software stack, it's their >>loss, not ours. >> > >This is what we do here, too. The only exceptions: Our mail server >(needs to deliver mail, even to broken sites) and our web proxy server >(also needs to connect to broken sites sometimes). Everything else is >ECN enabled. And this is the approach I'd suggest to anybody running 2.4 >servers. > - 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: ECN: Volunteers needed
I simply crontab an ECN off period for five minutes every hour and flush the mail queue. David. Holger Lubitz wrote: H. Peter Anvin wrote: I suspect that the main way to get this thing fixed is to make sure ECN is enabled on the server side; for example, we have turned on ECN on kernel.org. If a user is using a broken software stack, it's their loss, not ours. This is what we do here, too. The only exceptions: Our mail server (needs to deliver mail, even to broken sites) and our web proxy server (also needs to connect to broken sites sometimes). Everything else is ECN enabled. And this is the approach I'd suggest to anybody running 2.4 servers. - 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/
Another report of mozilla in D state, related to the 'uninterruptible sleep' thread
Second time around, I didn't evoke any interest the first time. I reported it back on Mar/27. It is still an almost daily problem requiring a reboot. Mozilla gets stuck in down_write_failed. This time I'm sure it's not reiser's fault. # uname -r 2.4.3-pre8 mozilla-bin D C781849C 0 21055 1(NOTLB) 20611 Call Trace: [] [] [] [leaf_copy_items+121/252] [leaf_paste_in_buffer+239/672] [leaf_cut_from_buffer+486/984] [leaf_cut_from_buffer+863/984] [balance_leaf+8645/9544] [balance_leaf+9225/9544] [leaf_item_bottle+916/1260] [balance_leaf+9505/9544] [balance_leaf+9225/9544] [leaf_item_bottle+916/1260] [balance_leaf+9505/9544] [] [bin_search_in_dir_item+58/196] [leaf_copy_items+121/252] [leaf_paste_in_buffer+239/672] [] [flush_commit_list+66/908] [flush_journal_list+531/944] [free_list_bitmaps+30/60] [reiserfs_unlink+167/460] [posix_lock_file+526/1232] [empty_bad_page+3213/4096] [empty_bad_page+2717/4096] [fib_flag_trans+35/60] [empty_bad_pte_table+3363/4096] If someone is actually interested, it'd be neat to get this fixed. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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/
Another report of mozilla in D state, related to the 'uninterruptible sleep' thread
Second time around, I didn't evoke any interest the first time. I reported it back on Mar/27. It is still an almost daily problem requiring a reboot. Mozilla gets stuck in down_write_failed. This time I'm sure it's not reiser's fault. # uname -r 2.4.3-pre8 mozilla-bin D C781849C 0 21055 1(NOTLB) 20611 Call Trace: [ff00] [ff00] [ff00] [leaf_copy_items+121/252] [leaf_paste_in_buffer+239/672] [leaf_cut_from_buffer+486/984] [leaf_cut_from_buffer+863/984] [balance_leaf+8645/9544] [balance_leaf+9225/9544] [leaf_item_bottle+916/1260] [balance_leaf+9505/9544] [balance_leaf+9225/9544] [leaf_item_bottle+916/1260] [balance_leaf+9505/9544] [f000] [bin_search_in_dir_item+58/196] [leaf_copy_items+121/252] [leaf_paste_in_buffer+239/672] [d086f044] [flush_commit_list+66/908] [flush_journal_list+531/944] [free_list_bitmaps+30/60] [reiserfs_unlink+167/460] [posix_lock_file+526/1232] [empty_bad_page+3213/4096] [empty_bad_page+2717/4096] [fib_flag_trans+35/60] [empty_bad_pte_table+3363/4096] If someone is actually interested, it'd be neat to get this fixed. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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/
sysrq-t followup to possible reiserfs bug
Ok, here's the trace, this time it didn't die on me. mozilla-bin D CDC1779C 0 6530 1(NOTLB) 6533 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [scsi_queue_next_request+62/248] [__scsi_end_request+327/340] [scsi_io_completion+394/880] [rw_intr+459/472] [scsi_old_done+67/1416] [scsi_old_done+1399/1416] [is_tree_node+55/84] [search_by_key+2059/3172] [is_tree_node+55/84] [search_by_key+2059/3172] [search_for_position_by_key+170/896] [search_for_position_by_key+551/896] [make_cpu_key+57/64] [_get_block_create_0+133/1012] [pathrelse+28/44] [_get_block_create_0+413/1012] [] [__alloc_pages+222/720] [schedule+624/916] [get_cnode+17/112] [journal_mark_dirty+473/776] [] [check_journal_end+531/572] [do_journal_end+177/2652] [journal_end+22/28] [reiserfs_dirty_inode+75/92] [__mark_inode_dirty+46/112] [down_write_failed+89/120] [__down_write_failed+17/32] [stext_lock+95/8170] [system_call+51/56] mozilla-bin D CDC1779C12 6533 1(NOTLB)6530 1516 Call Trace: [] [] [] [schedule+624/916] [get_cnode+17/112] [journal_mark_dirty+473/776] [] [check_journal_end+531/572] [do_journal_end+177/2652] [journal_end+22/28] [reiserfs_dirty_inode+75/92] [__mark_inode_dirty+46/112] [down_write_failed+89/120] [__down_write_failed+17/32] [stext_lock+95/8170] [system_call+51/56] -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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/
Bug in reiserfs? 2.4.3-pre6
Lately I've been having to reboot every few days due to D state processes, always mozilla so far. When I exit mozilla it doesn't always cleanly shutdown, sometimes processes are left behind. I'll post what I have and if I'm lucky I'll follow up with a backtrace on the pids. Last time I tried a sysrq-t, it killed X from under me. # ps aux|grep mozi david 6530 0.3 7.1 33444 18180 ? D11:34 0:00 /usr/src/mozilla/ david 6533 0.0 7.1 33444 18180 ? D11:34 0:00 /usr/src/mozilla/ # ps -eo pid,args,wchan|grep moz 6530 /usr/src/mozilla down_write_failed 6533 /usr/src/mozilla down_write_failed 5 [kreclaimd] kreclaimd 6 [bdflush]bdflush 18 [kreiserfsd] reiserfs_journal_commit_thread # ls -l /proc/6530/fd total 0 lrwx-- 1 davidusers 64 Mar 27 11:42 0 -> /dev/vc/12 lrwx-- 1 davidusers 64 Mar 27 11:42 1 -> /dev/vc/12 lrwx-- 1 davidusers 64 Mar 27 11:42 2 -> /dev/vc/12 lrwx-- 1 davidusers 64 Mar 27 11:42 3 -> /dev/zero lrwx-- 1 davidusers 64 Mar 27 11:42 4 -> /usr/src/mozilla/component.reg lr-x-- 1 davidusers 64 Mar 27 11:42 5 -> pipe:[3377132] l-wx-- 1 davidusers 64 Mar 27 11:42 6 -> pipe:[3377132] lr-x-- 1 davidusers 64 Mar 27 11:42 7 -> /usr/src/mozilla/chrome/classic.jar lrwx-- 1 davidusers 64 Mar 27 11:42 8 -> socket:[3377145] lr-x-- 1 davidusers 64 Mar 27 11:42 9 -> /usr/src/mozilla/chrome/en-US.jar lr-x-- 1 davidusers 64 Mar 27 11:42 10 -> pipe:[3377180] l-wx-- 1 davidusers 64 Mar 27 11:42 11 -> pipe:[3377180] lr-x-- 1 davidusers 64 Mar 27 11:42 12 -> pipe:[3377181] l-wx-- 1 davidusers 64 Mar 27 11:42 13 -> pipe:[3377181] lr-x-- 1 davidusers 64 Mar 27 11:42 14 -> pipe:[3377298] l-wx-- 1 davidusers 64 Mar 27 11:42 15 -> pipe:[3377298] lr-x-- 1 davidusers 64 Mar 27 11:42 16 -> /usr/src/mozilla/chrome/comm.jar lr-x-- 1 davidusers 64 Mar 27 11:42 17 -> /usr/src/mozilla/chrome/toolkit.jar lr-x-- 1 davidusers 64 Mar 27 11:42 18 -> /usr/src/mozilla/chrome/messenger.jar lr-x-- 1 davidusers 64 Mar 27 11:42 19 -> /usr/src/mozilla/chrome/US.jar lr-x-- 1 davidusers 64 Mar 27 11:42 20 -> /usr/src/mozilla/chrome/en-unix.jar lr-x-- 1 davidusers 64 Mar 27 11:42 21 -> /usr/src/mozilla/chrome/chatzilla.jar -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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/
Bug in reiserfs? 2.4.3-pre6
Lately I've been having to reboot every few days due to D state processes, always mozilla so far. When I exit mozilla it doesn't always cleanly shutdown, sometimes processes are left behind. I'll post what I have and if I'm lucky I'll follow up with a backtrace on the pids. Last time I tried a sysrq-t, it killed X from under me. # ps aux|grep mozi david 6530 0.3 7.1 33444 18180 ? D11:34 0:00 /usr/src/mozilla/ david 6533 0.0 7.1 33444 18180 ? D11:34 0:00 /usr/src/mozilla/ # ps -eo pid,args,wchan|grep moz 6530 /usr/src/mozilla down_write_failed 6533 /usr/src/mozilla down_write_failed 5 [kreclaimd] kreclaimd 6 [bdflush]bdflush 18 [kreiserfsd] reiserfs_journal_commit_thread # ls -l /proc/6530/fd total 0 lrwx-- 1 davidusers 64 Mar 27 11:42 0 - /dev/vc/12 lrwx-- 1 davidusers 64 Mar 27 11:42 1 - /dev/vc/12 lrwx-- 1 davidusers 64 Mar 27 11:42 2 - /dev/vc/12 lrwx-- 1 davidusers 64 Mar 27 11:42 3 - /dev/zero lrwx-- 1 davidusers 64 Mar 27 11:42 4 - /usr/src/mozilla/component.reg lr-x-- 1 davidusers 64 Mar 27 11:42 5 - pipe:[3377132] l-wx-- 1 davidusers 64 Mar 27 11:42 6 - pipe:[3377132] lr-x-- 1 davidusers 64 Mar 27 11:42 7 - /usr/src/mozilla/chrome/classic.jar lrwx-- 1 davidusers 64 Mar 27 11:42 8 - socket:[3377145] lr-x-- 1 davidusers 64 Mar 27 11:42 9 - /usr/src/mozilla/chrome/en-US.jar lr-x-- 1 davidusers 64 Mar 27 11:42 10 - pipe:[3377180] l-wx-- 1 davidusers 64 Mar 27 11:42 11 - pipe:[3377180] lr-x-- 1 davidusers 64 Mar 27 11:42 12 - pipe:[3377181] l-wx-- 1 davidusers 64 Mar 27 11:42 13 - pipe:[3377181] lr-x-- 1 davidusers 64 Mar 27 11:42 14 - pipe:[3377298] l-wx-- 1 davidusers 64 Mar 27 11:42 15 - pipe:[3377298] lr-x-- 1 davidusers 64 Mar 27 11:42 16 - /usr/src/mozilla/chrome/comm.jar lr-x-- 1 davidusers 64 Mar 27 11:42 17 - /usr/src/mozilla/chrome/toolkit.jar lr-x-- 1 davidusers 64 Mar 27 11:42 18 - /usr/src/mozilla/chrome/messenger.jar lr-x-- 1 davidusers 64 Mar 27 11:42 19 - /usr/src/mozilla/chrome/US.jar lr-x-- 1 davidusers 64 Mar 27 11:42 20 - /usr/src/mozilla/chrome/en-unix.jar lr-x-- 1 davidusers 64 Mar 27 11:42 21 - /usr/src/mozilla/chrome/chatzilla.jar -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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/
sysrq-t followup to possible reiserfs bug
Ok, here's the trace, this time it didn't die on me. mozilla-bin D CDC1779C 0 6530 1(NOTLB) 6533 Call Trace: [ff00] [ff00] [ff00] [e000] [e000] [e000] [e000] [e000] [e000] [e000] [e000] [e000] [e000] [e000] [e000] [e000] [fff801a1] [f2a9a870] [scsi_queue_next_request+62/248] [__scsi_end_request+327/340] [scsi_io_completion+394/880] [rw_intr+459/472] [scsi_old_done+67/1416] [scsi_old_done+1399/1416] [is_tree_node+55/84] [search_by_key+2059/3172] [is_tree_node+55/84] [search_by_key+2059/3172] [search_for_position_by_key+170/896] [search_for_position_by_key+551/896] [make_cpu_key+57/64] [_get_block_create_0+133/1012] [pathrelse+28/44] [_get_block_create_0+413/1012] [f000] [__alloc_pages+222/720] [schedule+624/916] [get_cnode+17/112] [journal_mark_dirty+473/776] [d1478044] [check_journal_end+531/572] [do_journal_end+177/2652] [journal_end+22/28] [reiserfs_dirty_inode+75/92] [__mark_inode_dirty+46/112] [down_write_failed+89/120] [__down_write_failed+17/32] [stext_lock+95/8170] [system_call+51/56] mozilla-bin D CDC1779C12 6533 1(NOTLB)6530 1516 Call Trace: [ff00] [ff00] [ff00] [schedule+624/916] [get_cnode+17/112] [journal_mark_dirty+473/776] [d1478044] [check_journal_end+531/572] [do_journal_end+177/2652] [journal_end+22/28] [reiserfs_dirty_inode+75/92] [__mark_inode_dirty+46/112] [down_write_failed+89/120] [__down_write_failed+17/32] [stext_lock+95/8170] [system_call+51/56] -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: Linux should better cope with power failure
Otto Wyss wrote: > > No, the correct answer is if you want a reliable recovery then run your disks > > in non write buffered mode. I.e. turn on sync in fstab. > > > You probably haven't tried to use sync or you would have noticed the > performace penalty. I think nobody really considers sync an alternative. > > O. Wyss You can't have the best of everything. There are tradeoffs. A viable option is a journaled filesystem. Linux boasts a few, two of which are at your fingertips by way of config options. Read up on JFS or ReiserFS. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: Linux should better cope with power failure
Otto Wyss wrote: No, the correct answer is if you want a reliable recovery then run your disks in non write buffered mode. I.e. turn on sync in fstab. You probably haven't tried to use sync or you would have noticed the performace penalty. I think nobody really considers sync an alternative. O. Wyss You can't have the best of everything. There are tradeoffs. A viable option is a journaled filesystem. Linux boasts a few, two of which are at your fingertips by way of config options. Read up on JFS or ReiserFS. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: Linux should better cope with power failure
Otto Wyss wrote: > > I had a similar experience: > > X crashed , hosing the console , so I could not initiate > > a proper shutdown. > > > > Here I must note that the response you got on linux-kernel is > > shameful. > > > Thanks, but I expected it a little bit. All around Linux is centered > around getting the highest performance out of it and very low (to low > IMHO) is done to have a save system. The attitude "It doesn't matter > making mistakes, they get fix anyhow" annoys me most, especially if it > were easy to prevent them. No, the correct answer is if you want a reliable recovery then run your disks in non write buffered mode. I.e. turn on sync in fstab. It's all about RTFM and knowing the difference between buffered actions and nonbuffered. Everything you need to have a safely clean and proper crash recovery system already is within your power, you just need to read the man pages and fix your fstab instead of blaming linux-kernel for bad attitudes. Yes, it's very easy to prevent e2fsck runs. Run synchronous or journaled file systems. > > > Don't we tell children never go close to any abyss or doesn't have > > > alpinist a saying "never go to the limits"? So why is this simple rule > > > always broken with computers? > > > > Is there a similar expression which could be hammered into any > developers mind, i.e. "Don't make errors, others already do them for you". There is also a very common expression...RTFM. Please understand what you are doing before you do it, particularly before you bad mouth others for having a bad attitude. Don't blame race car makers for destructive engine failure when you expect it to act like a family car. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: Linux should better cope with power failure
Otto Wyss wrote: I had a similar experience: X crashed , hosing the console , so I could not initiate a proper shutdown. Here I must note that the response you got on linux-kernel is shameful. Thanks, but I expected it a little bit. All around Linux is centered around getting the highest performance out of it and very low (to low IMHO) is done to have a save system. The attitude "It doesn't matter making mistakes, they get fix anyhow" annoys me most, especially if it were easy to prevent them. No, the correct answer is if you want a reliable recovery then run your disks in non write buffered mode. I.e. turn on sync in fstab. It's all about RTFM and knowing the difference between buffered actions and nonbuffered. Everything you need to have a safely clean and proper crash recovery system already is within your power, you just need to read the man pages and fix your fstab instead of blaming linux-kernel for bad attitudes. Yes, it's very easy to prevent e2fsck runs. Run synchronous or journaled file systems. Don't we tell children never go close to any abyss or doesn't have alpinist a saying "never go to the limits"? So why is this simple rule always broken with computers? Is there a similar expression which could be hammered into any developers mind, i.e. "Don't make errors, others already do them for you". There is also a very common expression...RTFM. Please understand what you are doing before you do it, particularly before you bad mouth others for having a bad attitude. Don't blame race car makers for destructive engine failure when you expect it to act like a family car. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: esound (esd), 2.4.[12] chopped up sound -- solved
a) not all drivers are created equal b) esd should check the return value anyway -d Doug Ledford wrote: > David Ford wrote: > > > > Actually you probably upgraded to a non-broken version of esd. Stock esd -still- > > writes to the socket without regard to return value. If the write only accepted > > 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at > > 4097, not 2099. esd is incredibly bad about err checking as is old e stuff. > > > > I posted my last patch for esd here and to other places in June of 2000. All it > > does is check for return value and adjust the writes accordingly. For reference, > > the patch is at http://stuph.org/esound-audio.c.patch. > > Why would esd get a short write() unless it is opening the file in non > blocking mode (which I didn't see when I was working on the i810 sound > driver)? If esd is writing to a file in blocking mode and that write is > returning short, then that sounds like a driver bug to me. -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: esound (esd), 2.4.[12] chopped up sound -- solved
Actually you probably upgraded to a non-broken version of esd. Stock esd -still- writes to the socket without regard to return value. If the write only accepted 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at 4097, not 2099. esd is incredibly bad about err checking as is old e stuff. I posted my last patch for esd here and to other places in June of 2000. All it does is check for return value and adjust the writes accordingly. For reference, the patch is at http://stuph.org/esound-audio.c.patch. -d Peter Lund wrote: > Pozsar Balazs wrote: > > > Are you sure that the problem isn't at the mp3->raw conversino point? In > > mandrake for example, mpg123 is badly compiled, and plays nicely on 2.2, > > but awfully on 2.4. > > Positive. Anyway, the problem is solved now...I just want to investigate it a > little bit further because I think there is something I can learn from it. > > In my original mail I wrote: > > > I've tested it on a freshly booted machine without X and gnome, only the bare > > essentials for the machine + esd + esdcat (I converted one of my mp3's into raw > > audio for the test). > > 1) mpg123 and XMMS sounded fine under 2.2.18 (which I hope was clear from what I > wrote). > 2) I played the raw sound directly to /dev/dsp -- worked great > 3) I played it through esd on 2.2.18 -- worked great > (the latter two points should have been made explicitly but weren't - sorry) > > so the conclusion is that there is some bad interaction between 2.4.x, the esd > version I was using, and the esdcat version I was using. esdcat seemed pretty > simple, it just > wrote 4K at a time to a Unix socket, blocking as necessary, so I figured the > culprit was elsewhere. > > The problem went away when I upgraded to the esd in Debian unstable (in the > esound package). I was either using an esd binary from Debian stable or one > from one of the Ximian packages. I'm still not sure whether they supply an esd > themselves or just rely on the standard Debian one. > > I took a look at the diff between the stable/testing and unstable versions of > the Debian esound package and there was a change in two or three places that > seems to give a plausible explanation. A simple write() was changed into a loop > that retried the write() in case it was partial with an error code of EAGAIN > (after sleeping 100 microseconds and with an upper bound on the number of > retries). > > My theory now is that the sound driver changed in some way from 2.2.x to 2.4.x > so some writes would only move a limited amount of bytes to the driver. Maybe > the driver only accepts about 4K in each version and the kernel performs the > retries, sleeping in between? Just a theory until I know more. > > Anyway, it works now with 2.4.x, even without the lowlatency patch from Andrew > Morton. > > -Peter > - > 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/ -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: esound (esd), 2.4.[12] chopped up sound -- solved
Actually you probably upgraded to a non-broken version of esd. Stock esd -still- writes to the socket without regard to return value. If the write only accepted 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at 4097, not 2099. esd is incredibly bad about err checking as is old e stuff. I posted my last patch for esd here and to other places in June of 2000. All it does is check for return value and adjust the writes accordingly. For reference, the patch is at http://stuph.org/esound-audio.c.patch. -d Peter Lund wrote: Pozsar Balazs wrote: Are you sure that the problem isn't at the mp3-raw conversino point? In mandrake for example, mpg123 is badly compiled, and plays nicely on 2.2, but awfully on 2.4. Positive. Anyway, the problem is solved now...I just want to investigate it a little bit further because I think there is something I can learn from it. In my original mail I wrote: I've tested it on a freshly booted machine without X and gnome, only the bare essentials for the machine + esd + esdcat (I converted one of my mp3's into raw audio for the test). 1) mpg123 and XMMS sounded fine under 2.2.18 (which I hope was clear from what I wrote). 2) I played the raw sound directly to /dev/dsp -- worked great 3) I played it through esd on 2.2.18 -- worked great (the latter two points should have been made explicitly but weren't - sorry) so the conclusion is that there is some bad interaction between 2.4.x, the esd version I was using, and the esdcat version I was using. esdcat seemed pretty simple, it just wrote 4K at a time to a Unix socket, blocking as necessary, so I figured the culprit was elsewhere. The problem went away when I upgraded to the esd in Debian unstable (in the esound package). I was either using an esd binary from Debian stable or one from one of the Ximian packages. I'm still not sure whether they supply an esd themselves or just rely on the standard Debian one. I took a look at the diff between the stable/testing and unstable versions of the Debian esound package and there was a change in two or three places that seems to give a plausible explanation. A simple write() was changed into a loop that retried the write() in case it was partial with an error code of EAGAIN (after sleeping 100 microseconds and with an upper bound on the number of retries). My theory now is that the sound driver changed in some way from 2.2.x to 2.4.x so some writes would only move a limited amount of bytes to the driver. Maybe the driver only accepts about 4K in each version and the kernel performs the retries, sleeping in between? Just a theory until I know more. Anyway, it works now with 2.4.x, even without the lowlatency patch from Andrew Morton. -Peter - 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/ -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: esound (esd), 2.4.[12] chopped up sound -- solved
a) not all drivers are created equal b) esd should check the return value anyway -d Doug Ledford wrote: David Ford wrote: Actually you probably upgraded to a non-broken version of esd. Stock esd -still- writes to the socket without regard to return value. If the write only accepted 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at 4097, not 2099. esd is incredibly bad about err checking as is old e stuff. I posted my last patch for esd here and to other places in June of 2000. All it does is check for return value and adjust the writes accordingly. For reference, the patch is at http://stuph.org/esound-audio.c.patch. Why would esd get a short write() unless it is opening the file in non blocking mode (which I didn't see when I was working on the i810 sound driver)? If esd is writing to a file in blocking mode and that write is returning short, then that sounds like a driver bug to me. -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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/
curious messages
2.4.2-ac4 Undo partial loss 208.179.59.2/5432 c1 l1 ss2/2 p1 Undo loss 208.179.59.2/5432 c2 l0 ss2/2 p0 Undo loss 208.179.59.2/25 c2 l0 ss2/2 p0 Undo partial loss 208.179.59.2/22 c1 l3 ss2/2 p3 Undo loss 208.179.59.2/143 c2 l0 ss2/3 p0 simple debug messages, or is someone (andy/dave) interested in them? -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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/
curious bug
2.4.3-pre3 richh12557 0.0 0.7 5096 1704 pts/10 D04:32 0:00 ./egg idaho richh12558 0.0 0.0 00 pts/10 Z04:32 0:00 [egg ] richh12560 0.0 0.7 5096 1704 pts/10 S04:32 0:00 ./egg idaho # ps -eo args,wchan|grep egg ./egg idaho down [egg ] do_exit ./egg idaho rt_sigsuspend kill -9 had no effect on 12557 until i killed 12560. this D state process held the load at 1.01 for hours. any takers? -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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/
curious bug
2.4.3-pre3 richh12557 0.0 0.7 5096 1704 pts/10 D04:32 0:00 ./egg idaho richh12558 0.0 0.0 00 pts/10 Z04:32 0:00 [egg defunct] richh12560 0.0 0.7 5096 1704 pts/10 S04:32 0:00 ./egg idaho # ps -eo args,wchan|grep egg ./egg idaho down [egg defunct] do_exit ./egg idaho rt_sigsuspend kill -9 had no effect on 12557 until i killed 12560. this D state process held the load at 1.01 for hours. any takers? -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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/
curious messages
2.4.2-ac4 Undo partial loss 208.179.59.2/5432 c1 l1 ss2/2 p1 Undo loss 208.179.59.2/5432 c2 l0 ss2/2 p0 Undo loss 208.179.59.2/25 c2 l0 ss2/2 p0 Undo partial loss 208.179.59.2/22 c1 l3 ss2/2 p3 Undo loss 208.179.59.2/143 c2 l0 ss2/3 p0 simple debug messages, or is someone (andy/dave) interested in them? -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Alan Cox wrote: >> I run Reiser on all but /boot, and it seems to enjoy corrupting my >> mbox'es randomly. >> Using the old-style Reiser FS format, 2.4.2-pre1, Evolution, on a CMD640 >> chipset with the fixes enabled. >> This also occurs in some log files, but I put it down to syslogd >> crashing or something. > > > Before you put that down to reiserfs can you chek 2.4.2-pre2. It may be > problems below the reiserfs layer Just as an aside, I've watched this conversation go on and on while I run reiserfs on several servers, workstations, and a notebook. I have current kernels and have watched carefully for corruption. I haven't seen any evidence of corruption on any of them including my notebook which has a bad battery and bad power connection so it tends to instantly die. Alan, is there a particular trigger to this? -d - 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: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Alan Cox wrote: I run Reiser on all but /boot, and it seems to enjoy corrupting my mbox'es randomly. Using the old-style Reiser FS format, 2.4.2-pre1, Evolution, on a CMD640 chipset with the fixes enabled. This also occurs in some log files, but I put it down to syslogd crashing or something. Before you put that down to reiserfs can you chek 2.4.2-pre2. It may be problems below the reiserfs layer Just as an aside, I've watched this conversation go on and on while I run reiserfs on several servers, workstations, and a notebook. I have current kernels and have watched carefully for corruption. I haven't seen any evidence of corruption on any of them including my notebook which has a bad battery and bad power connection so it tends to instantly die. Alan, is there a particular trigger to this? -d - 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: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs
Chris Mason wrote: > > On Thursday, February 01, 2001 02:16:43 PM -0200 Rik van Riel ><[EMAIL PROTECTED]> wrote: > >> About the system hanging completely, I wonder if it goes >> away by pressing sysrq-S (sync all disks). If it does, >> maybe Reiserfs was blocking all the pages in the inactive >> list from being written because one of the active pages >> (not a replacement candidate) needed to be written out >> first? Or does the Reiserfs ->writepage() function handle >> this? > In answer to Rik's question, no, sysrq-S doesn't fix it. The sound of the disk grind changes momentarily then it resumes. > In most cases, the reiserfs writepage func is the same as block_write_full_page. >The only difference should come when a packed tail has been mmap'd. > > Since JOURNAL_MAX_BATCH was at 100, the log should have only pinned 400k. More >blocks could be pinned, but kreiserfsd should be in the process of flushing those. > > I've been trying out a few things to send memory pressure down to reiserfs, but they >have mostly been based on the code to make fs/buffer.c use writepage for flushing. I >should have done something simple first, I'll start on that now. > > -chris http://stuph.org/VM/ is back up, no thanks to the network solutions. The files listed there have all the relevant backtraces. -d - 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: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
How about a simple patch to the top level makefile that checks the gcc
version then prints a distinct message ..'this compiler hasn't been approved
for compiling the kernel', sleeping for one second, then continuing on. This
solution doesn't stop compiling and makes a visible indicator without forcing
anything.
Sample attached.
-d
Alan Cox wrote:
> > As it stands, there is no way to determine programatically whether
> > gcc-2.96 is broken or now. The only way to do it is to check the RPM
> > version -- which, needless to say, is a bit difficult to do from the
> > C code about to be compiled. So I can't really blame Hans if he decides
> > to outlaw gcc-2.96[.0] for reiserfs compiles.
>
> Oh I can see why Hans wants to cut down his bug reporting load. I can also
> say from experience it wont work. If you put #error in then everyone will
> mail him and complain it doesnt build, if you put #warning in nobody will
> read it and if you dont put anything in you get the odd bug report anyway.
>
> Basically you can't win and unfortunately a shrink wrap forcing the user
> to read the README file for the kernel violates the GPL ..
>
> Jaded, me ?
>
> Alan
--
There is a natural aristocracy among men. The grounds of this are virtue and
talents. Thomas Jefferson
The good thing about standards is that there are so many to choose from. Andrew S.
Tanenbaum
--- Makefile.orig Sat Feb 3 00:48:26 2001
+++ MakefileSat Feb 3 00:45:00 2001
@@ -253,11 +253,23 @@
-o vmlinux
$(NM) vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw]
\)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort > System.map
-symlinks:
+symlinks: gccversioncheck
rm -f include/asm
( cd include ; ln -sf asm-$(ARCH) asm)
@if [ ! -d include/linux/modules ]; then \
mkdir include/linux/modules; \
+ fi
+
+gccversioncheck:
+ @gccversion=`${HOSTCC} --version`;\
+ echo Using gcc version: $$gccversion;\
+ if [ "x$${gccversion}" != "x2.95.2" ]; then \
+ echo
+""; \
+ echo "*** This compiler version is not approved for compiling the
+kernel"; \
+ echo "*** version: " $$HOSTCC $$gccversion ; \
+ echo "*** Please consider this when reporting bugs" ;\
+ echo
+""; \
+ sleep 1; \
fi
oldconfig: symlinks
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
How about a simple patch to the top level makefile that checks the gcc
version then prints a distinct message ..'this compiler hasn't been approved
for compiling the kernel', sleeping for one second, then continuing on. This
solution doesn't stop compiling and makes a visible indicator without forcing
anything.
Sample attached.
-d
Alan Cox wrote:
As it stands, there is no way to determine programatically whether
gcc-2.96 is broken or now. The only way to do it is to check the RPM
version -- which, needless to say, is a bit difficult to do from the
C code about to be compiled. So I can't really blame Hans if he decides
to outlaw gcc-2.96[.0] for reiserfs compiles.
Oh I can see why Hans wants to cut down his bug reporting load. I can also
say from experience it wont work. If you put #error in then everyone will
mail him and complain it doesnt build, if you put #warning in nobody will
read it and if you dont put anything in you get the odd bug report anyway.
Basically you can't win and unfortunately a shrink wrap forcing the user
to read the README file for the kernel violates the GPL ..
Jaded, me ?
Alan
--
There is a natural aristocracy among men. The grounds of this are virtue and
talents. Thomas Jefferson
The good thing about standards is that there are so many to choose from. Andrew S.
Tanenbaum
--- Makefile.orig Sat Feb 3 00:48:26 2001
+++ MakefileSat Feb 3 00:45:00 2001
@@ -253,11 +253,23 @@
-o vmlinux
$(NM) vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw]
\)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort System.map
-symlinks:
+symlinks: gccversioncheck
rm -f include/asm
( cd include ; ln -sf asm-$(ARCH) asm)
@if [ ! -d include/linux/modules ]; then \
mkdir include/linux/modules; \
+ fi
+
+gccversioncheck:
+ @gccversion=`${HOSTCC} --version`;\
+ echo Using gcc version: $$gccversion;\
+ if [ "x$${gccversion}" != "x2.95.2" ]; then \
+ echo
+""; \
+ echo "*** This compiler version is not approved for compiling the
+kernel"; \
+ echo "*** version: " $$HOSTCC $$gccversion ; \
+ echo "*** Please consider this when reporting bugs" ;\
+ echo
+""; \
+ sleep 1; \
fi
oldconfig: symlinks
Re: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs
Chris Mason wrote: On Thursday, February 01, 2001 02:16:43 PM -0200 Rik van Riel [EMAIL PROTECTED] wrote: About the system hanging completely, I wonder if it goes away by pressing sysrq-S (sync all disks). If it does, maybe Reiserfs was blocking all the pages in the inactive list from being written because one of the active pages (not a replacement candidate) needed to be written out first? Or does the Reiserfs -writepage() function handle this? In answer to Rik's question, no, sysrq-S doesn't fix it. The sound of the disk grind changes momentarily then it resumes. In most cases, the reiserfs writepage func is the same as block_write_full_page. The only difference should come when a packed tail has been mmap'd. Since JOURNAL_MAX_BATCH was at 100, the log should have only pinned 400k. More blocks could be pinned, but kreiserfsd should be in the process of flushing those. I've been trying out a few things to send memory pressure down to reiserfs, but they have mostly been based on the code to make fs/buffer.c use writepage for flushing. I should have done something simple first, I'll start on that now. -chris http://stuph.org/VM/ is back up, no thanks to the network solutions. The files listed there have all the relevant backtraces. -d - 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: 2.4.1 - can't read root fs (devfs maybe?)
> image=/boot/bzImage > label=linux > append="root=/dev/ide/host0/bus0/target0/lun0/part1 vga=3845" root=/dev/ide/host will work the same as root=/dev/hda... in pre-devfs -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: 2.4.1 - can't read root fs (devfs maybe?)
image=/boot/bzImage label=linux append="root=/dev/ide/host0/bus0/target0/lun0/part1 vga=3845" root=/dev/ide/host will work the same as root=/dev/hda... in pre-devfs -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs
My apologies...my internic data isn't updated, http://208.179.0.18/VM/ -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: 2.4.1 - can't read root fs (devfs maybe?)
"Michael J. Dikkema" wrote: > I went from 2.4.0 to 2.4.1 and was surprised that either the root > filesystem wasn't mounted, or it couldn't be read. I'm using devfs.. I'm > thinking there might have been a change with regards to the devfs > tree.. is the legacy /dev/hda1 still /dev/discs/disc0/part1? This symlink doesn't exist/isn't usable for boot. Use the qualified pathname. I.e. /dev/discs/disc0/part1 points to /dev/ide/host0/bus0/target0/lun0/part1 on my machine. Use that pathname. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: 2.4.1 - can't read root fs (devfs maybe?)
John Jasen wrote: > On Thu, 1 Feb 2001, Peter Samuelson wrote: > > > [Michael J. Dikkema] > > > > I went from 2.4.0 to 2.4.1 and was surprised that either the root > > > > filesystem wasn't mounted, or it couldn't be read. I'm using devfs.. I'm > > > > thinking there might have been a change with regards to the devfs > > > > tree.. is the legacy /dev/hda1 still /dev/discs/disc0/part1? > > > > > > > > I can't even get a shell with init=/bin/bash.. > > > > [John Jasen] > > > Sounds like a lack of devfsd, which handles backwards compatibility > > > for /dev entries. > > > > devfsd does not start up until after the root filesystem is mounted, so > > that's not it. > > E upon careful reading of the devfs/devfsd documentation, you'll > find that it says to put /sbin/devfsd /dev in amongst the first lines in > rc.sysinit. > > In looking through rc.sysinit, / is not mounted rw until much later. Logic suggests that the root filesystem must be mounted before init runs. If init=/bin/bash, no boot scripts are run, devfs should have populated /dev before the init was spawned. devfs doesn't depend on the write state of the filesystem. I am running devfs on 2.4.1, automatically mounted. I am having no problems. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs
Chris Mason wrote: > Sorry, can't seem to resolve stuph.org. What is kreiserfsd doing during when the >system is waiting for more ram? With JOURNAL_MAX_BATCH set to 100, kreiserfsd will >end up responsible for sending log blocks/metadata to disk and freeing the pinned >buffers. > > -chris (http://208.179.0.18/VM/) [schedule_timeout+115/148] [process_timeout+0/72] [interruptible_sleep_on_timeout+66/92] [reiserfs_journal_commit_thread+173/224] [kernel_thread+40/56] -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs
My apologies...my internic data isn't updated, http://208.179.0.18/VM/ -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: VM brokenness, possibly related to reiserfs
Correct, the point of the matter is to find stress points. It will do the exact same thing when it reaches the end of swap. I suspect a relation to reiserfs fighting for buffers perhaps. This fight occurs a few megs before the OOM routine trips. -d Ed Tomlinson wrote: > Hi, > > Gather this is with no swap space allocated... And the question is why does > the oom handler not get triggered? > > Ed Tomlinson > > David Ford wrote: > > > (Chris, changing JOURNAL_MAX_BATCH from 900 to 100 didn't affect > > anything). > > > > Ok, having approached this slightly more intelligently here are [better] > > results. > > > > The dumps are large so they are located at http://stuph.org/VM/. Here's > > the story. I boot and startx, I load xmms and netscape to eat away > > memory. When free buffers/cache falls below 7M the system stalls and > > the only recovery is sysrq-E or reboot. At the moment of stall the disk > > will grind continuously for about 25 to 30 minutes then go silent. At > > this point in time the only recovery is reboot, sysrq-E won't work. > > > > If I move the mouse or type a key within 30 seconds of this incident, > > that user input will take about 5 minutes to register. After that > > initial minute, nothing more will happen. > > > > Kernel 2.4.1, with reiserfs, devfs, no patches applied. > > > > "klog-X" are basically the same thing but I'm running top, syslogd, and > > klogd with -20 priority. I didn't note anything out of the ordinary in > > top. These are snapshots where I've managed to murder processes and > > restart the problem without rebooting. > > > > In the second instance, I had my finger on the kill button and managed > > to kill netscape and recover partially. However the system was heavily > > loaded even after the kill. > > > > I have xmms in STOPped state so it's just waiting. > > > > kswapd is taking 12.2% of the CPU according to ps, and kapm-idled is > > taking 26.9%. bdflush is taking 2.7%, X 3.5%, all others are nominal. > > The system load was hovering at 1.00 for a few minutes then dropped to > > zero. However scrolling text in an rxvt is slow enough to watch blocks > > move. Running "ps aux" takes nearly one third of a second for total > > time. Total number of processes is ~40. > > > > Jan 31 22:31:51 nifty kernel: kapm-idled S CBF77F94 4124 3 > > 1(L-TLB) 4 2 > > Jan 31 22:31:51 nifty kernel: Call Trace: [schedule_timeout+115/148] > > [process_timeout+0/72] [apm_mainloop+221/256] [apm+668/692] > > [kernel_thread+31/56] [kernel_thread+40/56] > > > > Jan 31 22:31:51 nifty kernel: kswapdS CBF75FAC 5704 4 > > 1(L-TLB) 5 3 > > Jan 31 22:31:51 nifty kernel: Call Trace: [schedule_timeout+115/148] > > [process_timeout+0/72] [interruptible_sleep_on_timeout+66/92] > > [kswapd+213/244] [kernel_thread+40/56] > > > > Jan 31 22:31:52 nifty kernel: bdflush S CBF7 5912 6 > > 1(L-TLB) 7 5 > > Jan 31 22:31:52 nifty kernel: Call Trace: [bdflush+206/216] > > [kernel_thread+40/56] > > > > > > In the fourth snapshot, I have put xmms in STOP state again inside the > > memory shortage, memory is at 4800 free buffers/cache and 1592 free mem. > > > > As I entered this shortage period I started a 'ps -eo ... > file' to try > > and record data there. This is the only disk activity happening. Load > > is ~4.00. I have now killed the ps. > > > > Load has dropped significantly and I have tolerable but quite laggy user > > input responsiveness now. > > > > Memory is currently 4900/1588 like above. Load is about 2.00 and will > > continue dropping if I don't do anything. Any processes I exec which > > need to be loaded from disk take several seconds. I.e. 'uptime' takes > > about 4 seconds to execute. > > > > Snapshot #5 will be the last one and I will reboot. Once memory is > > freed from xmms (back to 150megs free), everything is peachy. > > > > > > -d > > > > -- > > There is a natural aristocracy among men. The grounds of this are virtue > and talents. > > Thomas Jefferson The good thing about standards is that there are so many > to choose > > from. Andrew S. Tanenbaum > > > > > > > > - > > 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/ > > -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: VM brokenness, possibly related to reiserfs
Correct, the point of the matter is to find stress points. It will do the exact same thing when it reaches the end of swap. I suspect a relation to reiserfs fighting for buffers perhaps. This fight occurs a few megs before the OOM routine trips. -d Ed Tomlinson wrote: Hi, Gather this is with no swap space allocated... And the question is why does the oom handler not get triggered? Ed Tomlinson David Ford wrote: (Chris, changing JOURNAL_MAX_BATCH from 900 to 100 didn't affect anything). Ok, having approached this slightly more intelligently here are [better] results. The dumps are large so they are located at http://stuph.org/VM/. Here's the story. I boot and startx, I load xmms and netscape to eat away memory. When free buffers/cache falls below 7M the system stalls and the only recovery is sysrq-E or reboot. At the moment of stall the disk will grind continuously for about 25 to 30 minutes then go silent. At this point in time the only recovery is reboot, sysrq-E won't work. If I move the mouse or type a key within 30 seconds of this incident, that user input will take about 5 minutes to register. After that initial minute, nothing more will happen. Kernel 2.4.1, with reiserfs, devfs, no patches applied. "klog-X" are basically the same thing but I'm running top, syslogd, and klogd with -20 priority. I didn't note anything out of the ordinary in top. These are snapshots where I've managed to murder processes and restart the problem without rebooting. In the second instance, I had my finger on the kill button and managed to kill netscape and recover partially. However the system was heavily loaded even after the kill. I have xmms in STOPped state so it's just waiting. kswapd is taking 12.2% of the CPU according to ps, and kapm-idled is taking 26.9%. bdflush is taking 2.7%, X 3.5%, all others are nominal. The system load was hovering at 1.00 for a few minutes then dropped to zero. However scrolling text in an rxvt is slow enough to watch blocks move. Running "ps aux" takes nearly one third of a second for total time. Total number of processes is ~40. Jan 31 22:31:51 nifty kernel: kapm-idled S CBF77F94 4124 3 1(L-TLB) 4 2 Jan 31 22:31:51 nifty kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [apm_mainloop+221/256] [apm+668/692] [kernel_thread+31/56] [kernel_thread+40/56] Jan 31 22:31:51 nifty kernel: kswapdS CBF75FAC 5704 4 1(L-TLB) 5 3 Jan 31 22:31:51 nifty kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [interruptible_sleep_on_timeout+66/92] [kswapd+213/244] [kernel_thread+40/56] Jan 31 22:31:52 nifty kernel: bdflush S CBF7 5912 6 1(L-TLB) 7 5 Jan 31 22:31:52 nifty kernel: Call Trace: [bdflush+206/216] [kernel_thread+40/56] In the fourth snapshot, I have put xmms in STOP state again inside the memory shortage, memory is at 4800 free buffers/cache and 1592 free mem. As I entered this shortage period I started a 'ps -eo ... file' to try and record data there. This is the only disk activity happening. Load is ~4.00. I have now killed the ps. Load has dropped significantly and I have tolerable but quite laggy user input responsiveness now. Memory is currently 4900/1588 like above. Load is about 2.00 and will continue dropping if I don't do anything. Any processes I exec which need to be loaded from disk take several seconds. I.e. 'uptime' takes about 4 seconds to execute. Snapshot #5 will be the last one and I will reboot. Once memory is freed from xmms (back to 150megs free), everything is peachy. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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/ -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs
My apologies...my internic data isn't updated, http://208.179.0.18/VM/ -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs
Chris Mason wrote: Sorry, can't seem to resolve stuph.org. What is kreiserfsd doing during when the system is waiting for more ram? With JOURNAL_MAX_BATCH set to 100, kreiserfsd will end up responsible for sending log blocks/metadata to disk and freeing the pinned buffers. -chris (http://208.179.0.18/VM/) [schedule_timeout+115/148] [process_timeout+0/72] [interruptible_sleep_on_timeout+66/92] [reiserfs_journal_commit_thread+173/224] [kernel_thread+40/56] -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: 2.4.1 - can't read root fs (devfs maybe?)
John Jasen wrote: On Thu, 1 Feb 2001, Peter Samuelson wrote: [Michael J. Dikkema] I went from 2.4.0 to 2.4.1 and was surprised that either the root filesystem wasn't mounted, or it couldn't be read. I'm using devfs.. I'm thinking there might have been a change with regards to the devfs tree.. is the legacy /dev/hda1 still /dev/discs/disc0/part1? I can't even get a shell with init=/bin/bash.. [John Jasen] Sounds like a lack of devfsd, which handles backwards compatibility for /dev entries. devfsd does not start up until after the root filesystem is mounted, so that's not it. E upon careful reading of the devfs/devfsd documentation, you'll find that it says to put /sbin/devfsd /dev in amongst the first lines in rc.sysinit. In looking through rc.sysinit, / is not mounted rw until much later. Logic suggests that the root filesystem must be mounted before init runs. If init=/bin/bash, no boot scripts are run, devfs should have populated /dev before the init was spawned. devfs doesn't depend on the write state of the filesystem. I am running devfs on 2.4.1, automatically mounted. I am having no problems. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: 2.4.1 - can't read root fs (devfs maybe?)
"Michael J. Dikkema" wrote: I went from 2.4.0 to 2.4.1 and was surprised that either the root filesystem wasn't mounted, or it couldn't be read. I'm using devfs.. I'm thinking there might have been a change with regards to the devfs tree.. is the legacy /dev/hda1 still /dev/discs/disc0/part1? This symlink doesn't exist/isn't usable for boot. Use the qualified pathname. I.e. /dev/discs/disc0/part1 points to /dev/ide/host0/bus0/target0/lun0/part1 on my machine. Use that pathname. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs
My apologies...my internic data isn't updated, http://208.179.0.18/VM/ -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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/
VM brokenness, possibly related to reiserfs
(Chris, changing JOURNAL_MAX_BATCH from 900 to 100 didn't affect anything). Ok, having approached this slightly more intelligently here are [better] results. The dumps are large so they are located at http://stuph.org/VM/. Here's the story. I boot and startx, I load xmms and netscape to eat away memory. When free buffers/cache falls below 7M the system stalls and the only recovery is sysrq-E or reboot. At the moment of stall the disk will grind continuously for about 25 to 30 minutes then go silent. At this point in time the only recovery is reboot, sysrq-E won't work. If I move the mouse or type a key within 30 seconds of this incident, that user input will take about 5 minutes to register. After that initial minute, nothing more will happen. Kernel 2.4.1, with reiserfs, devfs, no patches applied. "klog-X" are basically the same thing but I'm running top, syslogd, and klogd with -20 priority. I didn't note anything out of the ordinary in top. These are snapshots where I've managed to murder processes and restart the problem without rebooting. In the second instance, I had my finger on the kill button and managed to kill netscape and recover partially. However the system was heavily loaded even after the kill. I have xmms in STOPped state so it's just waiting. kswapd is taking 12.2% of the CPU according to ps, and kapm-idled is taking 26.9%. bdflush is taking 2.7%, X 3.5%, all others are nominal. The system load was hovering at 1.00 for a few minutes then dropped to zero. However scrolling text in an rxvt is slow enough to watch blocks move. Running "ps aux" takes nearly one third of a second for total time. Total number of processes is ~40. Jan 31 22:31:51 nifty kernel: kapm-idled S CBF77F94 4124 3 1(L-TLB) 4 2 Jan 31 22:31:51 nifty kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [apm_mainloop+221/256] [apm+668/692] [kernel_thread+31/56] [kernel_thread+40/56] Jan 31 22:31:51 nifty kernel: kswapdS CBF75FAC 5704 4 1(L-TLB) 5 3 Jan 31 22:31:51 nifty kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [interruptible_sleep_on_timeout+66/92] [kswapd+213/244] [kernel_thread+40/56] Jan 31 22:31:52 nifty kernel: bdflush S CBF7 5912 6 1(L-TLB) 7 5 Jan 31 22:31:52 nifty kernel: Call Trace: [bdflush+206/216] [kernel_thread+40/56] In the fourth snapshot, I have put xmms in STOP state again inside the memory shortage, memory is at 4800 free buffers/cache and 1592 free mem. As I entered this shortage period I started a 'ps -eo ... > file' to try and record data there. This is the only disk activity happening. Load is ~4.00. I have now killed the ps. Load has dropped significantly and I have tolerable but quite laggy user input responsiveness now. Memory is currently 4900/1588 like above. Load is about 2.00 and will continue dropping if I don't do anything. Any processes I exec which need to be loaded from disk take several seconds. I.e. 'uptime' takes about 4 seconds to execute. Snapshot #5 will be the last one and I will reboot. Once memory is freed from xmms (back to 150megs free), everything is peachy. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: [PATCH/REQ] Increase kmsg buffer from 16K to 32K, kernel/printk.c
"Maciej W. Rozycki" wrote: > On Wed, 31 Jan 2001, Alan Cox wrote: > > > > Does Linus or anyone object to raising the ksmg buffer from 16K to 32K? > > > 4/5 systems I have now overflow the buffer during boot before init is > > > even launched. > > > > Thats just an indication that 2.4.x is currently printking too much crap on > > boot > > We could probably get rid of much of the crap for i386 by #undef > APIC_DEBUG in include/asm-i386/apic.h. Too bad broken SMP systems get > reported every now and then and the crap proves useful in getting what > actually is wrong. The largest bodies of text come from scsi, irda, usb, and udf. The LP/parport could stand being trimmed too. The fatfs barfs out bogus cluster size messages when I don't have any FAT type filesystems. Question is, If I submit patches to tidy up the boot messages, when will(can) they be applied? 2.4 or 2.5? -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: [PATCH] doc update/fixes for sysrq.txt
Alan Cox wrote: > > > AFAIK, this hasn't ever been true. I have never had to specifically > > > enable it at run time. > > > > I was suspicious of that in the old doc but thought I'd leave it in... > > Should have asked for feedback on it, but you caught it anyway, thanks! > > > > Here's a patch against the first that simply removes the lines. > > Its true in 2.2 At what point in 2.2 did it become true? I rarely used 2.2, I went from 2.1 to 2.3 and I don't recall having to ever enable it. Once it was compiled in it was on. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: [PATCH] doc update/fixes for sysrq.txt
Alan Cox wrote: AFAIK, this hasn't ever been true. I have never had to specifically enable it at run time. I was suspicious of that in the old doc but thought I'd leave it in... Should have asked for feedback on it, but you caught it anyway, thanks! Here's a patch against the first that simply removes the lines. Its true in 2.2 At what point in 2.2 did it become true? I rarely used 2.2, I went from 2.1 to 2.3 and I don't recall having to ever enable it. Once it was compiled in it was on. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: [PATCH/REQ] Increase kmsg buffer from 16K to 32K, kernel/printk.c
"Maciej W. Rozycki" wrote: On Wed, 31 Jan 2001, Alan Cox wrote: Does Linus or anyone object to raising the ksmg buffer from 16K to 32K? 4/5 systems I have now overflow the buffer during boot before init is even launched. Thats just an indication that 2.4.x is currently printking too much crap on boot We could probably get rid of much of the crap for i386 by #undef APIC_DEBUG in include/asm-i386/apic.h. Too bad broken SMP systems get reported every now and then and the crap proves useful in getting what actually is wrong. The largest bodies of text come from scsi, irda, usb, and udf. The LP/parport could stand being trimmed too. The fatfs barfs out bogus cluster size messages when I don't have any FAT type filesystems. Question is, If I submit patches to tidy up the boot messages, when will(can) they be applied? 2.4 or 2.5? -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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/
VM brokenness, possibly related to reiserfs
(Chris, changing JOURNAL_MAX_BATCH from 900 to 100 didn't affect anything). Ok, having approached this slightly more intelligently here are [better] results. The dumps are large so they are located at http://stuph.org/VM/. Here's the story. I boot and startx, I load xmms and netscape to eat away memory. When free buffers/cache falls below 7M the system stalls and the only recovery is sysrq-E or reboot. At the moment of stall the disk will grind continuously for about 25 to 30 minutes then go silent. At this point in time the only recovery is reboot, sysrq-E won't work. If I move the mouse or type a key within 30 seconds of this incident, that user input will take about 5 minutes to register. After that initial minute, nothing more will happen. Kernel 2.4.1, with reiserfs, devfs, no patches applied. "klog-X" are basically the same thing but I'm running top, syslogd, and klogd with -20 priority. I didn't note anything out of the ordinary in top. These are snapshots where I've managed to murder processes and restart the problem without rebooting. In the second instance, I had my finger on the kill button and managed to kill netscape and recover partially. However the system was heavily loaded even after the kill. I have xmms in STOPped state so it's just waiting. kswapd is taking 12.2% of the CPU according to ps, and kapm-idled is taking 26.9%. bdflush is taking 2.7%, X 3.5%, all others are nominal. The system load was hovering at 1.00 for a few minutes then dropped to zero. However scrolling text in an rxvt is slow enough to watch blocks move. Running "ps aux" takes nearly one third of a second for total time. Total number of processes is ~40. Jan 31 22:31:51 nifty kernel: kapm-idled S CBF77F94 4124 3 1(L-TLB) 4 2 Jan 31 22:31:51 nifty kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [apm_mainloop+221/256] [apm+668/692] [kernel_thread+31/56] [kernel_thread+40/56] Jan 31 22:31:51 nifty kernel: kswapdS CBF75FAC 5704 4 1(L-TLB) 5 3 Jan 31 22:31:51 nifty kernel: Call Trace: [schedule_timeout+115/148] [process_timeout+0/72] [interruptible_sleep_on_timeout+66/92] [kswapd+213/244] [kernel_thread+40/56] Jan 31 22:31:52 nifty kernel: bdflush S CBF7 5912 6 1(L-TLB) 7 5 Jan 31 22:31:52 nifty kernel: Call Trace: [bdflush+206/216] [kernel_thread+40/56] In the fourth snapshot, I have put xmms in STOP state again inside the memory shortage, memory is at 4800 free buffers/cache and 1592 free mem. As I entered this shortage period I started a 'ps -eo ... file' to try and record data there. This is the only disk activity happening. Load is ~4.00. I have now killed the ps. Load has dropped significantly and I have tolerable but quite laggy user input responsiveness now. Memory is currently 4900/1588 like above. Load is about 2.00 and will continue dropping if I don't do anything. Any processes I exec which need to be loaded from disk take several seconds. I.e. 'uptime' takes about 4 seconds to execute. Snapshot #5 will be the last one and I will reboot. Once memory is freed from xmms (back to 150megs free), everything is peachy. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: 2.4.x and SMP fails to compile (`current' undefined)
Mhm. Is it worth the effort to make a dependancy on the CPU type for SMP? -d Stephen Frost wrote: > * David Ford ([EMAIL PROTECTED]) wrote: > > A person just brought up a problem in #kernelnewbies, building an SMP > > kernel doesn't work very well, current is undefined. I don't have more > > time to debug it but I'll strip the config and put it up at > > http://stuph.org/smp-config > > They're trying to compile SMP for Athlon/K7 (CONFIG_MK7=y). -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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/
2.4.x and SMP fails to compile (`current' undefined)
A person just brought up a problem in #kernelnewbies, building an SMP kernel doesn't work very well, current is undefined. I don't have more time to debug it but I'll strip the config and put it up at http://stuph.org/smp-config -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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/
2.4.x and SMP fails to compile (`current' undefined)
A person just brought up a problem in #kernelnewbies, building an SMP kernel doesn't work very well, current is undefined. I don't have more time to debug it but I'll strip the config and put it up at http://stuph.org/smp-config -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: 2.4.x and SMP fails to compile (`current' undefined)
Mhm. Is it worth the effort to make a dependancy on the CPU type for SMP? /idle questions -d Stephen Frost wrote: * David Ford ([EMAIL PROTECTED]) wrote: A person just brought up a problem in #kernelnewbies, building an SMP kernel doesn't work very well, current is undefined. I don't have more time to debug it but I'll strip the config and put it up at http://stuph.org/smp-config They're trying to compile SMP for Athlon/K7 (CONFIG_MK7=y). -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: [PATCH] doc update/fixes for sysrq.txt
Jonathan Earle wrote: > > On Sun, 28 Jan 2001 11:35:50 +, David Ford wrote: > > > AFAIK, this hasn't ever been true. I have never had to specifically > > > enable it at run time. > > > > I was suspicious of that in the old doc but thought I'd leave it in... > > Should have asked for feedback on it, but you caught it > > anyway, thanks! > > > > Here's a patch against the first that simply removes the lines. > > I'd suggest leaving those lines in; I've never had it enabled by default. > I've run Debian and Redhat systems, and both had to have the option > specifically turned ON via startup script - simply compiling it into a > kernel did not enable it. > > Jon I suggest compiling it in and booting with init=/bin/bash, mounting /proc and checking the value. It is enabled by default. A few distributions have a boot script that enables or disables it based on the sysconfig. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: [PATCH] doc update/fixes for sysrq.txt
Jonathan Earle wrote: On Sun, 28 Jan 2001 11:35:50 +, David Ford wrote: AFAIK, this hasn't ever been true. I have never had to specifically enable it at run time. I was suspicious of that in the old doc but thought I'd leave it in... Should have asked for feedback on it, but you caught it anyway, thanks! Here's a patch against the first that simply removes the lines. I'd suggest leaving those lines in; I've never had it enabled by default. I've run Debian and Redhat systems, and both had to have the option specifically turned ON via startup script - simply compiling it into a kernel did not enable it. Jon I suggest compiling it in and booting with init=/bin/bash, mounting /proc and checking the value. It is enabled by default. A few distributions have a boot script that enables or disables it based on the sysconfig. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: D state after applying ps hang patch
The one LInus posted plus his addendum for the ll_rw_blk. http://blue-labs.org/patches/ps-hang.patch -d Jens Axboe wrote: > On Mon, Jan 29 2001, David Ford wrote: > > kernel 2.4.0-ac12 > > > > # ps -eo user,pid,args,wchan|egrep "imap|update|procmail" > > root 7 [kupdate]get_request_wait > > david 627 imapdget_request_wait > > david 752 procmail -f linu down > > david 761 procmail -f linu down > > david 799 procmail -f linu down > > david 854 procmail -f linu down > > david 886 procmail -f linu down > > david 847 imapdget_request_wait > > david 1079 procmail -f linu down > > david 3280 imapdinterruptible_sleep_on_locked > > david 3321 imapdinterruptible_sleep_on_locked > > > > and the cpu load is artificially inflated to 9.17 > > Which patch specifically? -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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/
D state after applying ps hang patch
kernel 2.4.0-ac12 # ps -eo user,pid,args,wchan|egrep "imap|update|procmail" root 7 [kupdate]get_request_wait david 627 imapdget_request_wait david 752 procmail -f linu down david 761 procmail -f linu down david 799 procmail -f linu down david 854 procmail -f linu down david 886 procmail -f linu down david 847 imapdget_request_wait david 1079 procmail -f linu down david 3280 imapdinterruptible_sleep_on_locked david 3321 imapdinterruptible_sleep_on_locked and the cpu load is artificially inflated to 9.17 -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: [PATCH] doc update/fixes for sysrq.txt
"Jeremy M. Dolan" wrote: > +Note that previous versions disabled sysrq by default, and you were required > +to specifically enable it at run-time. That is not the case any longer. AFAIK, this hasn't ever been true. I have never had to specifically enable it at run time. There are certain distributions which disabled it by default but this is distribution specific, not by way of the kernel. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: [PATCH] devfsd, compiling on glibc22x
Ulrich Drepper wrote: > Pierre Rousselet <[EMAIL PROTECTED]> writes: > > > for me : > > make CFLAGS='-O2 -I. -D_GNU_SOURCE' > > compiles without any patch. is it correct ? > > Yes. RTLD_NEXT is not in any standard, it's an extension available > via -D_GNU_SOURCE. Ok, how about we all tag Richard until he adds that to the makefile? :) -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: [PATCH] devfsd, compiling on glibc22x
Ulrich Drepper wrote: Pierre Rousselet [EMAIL PROTECTED] writes: for me : make CFLAGS='-O2 -I. -D_GNU_SOURCE' compiles without any patch. is it correct ? Yes. RTLD_NEXT is not in any standard, it's an extension available via -D_GNU_SOURCE. Ok, how about we all tag Richard until he adds that to the makefile? :) -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: [PATCH] doc update/fixes for sysrq.txt
"Jeremy M. Dolan" wrote: +Note that previous versions disabled sysrq by default, and you were required +to specifically enable it at run-time. That is not the case any longer. AFAIK, this hasn't ever been true. I have never had to specifically enable it at run time. There are certain distributions which disabled it by default but this is distribution specific, not by way of the kernel. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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/
D state after applying ps hang patch
kernel 2.4.0-ac12 # ps -eo user,pid,args,wchan|egrep "imap|update|procmail" root 7 [kupdate]get_request_wait david 627 imapdget_request_wait david 752 procmail -f linu down david 761 procmail -f linu down david 799 procmail -f linu down david 854 procmail -f linu down david 886 procmail -f linu down david 847 imapdget_request_wait david 1079 procmail -f linu down david 3280 imapdinterruptible_sleep_on_locked david 3321 imapdinterruptible_sleep_on_locked and the cpu load is artificially inflated to 9.17 -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: D state after applying ps hang patch
The one LInus posted plus his addendum for the ll_rw_blk. http://blue-labs.org/patches/ps-hang.patch -d Jens Axboe wrote: On Mon, Jan 29 2001, David Ford wrote: kernel 2.4.0-ac12 # ps -eo user,pid,args,wchan|egrep "imap|update|procmail" root 7 [kupdate]get_request_wait david 627 imapdget_request_wait david 752 procmail -f linu down david 761 procmail -f linu down david 799 procmail -f linu down david 854 procmail -f linu down david 886 procmail -f linu down david 847 imapdget_request_wait david 1079 procmail -f linu down david 3280 imapdinterruptible_sleep_on_locked david 3321 imapdinterruptible_sleep_on_locked and the cpu load is artificially inflated to 9.17 Which patch specifically? -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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/
[PATCH] devfsd, compiling on glibc22x
This patch is simple, defines RTLD_NEXT if not previously defined.
--- devfsd.c.orig Sat Jan 27 18:14:19 2001
+++ devfsd.cSat Jan 27 18:15:46 2001
@@ -165,6 +165,7 @@
Last updated by Richard Gooch 3-JUL-2000: Added "-C
/etc/modules.devfs"
when calling modprobe(8). Fail if a configuration line has EXECUTE
modprobe.
+Updated by David Ford 27-JAN-2001: Added RTLD_NEXT define
*/
#include
@@ -221,6 +222,10 @@
#define AC_MKNEWCOMPAT 8
#define AC_RMOLDCOMPAT 9
#define AC_RMNEWCOMPAT 10
+
+#ifndef RTLD_NEXT
+# define RTLD_NEXT ((void *) -1l)
+#endif
struct permissions_type
{
--
There is a natural aristocracy among men. The grounds of this are virtue and
talents. Thomas Jefferson
The good thing about standards is that there are so many to choose from. Andrew S.
Tanenbaum
-
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: ps hang in 241-pre10
It is important to note that when I hit the magic key and rebooted (SUB), a split second before it rebooted, a stalled 'lspci' snapped back to life and printed out my expected data. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: ps hang in 241-pre10
On 2.4.0-ac12, I played music for about 30 minutes without any problems. I started up an mpeg in xmms and it locked in short order. I'm sure now that it has something to do with the graphics. What DGA or other config options do you have enabled for your game? What video and sound card? I have an ATI Rage LT Pro AGP-133 according to lspci. -d J Sloan wrote: > Sorry, there was no xmms involved here - > > The behavior occurred while playing unreal tournament. > > But at least the sound card was in use, FWIW - > > jjs > > David Ford wrote: > > > We've narrowed it down to "we're all running xmms" when it happend. > > > > -d > > > > J Sloan wrote: > > > > > Just for the record, the system where I saw the problem > > > has only ext2 - > > > > -- > > There is a natural aristocracy among men. The grounds of this are virtue and >talents. Thomas Jefferson > > The good thing about standards is that there are so many to choose from. Andrew >S. Tanenbaum > > > > - > > 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/ -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: ps hang in 241-pre10
Unfortunately klogd reads /procerg. So the following is a painstakingly slow hand translation, I'll only print the D state entries unless someone asks otherwise. Prior to this: XMMS is running playing star wars mpeg. (regular user) (frozen) TOP is running (regular user) (frozen) while [ 1 ]; do ls -laR /proc ; done (regular user) (frozen) skill -9 xmms (root) (frozen) X 4.0.2 running, scp of 600meg file over pegasus usb ethernet (10Mbit). syslog caught: Jan 27 16:42:26 nifty kernel: SysRq: Show State Jan 27 16:42:26 nifty kernel: Jan 27 16:42:26 nifty kernel: freesibling Jan 27 16:42:26 nifty kernel: task PCstack pid father child younger older Jan 27 16:42:26 nifty kernel: init S CBFEBF2C 3184 1 0 187 (NOTLB) dmesg shows (only D state for brevity): top D CA98B3DC 4440 219158(NOTLB) Call Trace: [] [] [] [] [] [] [] c01078c8 T __down c0107964 T __down_interruptible c0107a28 T __down_trylock c0107a60 T __down_failed c0107a6c T __down_failed_interruptible c02f6a00 T stext_lock c02f827e A _etext c014b578 t proc_info_read c014b688 t mem_read c0131150 T sys_read c013121c T sys_write c0108d2c T system_call c0108d64 T ret_from_sys_call c010 t startup_32 c0100139 t is486 xmms D CACC5EA8 4116 713155 715 (NOTLB)1493 674 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] c01248e4 T ___wait_on_page c0124984 t __lock_page c01240dc t truncate_list_pages c0124268 T truncate_inode_pages c01242d4 t writeout_one_page c0144094 T remove_inode_hash c01440a8 T iput c01441fc T force_delete c01422a0 T dput c01423e4 T d_invalidate c0131c58 T fput c0131d28 T fget c012365c t unmap_fixup c0123788 t free_pgtables c012380c T do_munmap c0123a5c T sys_munmap ...ask if you want more xmms S C2979F30 0 715713 725 (NOTLB) Call Trace: [] [] [] [] [] [] xmms S C2B75F2C 1156 716715(NOTLB) 718 Call Trace: [] [] [] [] [] xmms S 7FFF 0 718715(NOTLB) 719 716 Call Trace: [] [] [] [] xmms S C2975F88 832 719715(NOTLB) 725 718 Call Trace: [] [] [] [] [] xmms S CA8D7F88 2672 725715(NOTLB) 719 Call Trace: [] [] [] [] c0114240 t process_timeout c0114288 T schedule_timeout c011431c T schedule_tail c0113d70 t remap_area_pages c0114020 T __ioremap c0108d2c T system_call c0108d64 T ret_from_sys_call lsD CA98B3DC 0 1896222(NOTLB) Call Trace: [] [] [] [] [] [] skill D CA98B3DC 0 1897187(NOTLB) Call Trace: [] [] [] [] [] [] c0107964 T __down_interruptible c0107a28 T __down_trylock c0107a60 T __down_failed c0107a6c T __down_failed_interruptible c02f6a00 T stext_lock c02f827e A _etext ... SysRq: Show Memory Mem-info: Free pages:2240kB ( 0kB HighMem) ( Active: 4153, inactive_dirty: 198, inactive_clean: 1077, free: 560 (383 766 1149) ) 31*4kB 1*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB = 660kB) 125*4kB 5*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB = 1580kB) = 0kB) Swap cache: add 3165, delete 547, find 25/124 Free swap:53104kB 49136 pages of RAM 0 pages of HIGHMEM 1798 reserved pages 2619 pages shared 2618 pages swap cached 0 pages in page table cache Buffer memory: 1276kB -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: ps hang in 241-pre10
Linus Torvalds wrote: > In article <[EMAIL PROTECTED]>, David Ford <[EMAIL PROTECTED]> > wrote: > > > >We've narrowed it down to "we're all running xmms" when it happend. > > Does anybody have a clue about what is different with xmms? Not sure. > Does it use KNI if it can, for example? We used to have a problem with > KNI+Athlons, for example. > > It might also be that it's threading-related, and that XMMS is one of > the few things that uses threads. Things like that. I'm not an XMMS > user, can somebody who knows XMMS comment on things that it does that > are unusual? If I was clued enough to know KNI, I could say for a certainty. I am assuming it's a form of MMX or related. My notebook is a mobile pII 366. I'm stress testing it now with ac12. I originally had pre9 on it. There is one difference other than that, I have Marcelo's bg aging patch on here which seems to have improved responsiveness significantly but I'll save that for another story. I've triggered it, report follows in next email. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: ps hang in 241-pre10
At the time I had temporary access to my notebook and had a mismatched System.map file :S -d Linus Torvalds wrote: > In article <[EMAIL PROTECTED]>, David Ford <[EMAIL PROTECTED]> wrote: > >I can quickly and easily duplicate it on my notebook by playing music or > >mpegs in xmms. It may take a few minutes but it's guaranteed. > > > >xmms stalls flat on it's face and anything accessing /proc stalls. If I get > >the time to do it, I'll take a gander at it with kdb. > > Please, if you see something like this, just do a simple > followed by while in text-mode. The > magic keystrokes will give a stack trace of the currently running > process and all processes respectively. -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: ps hang in 241-pre10
We've narrowed it down to "we're all running xmms" when it happend. -d J Sloan wrote: > Just for the record, the system where I saw the problem > has only ext2 - -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: VM breakdown, 2.4.0 family
I have Marcelo's patch. It isn't applicable because I am purposely not enabling any swap. The problem is the system gets down to about 7 megs of buffers free and within three seconds has become functionally dead. Zero response on any user input/output device save the magic key. The system will then grind the harddrive solid for about 25-30 minutes then everything will go silent. The brokenness is that the OOM code never activates. -d Ed Tomlinson wrote: > David Ford Wrote: > > >Since the testN series and up through ac12, I experience total loss of > >control when memory is nearly exhausted. > > > >I start with 256M and eat it up with programs until there is only about > >7 megs left, no swap. From that point all user processes stall and the > >disk begins to grind nonstop. It will continue to grind for about 25-30 > >minutes until it goes completely silent. No processes get killed, no VM > >messages are emitted. > > > >The only recourse is the magic key. If I reboot before the disk goes > >silent I can cleanly kill X with sysrq-E and restart. > > > >If I wait until it goes silent, all is lost. I have to sysrq-SUB. > > You might want to try: > > http://bazar.conectiva.com.br/~marcelo/patches/v2.4/2.4.1pre10/bg_page_aging.patch > > or > > ftp://ftp.cam.org/users/tomlins/pte_aging_limit_swaps.diff > > The first patch from Marcelo fixes a problem with aging the wrong pages. The > second patch is sort of a 'best of Marcelo' patch. It contains the aging fix > and adds conditional bg pte aging (if with activate fast than we age > down...). It also has code to trottle swapouts when under preasure - it only > swaps out as much as we need now. > > I have fives days of uptime with it here (on test9 and test10). > > Feedback Welcome, > > Ed Tomlinson <[EMAIL PROTECTED]> -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: [PATCH/REQ] Increase kmsg buffer from 16K to 32K, kernel/printk.c
Ion Badulescu wrote: > On Sat, 27 Jan 2001 08:01:14 +0000, David Ford <[EMAIL PROTECTED]> wrote: > > Does Linus or anyone object to raising the ksmg buffer from 16K to 32K? > > 4/5 systems I have now overflow the buffer during boot before init is > > even launched. > > Hmm, are you sure? man dmesg: > [...] >-sbufsize > use a buffer of bufsize to query the kernel ring > buffer. This is 8196 by default (this matches the > default kernel syslog buffer size in 2.0.33 and > 2.1.103). If you have set the kernel buffer to > larger than the default then this option can be > used to view the entire buffer. > > So try dmesg -s 16384. That's good enough for me on a 4-way SMP > box with lots of SCSI on-board (and trust me, SMP generates a *huge* > amount of kernel logging). Well, as I said, the (current) 16K buffer is overflowed before init is started. Being that I'd like to review the first page or two of boot messages, I have to increase this limit all the time. The above man page needs updated, the buffer size in 2.4.0 is 16K and it doesn't matter how large you set the dmesg -s parameter, the kernel's buffer size is the most you can retrieve from it. -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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/
Looking for comparison data on network stack prowess
I'm looking for some authoritative comparisons and discussions of the current network stacks in *BSD and Linux. I.e. NET4 in Linux and whatever is most current in *BSD. _PLEASE_ no flaming, no causing flamewar, nadda. I am writing an article for Linux.com and I am attempting to debunk longstanding fallacies on both sides of the camp. I am aiming for a truely neutral article which means I want to hear about the bad as well as the good for both camps. I am no master, and haven't played with *BSD in a few. I would appreciate any of you who can cooly speak their mind and provide insightful information. I am looking for: articles benchmarks commentary references etc.. Thank you, -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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/
