Re: i915 driver gpu hung kernel 3.11
Hi Bruno, I have tested the latest kernel and X, mesa etc, but am still using wine-1.3.24. I am working on upgrading that. If I still have the error I will file a bug report at bugs.freedesktop.org. I already have a login because of the same problem happening with Myst 5, but it was never resolved. Do you know if there is a comprehensive set of test I can run to make sure my hardware is OK. When I run dxdiag under wine it passes all tests, but then when trying to play Myst online or Myst 5 I get the gpu hung situation. Anyway thanks for taking the time to respond. Regards, Steve On 11/20/2013 12:26 PM, Bruno Prémont wrote: Hi Stephen, On Tue, 19 November 2013 Stephen Clark wrote: Thanks for the response. I have subscribed to the intel-gfx list. I didn't post the error_state file since it huge. It's best to submit a but report on bugs.freedesktop.org and attach the error_state there (compressed if needed) - repeating the information you provided in this thread. Without the error_state chances of getting some developer look at it and have a chance of understanding the cause are small. If they can reproduce it's a bonus. Once you have done so, replying with a reference to the bug might help people who find your report in mailing list archives. Bruno I was trying to play Myst Online using wine-1.3.24. I get started and start moving my avatar fairly quickly I get the error. I have built the latest X, mesa etc from the git repo and loaded the latest kernel but still have the problem, though now my screen doesn't lose horizontal sync like it used to before I uppgraded X etc. Below is a lspci of my laptop. 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02) 00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02) 00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02) 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02) 05:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller 05:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19) 05:01.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 01) 05:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 0a) 05:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10) On 11/18/2013 12:41 PM, Bruno Prémont wrote: Hi Stephen, You may want to CC intel-...@lists.freedesktop.org for i915 issues (even if you are not subscribed and you mail will wait for a moderator to let it go through). In case of intel GPU hangs you should at least include /sys/kernel/debug/dri/0/i915_error_state, probably submitting as a bug report on bugs.freedesktop.org due to its size. If you have any indication on what triggers the hang, please add! Bruno On Sun, 17 November 2013 Stephen Clark wrote: Hi List, I am getting this in kernel 3.11 x86_64 Nov 17 18:56:19 joker4 kernel: [drm:i915_hangcheck_elapsed] *ERROR* stuck on render ring Nov 17 18:56:19 joker4 kernel: [drm] capturing error event; look for more information in /sys/kernel/debug/dri/0/i915_error_state Nov 17 18:56:19 joker4 kernel: swapper/1: page allocation failure: order:6, mode:0x200020 Nov 17 18:56:19 joker4 kernel: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.6-1.el6.elrepo.x86_64 #1 Nov 17 18:56:19 joker4 kernel: Hardware name: To Be Filled By O.E.M. Z96F/Z96F, BIOS 080012 08/29/2006 Nov 17 18:56:19 joker4 kernel: 0006 8800b73038e0 815f7f89 0010 Nov 17 18:56:19 joker4 kernel: 00200020 8800b7303970 8114243d 8800b778ab28 Nov 17 18:56:19
Re: i915 driver gpu hung kernel 3.11
Hi Bruno, I have tested the latest kernel and X, mesa etc, but am still using wine-1.3.24. I am working on upgrading that. If I still have the error I will file a bug report at bugs.freedesktop.org. I already have a login because of the same problem happening with Myst 5, but it was never resolved. Do you know if there is a comprehensive set of test I can run to make sure my hardware is OK. When I run dxdiag under wine it passes all tests, but then when trying to play Myst online or Myst 5 I get the gpu hung situation. Anyway thanks for taking the time to respond. Regards, Steve On 11/20/2013 12:26 PM, Bruno Prémont wrote: Hi Stephen, On Tue, 19 November 2013 Stephen Clarksclar...@earthlink.net wrote: Thanks for the response. I have subscribed to the intel-gfx list. I didn't post the error_state file since it huge. It's best to submit a but report on bugs.freedesktop.org and attach the error_state there (compressed if needed) - repeating the information you provided in this thread. Without the error_state chances of getting some developer look at it and have a chance of understanding the cause are small. If they can reproduce it's a bonus. Once you have done so, replying with a reference to the bug might help people who find your report in mailing list archives. Bruno I was trying to play Myst Online using wine-1.3.24. I get started and start moving my avatar fairly quickly I get the error. I have built the latest X, mesa etc from the git repo and loaded the latest kernel but still have the problem, though now my screen doesn't lose horizontal sync like it used to before I uppgraded X etc. Below is a lspci of my laptop. 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02) 00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02) 00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02) 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02) 05:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller 05:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19) 05:01.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 01) 05:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 0a) 05:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10) On 11/18/2013 12:41 PM, Bruno Prémont wrote: Hi Stephen, You may want to CC intel-...@lists.freedesktop.org for i915 issues (even if you are not subscribed and you mail will wait for a moderator to let it go through). In case of intel GPU hangs you should at least include /sys/kernel/debug/dri/0/i915_error_state, probably submitting as a bug report on bugs.freedesktop.org due to its size. If you have any indication on what triggers the hang, please add! Bruno On Sun, 17 November 2013 Stephen Clarksclar...@earthlink.net wrote: Hi List, I am getting this in kernel 3.11 x86_64 Nov 17 18:56:19 joker4 kernel: [drm:i915_hangcheck_elapsed] *ERROR* stuck on render ring Nov 17 18:56:19 joker4 kernel: [drm] capturing error event; look for more information in /sys/kernel/debug/dri/0/i915_error_state Nov 17 18:56:19 joker4 kernel: swapper/1: page allocation failure: order:6, mode:0x200020 Nov 17 18:56:19 joker4 kernel: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.6-1.el6.elrepo.x86_64 #1 Nov 17 18:56:19 joker4 kernel: Hardware name: To Be Filled By O.E.M. Z96F/Z96F, BIOS 080012 08/29/2006 Nov 17 18:56:19 joker4 kernel: 0006 8800b73038e0 815f7f89 0010 Nov 17 18:56:19 joker4 kernel: 00200020 8800b7303970
Re: i915 driver gpu hung kernel 3.11
Hi Bruno, Thanks for the response. I have subscribed to the intel-gfx list. I didn't post the error_state file since it huge. I was trying to play Myst Online using wine-1.3.24. I get started and start moving my avatar fairly quickly I get the error. I have built the latest X, mesa etc from the git repo and loaded the latest kernel but still have the problem, though now my screen doesn't lose horizontal sync like it used to before I uppgraded X etc. Below is a lspci of my laptop. 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02) 00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02) 00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02) 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02) 05:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller 05:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19) 05:01.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 01) 05:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 0a) 05:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10) On 11/18/2013 12:41 PM, Bruno Prémont wrote: Hi Stephen, You may want to CC intel-...@lists.freedesktop.org for i915 issues (even if you are not subscribed and you mail will wait for a moderator to let it go through). In case of intel GPU hangs you should at least include /sys/kernel/debug/dri/0/i915_error_state, probably submitting as a bug report on bugs.freedesktop.org due to its size. If you have any indication on what triggers the hang, please add! Bruno On Sun, 17 November 2013 Stephen Clark wrote: Hi List, I am getting this in kernel 3.11 x86_64 Nov 17 18:56:19 joker4 kernel: [drm:i915_hangcheck_elapsed] *ERROR* stuck on render ring Nov 17 18:56:19 joker4 kernel: [drm] capturing error event; look for more information in /sys/kernel/debug/dri/0/i915_error_state Nov 17 18:56:19 joker4 kernel: swapper/1: page allocation failure: order:6, mode:0x200020 Nov 17 18:56:19 joker4 kernel: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.6-1.el6.elrepo.x86_64 #1 Nov 17 18:56:19 joker4 kernel: Hardware name: To Be Filled By O.E.M. Z96F/Z96F, BIOS 080012 08/29/2006 Nov 17 18:56:19 joker4 kernel: 0006 8800b73038e0 815f7f89 0010 Nov 17 18:56:19 joker4 kernel: 00200020 8800b7303970 8114243d 8800b778ab28 Nov 17 18:56:19 joker4 kernel: 0031 8800b7789000 00060002 Nov 17 18:56:19 joker4 kernel: Call Trace: Nov 17 18:56:19 joker4 kernel: [] dump_stack+0x49/0x60 Nov 17 18:56:19 joker4 kernel: [] warn_alloc_failed+0xfd/0x160 Nov 17 18:56:19 joker4 kernel: [] ? wakeup_kswapd+0x10c/0x140 Nov 17 18:56:19 joker4 kernel: [] __alloc_pages_slowpath+0x4ae/0x7c0 Nov 17 18:56:19 joker4 kernel: [] ? get_page_from_freelist+0x2dd/0x710 Nov 17 18:56:19 joker4 kernel: [] __alloc_pages_nodemask+0x30e/0x330 Nov 17 18:56:19 joker4 kernel: [] kmem_getpages+0x67/0x1e0 Nov 17 18:56:19 joker4 kernel: [] fallback_alloc+0x189/0x270 Nov 17 18:56:19 joker4 kernel: [] cache_alloc_node+0x95/0x160 Nov 17 18:56:19 joker4 kernel: [] __kmalloc+0x177/0x2c0 Nov 17 18:56:19 joker4 kernel: [] ? i915_capture_error_state+0x379/0x720 [i915] Nov 17 18:56:19 joker4 kernel: [] i915_capture_error_state+0x379/0x720 [i915] Nov 17 18:56:19 joker4 kernel: [] i915_handle_error+0x2b/0x80 [i915] Nov 17 18:56:19 joker4 kernel: [] i915_hangcheck_elapsed+0x2ce/0x350 [i915] Nov 17 18:56:19 joker4 kernel: [] ? sched_clock+0x9/0x10 Nov 17 18:56
Re: i915 driver gpu hung kernel 3.11
Hi Bruno, Thanks for the response. I have subscribed to the intel-gfx list. I didn't post the error_state file since it huge. I was trying to play Myst Online using wine-1.3.24. I get started and start moving my avatar fairly quickly I get the error. I have built the latest X, mesa etc from the git repo and loaded the latest kernel but still have the problem, though now my screen doesn't lose horizontal sync like it used to before I uppgraded X etc. Below is a lspci of my laptop. 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02) 00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02) 00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02) 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02) 05:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller 05:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19) 05:01.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 01) 05:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 0a) 05:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10) On 11/18/2013 12:41 PM, Bruno Prémont wrote: Hi Stephen, You may want to CC intel-...@lists.freedesktop.org for i915 issues (even if you are not subscribed and you mail will wait for a moderator to let it go through). In case of intel GPU hangs you should at least include /sys/kernel/debug/dri/0/i915_error_state, probably submitting as a bug report on bugs.freedesktop.org due to its size. If you have any indication on what triggers the hang, please add! Bruno On Sun, 17 November 2013 Stephen Clarksclar...@earthlink.net wrote: Hi List, I am getting this in kernel 3.11 x86_64 Nov 17 18:56:19 joker4 kernel: [drm:i915_hangcheck_elapsed] *ERROR* stuck on render ring Nov 17 18:56:19 joker4 kernel: [drm] capturing error event; look for more information in /sys/kernel/debug/dri/0/i915_error_state Nov 17 18:56:19 joker4 kernel: swapper/1: page allocation failure: order:6, mode:0x200020 Nov 17 18:56:19 joker4 kernel: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.6-1.el6.elrepo.x86_64 #1 Nov 17 18:56:19 joker4 kernel: Hardware name: To Be Filled By O.E.M. Z96F/Z96F, BIOS 080012 08/29/2006 Nov 17 18:56:19 joker4 kernel: 0006 8800b73038e0 815f7f89 0010 Nov 17 18:56:19 joker4 kernel: 00200020 8800b7303970 8114243d 8800b778ab28 Nov 17 18:56:19 joker4 kernel: 0031 8800b7789000 00060002 Nov 17 18:56:19 joker4 kernel: Call Trace: Nov 17 18:56:19 joker4 kernel:IRQ [815f7f89] dump_stack+0x49/0x60 Nov 17 18:56:19 joker4 kernel: [8114243d] warn_alloc_failed+0xfd/0x160 Nov 17 18:56:19 joker4 kernel: [8114e98c] ? wakeup_kswapd+0x10c/0x140 Nov 17 18:56:19 joker4 kernel: [811455ae] __alloc_pages_slowpath+0x4ae/0x7c0 Nov 17 18:56:19 joker4 kernel: [81142d9d] ? get_page_from_freelist+0x2dd/0x710 Nov 17 18:56:19 joker4 kernel: [81145bce] __alloc_pages_nodemask+0x30e/0x330 Nov 17 18:56:19 joker4 kernel: [8118c437] kmem_getpages+0x67/0x1e0 Nov 17 18:56:19 joker4 kernel: [8118dea9] fallback_alloc+0x189/0x270 Nov 17 18:56:19 joker4 kernel: [8118dc55] cache_alloc_node+0x95/0x160 Nov 17 18:56:19 joker4 kernel: [8118e9b7] __kmalloc+0x177/0x2c0 Nov 17 18:56:19 joker4 kernel: [a0044a29] ? i915_capture_error_state+0x379/0x720 [i915] Nov 17 18:56:19 joker4 kernel: [a0044a29] i915_capture_error_state+0x379/0x720 [i915]
i915 driver gpu hung kernel 3.11
Hi List, I am getting this in kernel 3.11 x86_64 Nov 17 18:56:19 joker4 kernel: [drm:i915_hangcheck_elapsed] *ERROR* stuck on render ring Nov 17 18:56:19 joker4 kernel: [drm] capturing error event; look for more information in /sys/kernel/debug/dri/0/i915_error_state Nov 17 18:56:19 joker4 kernel: swapper/1: page allocation failure: order:6, mode:0x200020 Nov 17 18:56:19 joker4 kernel: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.6-1.el6.elrepo.x86_64 #1 Nov 17 18:56:19 joker4 kernel: Hardware name: To Be Filled By O.E.M. Z96F/Z96F, BIOS 080012 08/29/2006 Nov 17 18:56:19 joker4 kernel: 0006 8800b73038e0 815f7f89 0010 Nov 17 18:56:19 joker4 kernel: 00200020 8800b7303970 8114243d 8800b778ab28 Nov 17 18:56:19 joker4 kernel: 0031 8800b7789000 00060002 Nov 17 18:56:19 joker4 kernel: Call Trace: Nov 17 18:56:19 joker4 kernel: [] dump_stack+0x49/0x60 Nov 17 18:56:19 joker4 kernel: [] warn_alloc_failed+0xfd/0x160 Nov 17 18:56:19 joker4 kernel: [] ? wakeup_kswapd+0x10c/0x140 Nov 17 18:56:19 joker4 kernel: [] __alloc_pages_slowpath+0x4ae/0x7c0 Nov 17 18:56:19 joker4 kernel: [] ? get_page_from_freelist+0x2dd/0x710 Nov 17 18:56:19 joker4 kernel: [] __alloc_pages_nodemask+0x30e/0x330 Nov 17 18:56:19 joker4 kernel: [] kmem_getpages+0x67/0x1e0 Nov 17 18:56:19 joker4 kernel: [] fallback_alloc+0x189/0x270 Nov 17 18:56:19 joker4 kernel: [] cache_alloc_node+0x95/0x160 Nov 17 18:56:19 joker4 kernel: [] __kmalloc+0x177/0x2c0 Nov 17 18:56:19 joker4 kernel: [] ? i915_capture_error_state+0x379/0x720 [i915] Nov 17 18:56:19 joker4 kernel: [] i915_capture_error_state+0x379/0x720 [i915] Nov 17 18:56:19 joker4 kernel: [] i915_handle_error+0x2b/0x80 [i915] Nov 17 18:56:19 joker4 kernel: [] i915_hangcheck_elapsed+0x2ce/0x350 [i915] Nov 17 18:56:19 joker4 kernel: [] ? sched_clock+0x9/0x10 Nov 17 18:56:19 joker4 kernel: [] ? sched_clock_local+0x25/0x90 Nov 17 18:56:19 joker4 kernel: [] ? usb_add_hcd+0x3d0/0x3d0 Nov 17 18:56:19 joker4 kernel: [] ? i915_handle_error+0x80/0x80 [i915] Nov 17 18:56:19 joker4 kernel: [] call_timer_fn+0x49/0x120 Nov 17 18:56:19 joker4 kernel: [] run_timer_softirq+0x23b/0x2a0 Nov 17 18:56:19 joker4 kernel: [] ? timerqueue_add+0x60/0xb0 Nov 17 18:56:19 joker4 kernel: [] ? i915_handle_error+0x80/0x80 [i915] Nov 17 18:56:19 joker4 kernel: [] __do_softirq+0xf7/0x270 Nov 17 18:56:19 joker4 kernel: [] ? hrtimer_interrupt+0x163/0x260 Nov 17 18:56:19 joker4 kernel: [] call_softirq+0x1c/0x30 Nov 17 18:56:19 joker4 kernel: [] do_softirq+0x65/0xa0 Nov 17 18:56:19 joker4 kernel: [] irq_exit+0xc5/0xd0 Nov 17 18:56:19 joker4 kernel: [] smp_apic_timer_interrupt+0x4a/0x5a Nov 17 18:56:19 joker4 kernel: [] apic_timer_interrupt+0x6d/0x80 Nov 17 18:56:19 joker4 kernel: [] ? cpu_idle_loop+0x10a/0x210 Nov 17 18:56:19 joker4 kernel: [] ? cpu_idle_loop+0xdc/0x210 Nov 17 18:56:19 joker4 kernel: [] cpu_startup_entry+0x70/0x80 Nov 17 18:56:19 joker4 kernel: [] start_secondary+0xcd/0xd0 Nov 17 18:56:19 joker4 kernel: SLAB: Unable to allocate memory on node 0 (gfp=0x20) Nov 17 18:56:19 joker4 kernel: cache: kmalloc-262144, object size: 262144, order: 6 Nov 17 18:56:19 joker4 kernel: node 0: slabs: 0/0, objs: 0/0, free: 0 Nov 17 18:56:19 joker4 kernel: [drm:i915_set_reset_status] *ERROR* render ring hung inside bo (0x85c000 ctx 0) at 0x85c97c is this fixed in 3.12? Just checked get the same thing in 3.12 but no trace back. Nov 17 19:41:33 joker4 kernel: [drm] stuck on render ring Nov 17 19:41:33 joker4 kernel: [drm] capturing error event; look for more information in /sys/class/drm/card0/error Nov 17 19:41:33 joker4 kernel: [drm:i915_set_reset_status] *ERROR* render ring hung inside bo (0x7214000 ctx 0) at 0x72142e0 Nov 17 19:41:33 joker4 kernel: [drm:i915_reset] *ERROR* Failed to reset chip. Thanks, Steve - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
i915 driver gpu hung kernel 3.11
Hi List, I am getting this in kernel 3.11 x86_64 Nov 17 18:56:19 joker4 kernel: [drm:i915_hangcheck_elapsed] *ERROR* stuck on render ring Nov 17 18:56:19 joker4 kernel: [drm] capturing error event; look for more information in /sys/kernel/debug/dri/0/i915_error_state Nov 17 18:56:19 joker4 kernel: swapper/1: page allocation failure: order:6, mode:0x200020 Nov 17 18:56:19 joker4 kernel: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.6-1.el6.elrepo.x86_64 #1 Nov 17 18:56:19 joker4 kernel: Hardware name: To Be Filled By O.E.M. Z96F/Z96F, BIOS 080012 08/29/2006 Nov 17 18:56:19 joker4 kernel: 0006 8800b73038e0 815f7f89 0010 Nov 17 18:56:19 joker4 kernel: 00200020 8800b7303970 8114243d 8800b778ab28 Nov 17 18:56:19 joker4 kernel: 0031 8800b7789000 00060002 Nov 17 18:56:19 joker4 kernel: Call Trace: Nov 17 18:56:19 joker4 kernel: IRQ [815f7f89] dump_stack+0x49/0x60 Nov 17 18:56:19 joker4 kernel: [8114243d] warn_alloc_failed+0xfd/0x160 Nov 17 18:56:19 joker4 kernel: [8114e98c] ? wakeup_kswapd+0x10c/0x140 Nov 17 18:56:19 joker4 kernel: [811455ae] __alloc_pages_slowpath+0x4ae/0x7c0 Nov 17 18:56:19 joker4 kernel: [81142d9d] ? get_page_from_freelist+0x2dd/0x710 Nov 17 18:56:19 joker4 kernel: [81145bce] __alloc_pages_nodemask+0x30e/0x330 Nov 17 18:56:19 joker4 kernel: [8118c437] kmem_getpages+0x67/0x1e0 Nov 17 18:56:19 joker4 kernel: [8118dea9] fallback_alloc+0x189/0x270 Nov 17 18:56:19 joker4 kernel: [8118dc55] cache_alloc_node+0x95/0x160 Nov 17 18:56:19 joker4 kernel: [8118e9b7] __kmalloc+0x177/0x2c0 Nov 17 18:56:19 joker4 kernel: [a0044a29] ? i915_capture_error_state+0x379/0x720 [i915] Nov 17 18:56:19 joker4 kernel: [a0044a29] i915_capture_error_state+0x379/0x720 [i915] Nov 17 18:56:19 joker4 kernel: [a0044dfb] i915_handle_error+0x2b/0x80 [i915] Nov 17 18:56:19 joker4 kernel: [a004511e] i915_hangcheck_elapsed+0x2ce/0x350 [i915] Nov 17 18:56:19 joker4 kernel: [8101b019] ? sched_clock+0x9/0x10 Nov 17 18:56:19 joker4 kernel: [8109d905] ? sched_clock_local+0x25/0x90 Nov 17 18:56:19 joker4 kernel: [814711f0] ? usb_add_hcd+0x3d0/0x3d0 Nov 17 18:56:19 joker4 kernel: [a0044e50] ? i915_handle_error+0x80/0x80 [i915] Nov 17 18:56:19 joker4 kernel: [81073b19] call_timer_fn+0x49/0x120 Nov 17 18:56:19 joker4 kernel: [8107470b] run_timer_softirq+0x23b/0x2a0 Nov 17 18:56:19 joker4 kernel: [812b2660] ? timerqueue_add+0x60/0xb0 Nov 17 18:56:19 joker4 kernel: [a0044e50] ? i915_handle_error+0x80/0x80 [i915] Nov 17 18:56:19 joker4 kernel: [8106c147] __do_softirq+0xf7/0x270 Nov 17 18:56:19 joker4 kernel: [8108e0c3] ? hrtimer_interrupt+0x163/0x260 Nov 17 18:56:19 joker4 kernel: [81606adc] call_softirq+0x1c/0x30 Nov 17 18:56:19 joker4 kernel: [81015885] do_softirq+0x65/0xa0 Nov 17 18:56:19 joker4 kernel: [8106be75] irq_exit+0xc5/0xd0 Nov 17 18:56:19 joker4 kernel: [8160757a] smp_apic_timer_interrupt+0x4a/0x5a Nov 17 18:56:19 joker4 kernel: [81605e1d] apic_timer_interrupt+0x6d/0x80 Nov 17 18:56:19 joker4 kernel: EOI [810bb1aa] ? cpu_idle_loop+0x10a/0x210 Nov 17 18:56:19 joker4 kernel: [810bb17c] ? cpu_idle_loop+0xdc/0x210 Nov 17 18:56:19 joker4 kernel: [810bb320] cpu_startup_entry+0x70/0x80 Nov 17 18:56:19 joker4 kernel: [810437bd] start_secondary+0xcd/0xd0 Nov 17 18:56:19 joker4 kernel: SLAB: Unable to allocate memory on node 0 (gfp=0x20) Nov 17 18:56:19 joker4 kernel: cache: kmalloc-262144, object size: 262144, order: 6 Nov 17 18:56:19 joker4 kernel: node 0: slabs: 0/0, objs: 0/0, free: 0 Nov 17 18:56:19 joker4 kernel: [drm:i915_set_reset_status] *ERROR* render ring hung inside bo (0x85c000 ctx 0) at 0x85c97c is this fixed in 3.12? Just checked get the same thing in 3.12 but no trace back. Nov 17 19:41:33 joker4 kernel: [drm] stuck on render ring Nov 17 19:41:33 joker4 kernel: [drm] capturing error event; look for more information in /sys/class/drm/card0/error Nov 17 19:41:33 joker4 kernel: [drm:i915_set_reset_status] *ERROR* render ring hung inside bo (0x7214000 ctx 0) at 0x72142e0 Nov 17 19:41:33 joker4 kernel: [drm:i915_reset] *ERROR* Failed to reset chip. Thanks, Steve - -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
test
test - is the ml alive. -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) -- 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/
test
test - is the ml alive. -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) -- 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: cpuinfo_cur_freq always max
Johannes Weiner wrote: Hi, Stephen Clark <[EMAIL PROTECTED]> writes: userspace Please supply the full dmesg output on the non-working kernel the corresponding .config (or /proc/config.gz). Added Dave to CC. Hannes Duh - I rebooted into the new kernel and no longer see the behavior I described above. Maybe I had something going in the background i didn't realize. Thing was I even started a bash empty while loop to see if /proc/cpuinfo speed would go up and it did. I have an applet that displays on my kde kicker panel that every 2 seconds reads /sys/.../cpuinfo_cur_freq and it was sitting on the max speed all the time. Hmmm. Well Thanks for the response and sorry for the false alarm. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) -- 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: cpuinfo_cur_freq always max
Johannes Weiner wrote: Hi, Stephen Clark <[EMAIL PROTECTED]> writes: Which governor are you using? ondemand? Not sure - but the only thing that is changed is the kernel - if I go back to 2.6.23.1 it works correctly. Have a look at /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor Hannes PS: Steve, please keep the list in CC. userspace -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) -- 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: cpuinfo_cur_freq always max
Johannes Weiner wrote: Hi, Stephen Clark [EMAIL PROTECTED] writes: Which governor are you using? ondemand? Not sure - but the only thing that is changed is the kernel - if I go back to 2.6.23.1 it works correctly. Have a look at /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor Hannes PS: Steve, please keep the list in CC. userspace -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) -- 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: cpuinfo_cur_freq always max
Johannes Weiner wrote: Hi, Stephen Clark [EMAIL PROTECTED] writes: userspace Please supply the full dmesg output on the non-working kernel the corresponding .config (or /proc/config.gz). Added Dave to CC. Hannes Duh - I rebooted into the new kernel and no longer see the behavior I described above. Maybe I had something going in the background i didn't realize. Thing was I even started a bash empty while loop to see if /proc/cpuinfo speed would go up and it did. I have an applet that displays on my kde kicker panel that every 2 seconds reads /sys/.../cpuinfo_cur_freq and it was sitting on the max speed all the time. Hmmm. Well Thanks for the response and sorry for the false alarm. Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) -- 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/
cpuinfo_cur_freq always max
Hello, Running linux 2.6.23.1-21.fc7 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq correctly reflects the cpu speed, when idle it is 996000 and when compiling it is 1826000. Its also the same as what is in /proc/cpuinfo. But with 2.6.23.8-34.fc7 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq is always the max cpu speed of 1826000. While cpuinfo_cur_freq is the max 1826000 /proc/cpuinfo relflects the correct speed when idle of 996000 This is on an asus laptop with an intel core 2 duo T5600 processor. Anyone else see this problem. Regards, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) -- 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/
cpuinfo_cur_freq always max
Hello, Running linux 2.6.23.1-21.fc7 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq correctly reflects the cpu speed, when idle it is 996000 and when compiling it is 1826000. Its also the same as what is in /proc/cpuinfo. But with 2.6.23.8-34.fc7 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq is always the max cpu speed of 1826000. While cpuinfo_cur_freq is the max 1826000 /proc/cpuinfo relflects the correct speed when idle of 996000 This is on an asus laptop with an intel core 2 duo T5600 processor. Anyone else see this problem. Regards, Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) -- 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: Power Saving
Dave Jones wrote: On Mon, Nov 19, 2007 at 07:41:31PM -0500, Stephen Clark wrote: > Hello List, > > I am trying to get throttling to work on the following processor I think by throttling, you actually mean changing frequency/voltage ? (throttling is something else, where the CPU skips every n cycles, which doesn't actually save any power) > with linux 2.6.17-1.2142_FC4 with no luck. wow. that's a prehistoric kernel. > AMD Athlon(tm) XP 1700+ you lose. Only the mobile athlons supported scaling their speed. And even then, only if the BIOS supported it with the correct tables. (Typically this means, "only laptops"). Dave well what about the info from /proc/ cat /proc/acpi/processor/CPU0/info processor id:0 acpi id: 0 bus mastering control: no power management:yes throttling control: yes limit interface: yes and: cat /proc/acpi/processor/CPU0/throttling state count: 2 active state:T0 states: *T0: 00% T1: 50% and: [EMAIL PROTECTED] ~]# cat /proc/acpi/processor/CPU0/power active state:C2 max_cstate: C8 bus master activity: d18324c9 states: C1: type[C1] promotion[C2] demotion[--] latency[000] usage[01340140] *C2: type[C2] promotion[--] demotion[C1] latency[090] usage[02980043] Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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/
Power Saving
Hello List, I am trying to get throttling to work on the following processor with linux 2.6.17-1.2142_FC4 with no luck. AMD Athlon(tm) XP 1700+ cat /proc/acpi/processor/CPU0/info processor id:0 acpi id: 0 bus mastering control: no power management:yes throttling control: yes limit interface: yes The /sys/devices/system/cpu/cpu0/cpufreq/* directory does not exist. I have modprobed the following cpufreq* modules. Module Size Used by cpufreq_stats 6101 0 cpufreq_powersave 2241 0 cpufreq_ondemand7009 0 cpufreq_conservative 7265 0 What am I doing wrong? Thanks Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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/
Power Saving
Hello List, I am trying to get throttling to work on the following processor with linux 2.6.17-1.2142_FC4 with no luck. AMD Athlon(tm) XP 1700+ cat /proc/acpi/processor/CPU0/info processor id:0 acpi id: 0 bus mastering control: no power management:yes throttling control: yes limit interface: yes The /sys/devices/system/cpu/cpu0/cpufreq/* directory does not exist. I have modprobed the following cpufreq* modules. Module Size Used by cpufreq_stats 6101 0 cpufreq_powersave 2241 0 cpufreq_ondemand7009 0 cpufreq_conservative 7265 0 What am I doing wrong? Thanks Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: Power Saving
Dave Jones wrote: On Mon, Nov 19, 2007 at 07:41:31PM -0500, Stephen Clark wrote: Hello List, I am trying to get throttling to work on the following processor I think by throttling, you actually mean changing frequency/voltage ? (throttling is something else, where the CPU skips every n cycles, which doesn't actually save any power) with linux 2.6.17-1.2142_FC4 with no luck. wow. that's a prehistoric kernel. AMD Athlon(tm) XP 1700+ you lose. Only the mobile athlons supported scaling their speed. And even then, only if the BIOS supported it with the correct tables. (Typically this means, only laptops). Dave well what about the info from /proc/ cat /proc/acpi/processor/CPU0/info processor id:0 acpi id: 0 bus mastering control: no power management:yes throttling control: yes limit interface: yes and: cat /proc/acpi/processor/CPU0/throttling state count: 2 active state:T0 states: *T0: 00% T1: 50% and: [EMAIL PROTECTED] ~]# cat /proc/acpi/processor/CPU0/power active state:C2 max_cstate: C8 bus master activity: d18324c9 states: C1: type[C1] promotion[C2] demotion[--] latency[000] usage[01340140] *C2: type[C2] promotion[--] demotion[C1] latency[090] usage[02980043] Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: Laptop's HDD
Maciej W. Rozycki wrote: On Sun, 4 Nov 2007, Alberto Gonzalez wrote: The problem comes from a very high rate of load/unload cycles of the heads that reaches the 300.000-600.000 limit in 2-3 years (with smartmontools it can checked it with "smartctl -A /dev/sda") . There are reports of HDD dying even earlier for this problem [2] I use: # hdparm -B 255 /dev/hda to get rid of the problem with an ATA disk where I do not care that much about power consumption. I do not know what the equivalent for a SATA disk would be, but chances are it will be easier to track it down with the reference above. Maciej - 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/ My laptop harddrive is only a little over a year old and it has a cycle count of 193 Load_Cycle_Count0x0012 021 021 000 Old_age Always - 795931 it was going up a few counts everytime I ran the smartctl -A command. It quit incrementing after I did the hdparm -B 255 command. -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: Laptop's HDD
Maciej W. Rozycki wrote: On Sun, 4 Nov 2007, Alberto Gonzalez wrote: The problem comes from a very high rate of load/unload cycles of the heads that reaches the 300.000-600.000 limit in 2-3 years (with smartmontools it can checked it with smartctl -A /dev/sda) . There are reports of HDD dying even earlier for this problem [2] I use: # hdparm -B 255 /dev/hda to get rid of the problem with an ATA disk where I do not care that much about power consumption. I do not know what the equivalent for a SATA disk would be, but chances are it will be easier to track it down with the reference above. Maciej - 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/ My laptop harddrive is only a little over a year old and it has a cycle count of 193 Load_Cycle_Count0x0012 021 021 000 Old_age Always - 795931 it was going up a few counts everytime I ran the smartctl -A command. It quit incrementing after I did the hdparm -B 255 command. -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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/
asus-laptop module
Hi List, When the asus-laptop module is loaded it automatically turns on my wireless led light irregardless of the whether or not the my wireless is up or not. I had previously been using the out of kernel asus-laptop module, which no longer compiles because of missing some structure definition, Andreas Kempe had added a module parameter to the out of tree version that let the module be loaded with the led off by passing wled=0 as a parameter. Can this be added to the in kernel version? Or the default for the wireless led be off when loading the module? Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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/
asus-laptop module
Hi List, When the asus-laptop module is loaded it automatically turns on my wireless led light irregardless of the whether or not the my wireless is up or not. I had previously been using the out of kernel asus-laptop module, which no longer compiles because of missing some structure definition, Andreas Kempe had added a module parameter to the out of tree version that let the module be loaded with the led off by passing wled=0 as a parameter. Can this be added to the in kernel version? Or the default for the wireless led be off when loading the module? Thanks, Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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/
ali_pata sets my udma to 33 when it should be 66
I just upgraded my HP N5430 laptop to fedora 7 with a 2.6.21 kernel. It used to be udma/66 under the old ide driver. ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x00011000 irq 14 ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x00011008 irq 15 scsi0 : pata_ali ata1.00: ata_hpa_resize 1: sectors = 39070080, hpa_sectors = 39070080 ata1.00: ATA-5: HITACHI_DK23CA-20, 00H1A0A3, max UDMA/100 ata1.00: 39070080 sectors, multi 16: LBA ata1.00: ata_hpa_resize 1: sectors = 39070080, hpa_sectors = 39070080 ata1.00: configured for UDMA/33 How can this be fixed? Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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/
ali_pata sets my udma to 33 when it should be 66
I just upgraded my HP N5430 laptop to fedora 7 with a 2.6.21 kernel. It used to be udma/66 under the old ide driver. ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x00011000 irq 14 ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x00011008 irq 15 scsi0 : pata_ali ata1.00: ata_hpa_resize 1: sectors = 39070080, hpa_sectors = 39070080 ata1.00: ATA-5: HITACHI_DK23CA-20, 00H1A0A3, max UDMA/100 ata1.00: 39070080 sectors, multi 16: LBA ata1.00: ata_hpa_resize 1: sectors = 39070080, hpa_sectors = 39070080 ata1.00: configured for UDMA/33 How can this be fixed? Thanks, Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
David Schwartz wrote: On Wed, 20 Jun 2007 12:55:10 -0700 "David Schwartz" <[EMAIL PROTECTED]> wrote: A key is a number. A signature is a number. They are neither statements nor instructions. The argument that GPLv2 prohibits Tivoization is really and truly absurd. It has neither a legal nor a moral leg to stand on. A computer program is a number too. No, it's not. It can be expressed as a number, but it is not a number. ??? can be expressed as a number, but it is not a number ??? sure its a number. Keys are purely numbers, they are nothing else. Signatures are pure primitive facts encoded as numbers (authority X blessed object Y). A computer program is a set of instructions to accomplish a particular result. It can be expressed as a number, but that doesn't mean it is a number. It might be true in principle to develop a scheme whereby every physical object uniquely corresponds to an extremely large number. That doesn't turn physical objects into numbers. DS - 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/ -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
David Schwartz wrote: On Wed, 20 Jun 2007 12:55:10 -0700 David Schwartz [EMAIL PROTECTED] wrote: A key is a number. A signature is a number. They are neither statements nor instructions. The argument that GPLv2 prohibits Tivoization is really and truly absurd. It has neither a legal nor a moral leg to stand on. A computer program is a number too. No, it's not. It can be expressed as a number, but it is not a number. ??? can be expressed as a number, but it is not a number ??? sure its a number. Keys are purely numbers, they are nothing else. Signatures are pure primitive facts encoded as numbers (authority X blessed object Y). A computer program is a set of instructions to accomplish a particular result. It can be expressed as a number, but that doesn't mean it is a number. It might be true in principle to develop a scheme whereby every physical object uniquely corresponds to an extremely large number. That doesn't turn physical objects into numbers. DS - 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/ -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: Combined mode quirk removal kills performance
Frank Sorenson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The patch to "remove combined mode quirk" (git bisect says 8cdfb29c0cd8018f92214c11c631d8926f4cb032) makes my laptop run slower than a dead sloth. "hdparm -T" indicates that buffered disk reads on my hard drive drop from 48-50 MB/sec to 1-2MB/sec, and the system is nearly unusable. System is a Dell Inspiron E1705 (Core 2 Duo 2.16GHz) running x86_64 FC6. Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGXt+JaI0dwg4A47wRAqJmAJ4k4E9ekkitOdQ72HUXbky11nD1cACghGu6 y7Y71PPaKHYcQhYSfL55bNk= =MPYY -END PGP SIGNATURE- - 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/ Hi Frank, I had the same problem. I am running FC6 and had to build a custom kernel that did not configure in the old ide driver - then my speed of my harddrive went back to normal. HTH, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: Combined mode quirk removal kills performance
Frank Sorenson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The patch to remove combined mode quirk (git bisect says 8cdfb29c0cd8018f92214c11c631d8926f4cb032) makes my laptop run slower than a dead sloth. hdparm -T indicates that buffered disk reads on my hard drive drop from 48-50 MB/sec to 1-2MB/sec, and the system is nearly unusable. System is a Dell Inspiron E1705 (Core 2 Duo 2.16GHz) running x86_64 FC6. Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGXt+JaI0dwg4A47wRAqJmAJ4k4E9ekkitOdQ72HUXbky11nD1cACghGu6 y7Y71PPaKHYcQhYSfL55bNk= =MPYY -END PGP SIGNATURE- - 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/ Hi Frank, I had the same problem. I am running FC6 and had to build a custom kernel that did not configure in the old ide driver - then my speed of my harddrive went back to normal. HTH, Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: Weird hard disk noise on shutdown (bug #7674)
Rob Landley wrote: On Tuesday 15 May 2007 5:08 pm, Dave Jones wrote: On Mon, May 14, 2007 at 07:32:43PM +0200, Tejun Heo wrote: > Francesco Pretto wrote: > > 2007/5/4, Tejun Heo <[EMAIL PROTECTED]>: > >> Yeap, the third iteration of the patch just got submitted. > >> > >> http://thread.gmane.org/gmane.linux.ide/18485 > >> > >> Unfortunately, there doesn't seem to be an easy way out. We'll need > >> userland shutdown(8) update. > >> > >> -- > >> tejun > >> > > > > Ok, i can't understand if the patch will be included in 2.6.22 (i > > didn't see it in the Andrew Morton merge plan). However, if you can > > confirm the inclusion, i can send bug reports for ubuntu and gentoo. I > > can even send an email to Miquel van Smoorenburg, who should be the > > mainstream sysvinit developer (and probably the last maintainer). > > Okay, the patch made upstream and webpage posted. > > http://linux-ata.org/shutdown.html There's a typo.. "Check whether /sys/modules/libata/parameters/spindown_compat exists. If it does, write 0 to it." should be /sys/module/libata/parameters/spindown_compat (no 's' after module) Um, hang on. So libata can't reliably turn the system off without data loss and potential damage to hardware unless userspace goes through a special song and dance? And this is _not_ considered a defect in the kernel? Why? (Is there any other piece of hardware that needs userspace to quiesce it just so the _off_switch_ can take effect? Yes, I read both the gmane thread and the linux-ata.org link. I used to maintain the busybox halt/reboot/poweroff commands, although I don't anymore. That just called reboot(), and this worked.) Why on _earth_ does complicating software suspend add extra requirements to actual shutdown? Since when does the shutdown command have to enumerate attached block devices? If anything this would belong in umount -a, but that doesn't care about the hardware of the underlying block devices and SHOULDN'T... I'm confused. Could someone please explain? Rob - 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/ I agree. This didn't happen when I was just using the ide driver, why can't libata work as well as the old ide driver. My $.02 Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: Weird hard disk noise on shutdown (bug #7674)
Rob Landley wrote: On Tuesday 15 May 2007 5:08 pm, Dave Jones wrote: On Mon, May 14, 2007 at 07:32:43PM +0200, Tejun Heo wrote: Francesco Pretto wrote: 2007/5/4, Tejun Heo [EMAIL PROTECTED]: Yeap, the third iteration of the patch just got submitted. http://thread.gmane.org/gmane.linux.ide/18485 Unfortunately, there doesn't seem to be an easy way out. We'll need userland shutdown(8) update. -- tejun Ok, i can't understand if the patch will be included in 2.6.22 (i didn't see it in the Andrew Morton merge plan). However, if you can confirm the inclusion, i can send bug reports for ubuntu and gentoo. I can even send an email to Miquel van Smoorenburg, who should be the mainstream sysvinit developer (and probably the last maintainer). Okay, the patch made upstream and webpage posted. http://linux-ata.org/shutdown.html There's a typo.. Check whether /sys/modules/libata/parameters/spindown_compat exists. If it does, write 0 to it. should be /sys/module/libata/parameters/spindown_compat (no 's' after module) Um, hang on. So libata can't reliably turn the system off without data loss and potential damage to hardware unless userspace goes through a special song and dance? And this is _not_ considered a defect in the kernel? Why? (Is there any other piece of hardware that needs userspace to quiesce it just so the _off_switch_ can take effect? Yes, I read both the gmane thread and the linux-ata.org link. I used to maintain the busybox halt/reboot/poweroff commands, although I don't anymore. That just called reboot(), and this worked.) Why on _earth_ does complicating software suspend add extra requirements to actual shutdown? Since when does the shutdown command have to enumerate attached block devices? If anything this would belong in umount -a, but that doesn't care about the hardware of the underlying block devices and SHOULDN'T... I'm confused. Could someone please explain? Rob - 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/ I agree. This didn't happen when I was just using the ide driver, why can't libata work as well as the old ide driver. My $.02 Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: Announcing free software drivers for the new Intel® 965GM Express Chipset
Jeff Garzik wrote: Great news. Here's hoping that Intel produces a standalone video card eventually, to further take away market share from closed source competitors. Jeff, not biased at all... - 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/ Yeah me too - I have a laptop with the 945gm an I am extremely happy with intel's support. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: Announcing free software drivers for the new Intel® 965GM Express Chipset
Jeff Garzik wrote: Great news. Here's hoping that Intel produces a standalone video card eventually, to further take away market share from closed source competitors. Jeff, not biased at all... - 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/ Yeah me too - I have a laptop with the 945gm an I am extremely happy with intel's support. Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: CodingStyle: start flamewar about use of braces
Lennart Sorensen wrote:
On Tue, May 08, 2007 at 05:19:45PM -0400, Jeff Garzik wrote:
+Do not unnecessarily use braces where a single statement will do.
+
+if (condition)
+ action();
+
+This does not apply if one branch of a conditional statement is a single
+statement. Use braces in both branches.
+
+if (condition) {
+ do_this();
+ do_that();
+} else {
+ otherwise();
+}
If anyone tries to add braces to my code's 'else' statements where they
are not required, that patch will get NAK'd in a heartbeat.
Oh isn't coding style fun. I personally hate code that doesn't ALWAYS
have the braces everywhere since it makes adding a print statement
or other debuging to the condition such a pain since you then have to
add braces to the condition to avoid breaking the code just to insert
a print statement. It is one of the few things I disagree with in the
linux kernel coding style.
--
Len Sorensen
-
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/
I agree - it is merely defensive programming to always have the braces,
it prevents someone
from sticking in a diag and forgetting to add braces so things go haywire.
My $.02
Steve
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
-
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 8/8] One Laptop Per Child power/battery driver
Maciej W. Rozycki wrote: On Tue, 8 May 2007, Satyam Sharma wrote: Hmmm ... what if David was German and had a couple of umlauts in his name :-) One would expect to at least _spell_ his own name properly in his code. Sources need to take care of that too (but we better stick to only UTF-8 for source files, wouldn't want to introduce ISO-8859-1 into the mix too :-) Well, my name has an acute above "o" and a dot above "z", but I do not have such a high expectation as to have it correctly spelled in comments and elsewhere within some code before I am able to get it right in official documents issued in English. And the universe is not going to collapse because of the missing accents, so I consider this an issue we can think of resolving once we have fixed all the bugs that we have. Maciej - 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/ Well stated! -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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 8/8] One Laptop Per Child power/battery driver
Dmitry Torokhov wrote: On 5/7/07, Alan Cox <[EMAIL PROTECTED]> wrote: On Mon, 7 May 2007 19:49:50 + Pavel Machek <[EMAIL PROTECTED]> wrote: On Mon 2007-05-07 16:10:53, David Woodhouse wrote: On Mon, 2007-05-07 at 14:04 +, Pavel Machek wrote: Can we stick to ascii in sources? No. Please join us in the 21st century. We had this discussion before. Kernel sources should be us-ascii. utf-8 is ok for documentation. We had this discussion before. Kernel sources should use utf-8 for comments where neccessary. Many names cannot be correctly represented in US ascii, and mangling them is just plain rude. So should we all start writing our names in native alphabets? And comments too? And while your at I think you should write all the comments and documentation in your native language as well ;-) -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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 8/8] One Laptop Per Child power/battery driver
Dmitry Torokhov wrote: On 5/7/07, Alan Cox [EMAIL PROTECTED] wrote: On Mon, 7 May 2007 19:49:50 + Pavel Machek [EMAIL PROTECTED] wrote: On Mon 2007-05-07 16:10:53, David Woodhouse wrote: On Mon, 2007-05-07 at 14:04 +, Pavel Machek wrote: Can we stick to ascii in sources? No. Please join us in the 21st century. We had this discussion before. Kernel sources should be us-ascii. utf-8 is ok for documentation. We had this discussion before. Kernel sources should use utf-8 for comments where neccessary. Many names cannot be correctly represented in US ascii, and mangling them is just plain rude. So should we all start writing our names in native alphabets? And comments too? And while your at I think you should write all the comments and documentation in your native language as well ;-) -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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 8/8] One Laptop Per Child power/battery driver
Maciej W. Rozycki wrote: On Tue, 8 May 2007, Satyam Sharma wrote: Hmmm ... what if David was German and had a couple of umlauts in his name :-) One would expect to at least _spell_ his own name properly in his code. Sources need to take care of that too (but we better stick to only UTF-8 for source files, wouldn't want to introduce ISO-8859-1 into the mix too :-) Well, my name has an acute above o and a dot above z, but I do not have such a high expectation as to have it correctly spelled in comments and elsewhere within some code before I am able to get it right in official documents issued in English. And the universe is not going to collapse because of the missing accents, so I consider this an issue we can think of resolving once we have fixed all the bugs that we have. Maciej - 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/ Well stated! -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: CodingStyle: start flamewar about use of braces
Lennart Sorensen wrote:
On Tue, May 08, 2007 at 05:19:45PM -0400, Jeff Garzik wrote:
+Do not unnecessarily use braces where a single statement will do.
+
+if (condition)
+ action();
+
+This does not apply if one branch of a conditional statement is a single
+statement. Use braces in both branches.
+
+if (condition) {
+ do_this();
+ do_that();
+} else {
+ otherwise();
+}
If anyone tries to add braces to my code's 'else' statements where they
are not required, that patch will get NAK'd in a heartbeat.
Oh isn't coding style fun. I personally hate code that doesn't ALWAYS
have the braces everywhere since it makes adding a print statement
or other debuging to the condition such a pain since you then have to
add braces to the condition to avoid breaking the code just to insert
a print statement. It is one of the few things I disagree with in the
linux kernel coding style.
--
Len Sorensen
-
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/
I agree - it is merely defensive programming to always have the braces,
it prevents someone
from sticking in a diag and forgetting to add braces so things go haywire.
My $.02
Steve
--
They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety. (Ben Franklin)
The course of history shows that as a government grows, liberty
decreases. (Thomas Jefferson)
-
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: [git patches] libata updates
Chuck Ebbert wrote: Stephen Clark wrote: I'm running fc6 but with kernel 2.6.21 from kernel.org - compiled with the .config file from fc6. My system is a asus laptop with an ich7 chipset which has both sata and pata controllers. My laptop only brings out the pata controller interface and both my hd and od are on the second channel of the pata. So can I configure out the old ide and just have ata_piix automatically control them both in 2.6.21? Sure, just edit the .config. You may need to play with options to mkinitrd though; I don't think it will include the PATA drivers for you automatically. - 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 worked - no combined_mode=libata and my hd is doing 45mb/sec. Thanks to all who replied. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: [git patches] libata updates
Jesse Barnes wrote: On Monday, April 30, 2007 1:22 pm Stephen Clark wrote: Please don't do this! Yeah the kernel will boot but the hd performance is sh*t on my laptop. I am running FC6 with kernel 2.6.21 and without the combined_mode setting my disk performance goes down to a whopping 1.25mb/sec from 44mb/sec when I boot with combined_mode=libata. It make my system unusable! So your performance is good when you add combined_mode=libata? I hope so, because that's why I added it in the first place... However, Jeff's patch won't steal your performance as long as you make sure you use the libata based drivers for everything. If you're running Fedora I think the rawhide kernels are configured this way, but the fc6 era kernels aren't. Jesse I'm running fc6 but with kernel 2.6.21 from kernel.org - compiled with the .config file from fc6. My system is a asus laptop with an ich7 chipset which has both sata and pata controllers. My laptop only brings out the pata controller interface and both my hd and od are on the second channel of the pata. So can I configure out the old ide and just have ata_piix automatically control them both in 2.6.21? Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: [git patches] libata updates
Jeff Garzik wrote: Stephen Clark wrote: Yeah the kernel will boot but the hd performance is sh*t on my laptop. I am running FC6 with kernel 2.6.21 and without the combined_mode setting my disk performance goes down to a whopping 1.25mb/sec from 44mb/sec when I boot with combined_mode=libata. It make my system unusable! No, that's the split-driver configuration that causes the slowdown. Now that both drivers fully support the hardware, either driver can make things go full speed. Please try testing the update first :) Jeff - 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/ Ok, I'am willing to test it out, but how to I get a patch file from the git stuff? I currently have the 2.6.21 kernel source. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: [git patches] libata updates
Jeff Garzik wrote: Stephen Clark wrote: Yeah the kernel will boot but the hd performance is sh*t on my laptop. I am running FC6 with kernel 2.6.21 and without the combined_mode setting my disk performance goes down to a whopping 1.25mb/sec from 44mb/sec when I boot with combined_mode=libata. It make my system unusable! No, that's the split-driver configuration that causes the slowdown. Now that both drivers fully support the hardware, either driver can make things go full speed. Please try testing the update first :) Jeff - 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/ Ok, I'am willing to test it out, but how to I get a patch file from the git stuff? I currently have the 2.6.21 kernel source. Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: [git patches] libata updates
Jesse Barnes wrote: On Monday, April 30, 2007 1:22 pm Stephen Clark wrote: Please don't do this! Yeah the kernel will boot but the hd performance is sh*t on my laptop. I am running FC6 with kernel 2.6.21 and without the combined_mode setting my disk performance goes down to a whopping 1.25mb/sec from 44mb/sec when I boot with combined_mode=libata. It make my system unusable! So your performance is good when you add combined_mode=libata? I hope so, because that's why I added it in the first place... However, Jeff's patch won't steal your performance as long as you make sure you use the libata based drivers for everything. If you're running Fedora I think the rawhide kernels are configured this way, but the fc6 era kernels aren't. Jesse I'm running fc6 but with kernel 2.6.21 from kernel.org - compiled with the .config file from fc6. My system is a asus laptop with an ich7 chipset which has both sata and pata controllers. My laptop only brings out the pata controller interface and both my hd and od are on the second channel of the pata. So can I configure out the old ide and just have ata_piix automatically control them both in 2.6.21? Thanks, Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: [git patches] libata updates
Chuck Ebbert wrote: Stephen Clark wrote: I'm running fc6 but with kernel 2.6.21 from kernel.org - compiled with the .config file from fc6. My system is a asus laptop with an ich7 chipset which has both sata and pata controllers. My laptop only brings out the pata controller interface and both my hd and od are on the second channel of the pata. So can I configure out the old ide and just have ata_piix automatically control them both in 2.6.21? Sure, just edit the .config. You may need to play with options to mkinitrd though; I don't think it will include the PATA drivers for you automatically. - 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 worked - no combined_mode=libata and my hd is doing 45mb/sec. Thanks to all who replied. Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: [git patches] libata updates
Jeff Garzik wrote: Chuck Ebbert wrote: Jeff Garzik wrote: Jeff Garzik (8): libata/IDE: remove combined mode quirk You can't just remove the "combined_mode=" kernel parameter or every Linux user who uses that will get an unbootable kernel with no good way of diagnosing the problem. It should still be accepted and just print a warning. No, most modern distros will simply Just Work(tm) due to mount by label, udev, and similar gadgets. As long as you have at least one (if not both) ATA drivers, you have a kernel that will boot your hardware. And by definition those using combined_mode= do indeed have the necessary drivers. Jeff - 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/ Please don't do this! Yeah the kernel will boot but the hd performance is sh*t on my laptop. I am running FC6 with kernel 2.6.21 and without the combined_mode setting my disk performance goes down to a whopping 1.25mb/sec from 44mb/sec when I boot with combined_mode=libata. It make my system unusable! Regards, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: [git patches] libata updates
Jeff Garzik wrote: Chuck Ebbert wrote: Jeff Garzik wrote: Jeff Garzik (8): libata/IDE: remove combined mode quirk You can't just remove the combined_mode= kernel parameter or every Linux user who uses that will get an unbootable kernel with no good way of diagnosing the problem. It should still be accepted and just print a warning. No, most modern distros will simply Just Work(tm) due to mount by label, udev, and similar gadgets. As long as you have at least one (if not both) ATA drivers, you have a kernel that will boot your hardware. And by definition those using combined_mode= do indeed have the necessary drivers. Jeff - 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/ Please don't do this! Yeah the kernel will boot but the hd performance is sh*t on my laptop. I am running FC6 with kernel 2.6.21 and without the combined_mode setting my disk performance goes down to a whopping 1.25mb/sec from 44mb/sec when I boot with combined_mode=libata. It make my system unusable! Regards, Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)
Linus Torvalds wrote: On Fri, 27 Apr 2007, Andreas Dilger wrote: It's true that this is a "feature" of ext3 with data=ordered (the default), but I suspect the same thing is now true in reiserfs too. Oh, well.. Journalling sucks. I was actually _really_ hoping that somebody would come along and tell everybody that this whole journal-logging is stupid, and that it's just better to not ever re-write blocks on disk, but instead write to new blocks with version numbers (and not re-use old blocks until new versions are stable on disk). That sort of sounds like something NCR used to do in the mainframe days files had generation numbers, and multiple generations of the files were kept around with the OS automatically removing the older ones. There was even somebody who did something like that for a PhD thesis, I forget the details (and it apparently died when the thesis was presumably accepted ;). Linus - 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/ -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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.21
Adrian Bunk wrote: On Fri, Apr 27, 2007 at 12:31:43PM -0400, Theodore Tso wrote: On Fri, Apr 27, 2007 at 04:58:05PM +0200, Adrian Bunk wrote: "no regressions" is definitely not feasible. 14 known regressions, some of them not yet debugged at all, are different from your "some small regression". Yes, but when were some of these regressions reported? Past a certain point, I think it's reasonable to look at the regression, decide how many people would be affected by it, and why it hadn't been noticed earlier, and in some cases, decide that it's better to get this debugged and fixed in the stable and development trees in parallel. 8 of them have been reported in March or earlier. [1] Patches for 2 of these 8 were available at the time of the release. [2] While the question whether to merge one of them into 2.6.21 was controversial, the other one was not controversial. For one of the bugs, it became obvious when someone looked at it after the release of 2.6.21 that between the bug report on March 31th and the release of 2.6.21 on April 21th, noone started debugging this bug. [3] [4] And look e.g. at the many (and non-trivial) changes between -rc7 and -final, resulting in more than one report from people who were running -rc7 without problems - and 2.6.21 doesn't work for them. I agree that's unfortunate. It's not a choice between "regressions don't matter" and "no regressions", it's about the place in the area between these two extremes. I have my opinions on what I want to expect from a stable Linux kernel, and other people have different opinins. Everyone is going to disagree to some extent; and their own comfort zone. So a certain amount compromise is always going to be necessary. Of course, it's up to you decide whether this has gone beyond the zone where you aren't comfortable working with other people's development style. Regards, - Ted cu Adrian [1] http://lkml.org/lkml/2007/4/26/2 [2] http://lkml.org/lkml/2007/4/25/496 [3] http://lkml.org/lkml/2007/4/26/496 [4] and although it turned out this specific regression was already fixed in 2.6.21, I hope you get my point What Adrian was doing, or anybody in the future, is not going to be productive unless Linus holds the people who are responsible for the bug to get it fixed or report why they can't. My $.02 Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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.21
Stephen Clark wrote: Jeff Garzik wrote: Stephen Clark wrote: It is laptop that does not have a serial port and I could not couldn't get the kernel to boot using a usb serial port so I couldn't get a screen capture of the intermittant panic. If you can write it down with a pen and paper, or manually copy the panic onto another computer (w/ hand and eyes), that would be helpful. Jeff Hi Jeff, It was with FC7 livecd 6.92 - thought I would just try 6.93 which I see has appeared at the mirrors. If it still happens I will copy the exception and send it in. Steve I downloaded and compile 2.6.21 and so far it seem to be running fine on my asus based S96F whitebook laptop - no panic from the rtl8169 Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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.21
Stephen Clark wrote: Jeff Garzik wrote: Stephen Clark wrote: It is laptop that does not have a serial port and I could not couldn't get the kernel to boot using a usb serial port so I couldn't get a screen capture of the intermittant panic. If you can write it down with a pen and paper, or manually copy the panic onto another computer (w/ hand and eyes), that would be helpful. Jeff Hi Jeff, It was with FC7 livecd 6.92 - thought I would just try 6.93 which I see has appeared at the mirrors. If it still happens I will copy the exception and send it in. Steve I downloaded and compile 2.6.21 and so far it seem to be running fine on my asus based S96F whitebook laptop - no panic from the rtl8169 Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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.21
Adrian Bunk wrote: On Fri, Apr 27, 2007 at 12:31:43PM -0400, Theodore Tso wrote: On Fri, Apr 27, 2007 at 04:58:05PM +0200, Adrian Bunk wrote: no regressions is definitely not feasible. 14 known regressions, some of them not yet debugged at all, are different from your some small regression. Yes, but when were some of these regressions reported? Past a certain point, I think it's reasonable to look at the regression, decide how many people would be affected by it, and why it hadn't been noticed earlier, and in some cases, decide that it's better to get this debugged and fixed in the stable and development trees in parallel. 8 of them have been reported in March or earlier. [1] Patches for 2 of these 8 were available at the time of the release. [2] While the question whether to merge one of them into 2.6.21 was controversial, the other one was not controversial. For one of the bugs, it became obvious when someone looked at it after the release of 2.6.21 that between the bug report on March 31th and the release of 2.6.21 on April 21th, noone started debugging this bug. [3] [4] And look e.g. at the many (and non-trivial) changes between -rc7 and -final, resulting in more than one report from people who were running -rc7 without problems - and 2.6.21 doesn't work for them. I agree that's unfortunate. It's not a choice between regressions don't matter and no regressions, it's about the place in the area between these two extremes. I have my opinions on what I want to expect from a stable Linux kernel, and other people have different opinins. Everyone is going to disagree to some extent; and their own comfort zone. So a certain amount compromise is always going to be necessary. Of course, it's up to you decide whether this has gone beyond the zone where you aren't comfortable working with other people's development style. Regards, - Ted cu Adrian [1] http://lkml.org/lkml/2007/4/26/2 [2] http://lkml.org/lkml/2007/4/25/496 [3] http://lkml.org/lkml/2007/4/26/496 [4] and although it turned out this specific regression was already fixed in 2.6.21, I hope you get my point What Adrian was doing, or anybody in the future, is not going to be productive unless Linus holds the people who are responsible for the bug to get it fixed or report why they can't. My $.02 Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: [ext3][kernels = 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)
Linus Torvalds wrote: On Fri, 27 Apr 2007, Andreas Dilger wrote: It's true that this is a feature of ext3 with data=ordered (the default), but I suspect the same thing is now true in reiserfs too. Oh, well.. Journalling sucks. I was actually _really_ hoping that somebody would come along and tell everybody that this whole journal-logging is stupid, and that it's just better to not ever re-write blocks on disk, but instead write to new blocks with version numbers (and not re-use old blocks until new versions are stable on disk). That sort of sounds like something NCR used to do in the mainframe days files had generation numbers, and multiple generations of the files were kept around with the OS automatically removing the older ones. There was even somebody who did something like that for a PhD thesis, I forget the details (and it apparently died when the thesis was presumably accepted ;). Linus - 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/ -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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.21
Francois Romieu wrote: Jeff Garzik <[EMAIL PROTECTED]> : Francois Romieu wrote: Pointer for the rtl8139 regression please ? I'm guessing it's this one: Subject: boot failure: rtl8139: exception in interrupt routine References : http://lkml.org/lkml/2007/3/31/160 Submitter : Stephen Clark <[EMAIL PROTECTED]> Status : unknown The poster says rtl8139, but doesn't provide more info. His lspci says "RTL8169SC", which sounds more like r8169 to me. Yes, thanks. The r8169 driver has been added a few bugfixes between 2.6.21-rc5 and now. Some are related to latent, timing changes induced bugs. Stephen, would you mind testing 2.6.21 and open a PR at bugzilla.kernel.org if the bug does not go away ? Bugzilla e-mails end directly in my mailbox. l-k traffic can be temporarily unnoticed (especially on saturday night). Sure I'll give it a try in the next couple of days. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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.21
Jeff Garzik wrote: Stephen Clark wrote: It is laptop that does not have a serial port and I could not couldn't get the kernel to boot using a usb serial port so I couldn't get a screen capture of the intermittant panic. If you can write it down with a pen and paper, or manually copy the panic onto another computer (w/ hand and eyes), that would be helpful. Jeff Hi Jeff, It was with FC7 livecd 6.92 - thought I would just try 6.93 which I see has appeared at the mirrors. If it still happens I will copy the exception and send it in. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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.21
Jeff Garzik wrote: Francois Romieu wrote: Pointer for the rtl8139 regression please ? I'm guessing it's this one: Subject: boot failure: rtl8139: exception in interrupt routine References : http://lkml.org/lkml/2007/3/31/160 Submitter : Stephen Clark <[EMAIL PROTECTED]> Status : unknown The poster says rtl8139, but doesn't provide more info. His lspci says "RTL8169SC", which sounds more like r8169 to me. Jeff - 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/ Yeah, that was my bad it is a RTL8169SC, and the problem was intermittent sometimes is cause a panic othertimes it didn't. It is laptop that does not have a serial port and I could not couldn't get the kernel to boot using a usb serial port so I couldn't get a screen capture of the intermittant panic. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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.21
Jeff Garzik wrote: IMO, the closer you look, the more warts you find. Before you starting doing your work with kernel regressions, no one was really tracking it. I bet you have helped cut down on the regressions, but I have no good way to quantify my gut feeling. Additional comments on developers and fixing regressions: * Sometimes seeing a long list, peoples' eyes glaze over. Its just human nature. A long list also gives us no idea of scale, or severity. I bet a weekly "top 10 bugs and regressions" email would help focus developer attention. * To be effective, lists, either long or top-10, must be pruned if you get a sense that only one user is affected. [With oopses and BUGs as a clear exception,] many problems benefit from at least two users reporting a bug. * It gets a bit tiresome to field the large number of driver bug reports that eventually turn out to be related to broken interrupt handling somehow. I think we developers need to get better at showing users how to isolate driver vs. PCI/ACPI/core bugs. Maybe drivers need to start introducing interrupt delivery tests into their probe code. Overall, broken interrupt handling manifests in several ways, most of which initially appear symptomatic of a broken driver. Jeff - 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/ Jeff, If hardware worked in the previous version of the kernel can't users expect the same hardware to work in this kernel? Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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.21
Krzysztof Halasa wrote: Adrian Bunk <[EMAIL PROTECTED]> writes: Look at the facts: 8 out of 14 regressions in my current list were reported in March or earlier. And for many regressions fixed it took several weeks until debugging by a kernel developer was started. We do not lack testers for getting bug reports quickly. We lack developer manpower for debugging the many regression reports. Quite possible, given the (very) limited range of the bugs. Most people just can't debug them. This isn't IMHO fundamentally wrong, and releasing a ".0" kernel with known problems isn't fundamentally wrong either. What is missing is easily accessible KNOWN_PROBLEMS information for released kernels. While I think your work documenting etc. known regressions is a very good thing, publishing it with the released kernels (certainly .0 and next stable releases, perhaps "quite stable" rc versions as well) would be ideal. A pressure for fixing the bugs is, obviously, the other very good thing. 2.6.20 was actually really good. Yes, it had some regressions, but I do believe that it was one of the least buggy releases we've had. The process _worked_. I the process worked with 2.6.21 as well. Obviously no two releases are equal, one has to be better than the other. I'm not satisfied with the result, and the world won't stop turning when I'm not tracking 2.6.22-rc regressions. Anyway, I and many others are satisfied with the result. I think it's one of the few "quite recent" things which are a great improvements. Other such things are using that weird git thing :-) and perhaps the most important - the length of devel cycle under control (I mean the lack of "2.5 series" thing). But I am not happy with the current state of released kernels. We've got stable series. With KNOWN_PROBLEMS information, sysadmins can decide if they can safely upgrade to .0 or if they have to wait for .123. Pressing the responsible people to fix the problems in .123 (would) help it greatly. The biggest problem I see is that developers want to make improvements in an area, like ide, but they don't seem to look at the old code and make it sure the new code supports everything the old code did. This causes hardware that used to work to not work, or work in a degraded fashion. My $.02 Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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.21
Krzysztof Halasa wrote: Adrian Bunk [EMAIL PROTECTED] writes: Look at the facts: 8 out of 14 regressions in my current list were reported in March or earlier. And for many regressions fixed it took several weeks until debugging by a kernel developer was started. We do not lack testers for getting bug reports quickly. We lack developer manpower for debugging the many regression reports. Quite possible, given the (very) limited range of the bugs. Most people just can't debug them. This isn't IMHO fundamentally wrong, and releasing a .0 kernel with known problems isn't fundamentally wrong either. What is missing is easily accessible KNOWN_PROBLEMS information for released kernels. While I think your work documenting etc. known regressions is a very good thing, publishing it with the released kernels (certainly .0 and next stable releases, perhaps quite stable rc versions as well) would be ideal. A pressure for fixing the bugs is, obviously, the other very good thing. 2.6.20 was actually really good. Yes, it had some regressions, but I do believe that it was one of the least buggy releases we've had. The process _worked_. I the process worked with 2.6.21 as well. Obviously no two releases are equal, one has to be better than the other. I'm not satisfied with the result, and the world won't stop turning when I'm not tracking 2.6.22-rc regressions. Anyway, I and many others are satisfied with the result. I think it's one of the few quite recent things which are a great improvements. Other such things are using that weird git thing :-) and perhaps the most important - the length of devel cycle under control (I mean the lack of 2.5 series thing). But I am not happy with the current state of released kernels. We've got stable series. With KNOWN_PROBLEMS information, sysadmins can decide if they can safely upgrade to .0 or if they have to wait for .123. Pressing the responsible people to fix the problems in .123 (would) help it greatly. The biggest problem I see is that developers want to make improvements in an area, like ide, but they don't seem to look at the old code and make it sure the new code supports everything the old code did. This causes hardware that used to work to not work, or work in a degraded fashion. My $.02 Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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.21
Jeff Garzik wrote: IMO, the closer you look, the more warts you find. Before you starting doing your work with kernel regressions, no one was really tracking it. I bet you have helped cut down on the regressions, but I have no good way to quantify my gut feeling. Additional comments on developers and fixing regressions: * Sometimes seeing a long list, peoples' eyes glaze over. Its just human nature. A long list also gives us no idea of scale, or severity. I bet a weekly top 10 bugs and regressions email would help focus developer attention. * To be effective, lists, either long or top-10, must be pruned if you get a sense that only one user is affected. [With oopses and BUGs as a clear exception,] many problems benefit from at least two users reporting a bug. * It gets a bit tiresome to field the large number of driver bug reports that eventually turn out to be related to broken interrupt handling somehow. I think we developers need to get better at showing users how to isolate driver vs. PCI/ACPI/core bugs. Maybe drivers need to start introducing interrupt delivery tests into their probe code. Overall, broken interrupt handling manifests in several ways, most of which initially appear symptomatic of a broken driver. Jeff - 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/ Jeff, If hardware worked in the previous version of the kernel can't users expect the same hardware to work in this kernel? Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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.21
Jeff Garzik wrote: Francois Romieu wrote: Pointer for the rtl8139 regression please ? I'm guessing it's this one: Subject: boot failure: rtl8139: exception in interrupt routine References : http://lkml.org/lkml/2007/3/31/160 Submitter : Stephen Clark [EMAIL PROTECTED] Status : unknown The poster says rtl8139, but doesn't provide more info. His lspci says RTL8169SC, which sounds more like r8169 to me. Jeff - 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/ Yeah, that was my bad it is a RTL8169SC, and the problem was intermittent sometimes is cause a panic othertimes it didn't. It is laptop that does not have a serial port and I could not couldn't get the kernel to boot using a usb serial port so I couldn't get a screen capture of the intermittant panic. Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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.21
Jeff Garzik wrote: Stephen Clark wrote: It is laptop that does not have a serial port and I could not couldn't get the kernel to boot using a usb serial port so I couldn't get a screen capture of the intermittant panic. If you can write it down with a pen and paper, or manually copy the panic onto another computer (w/ hand and eyes), that would be helpful. Jeff Hi Jeff, It was with FC7 livecd 6.92 - thought I would just try 6.93 which I see has appeared at the mirrors. If it still happens I will copy the exception and send it in. Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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.21
Francois Romieu wrote: Jeff Garzik [EMAIL PROTECTED] : Francois Romieu wrote: Pointer for the rtl8139 regression please ? I'm guessing it's this one: Subject: boot failure: rtl8139: exception in interrupt routine References : http://lkml.org/lkml/2007/3/31/160 Submitter : Stephen Clark [EMAIL PROTECTED] Status : unknown The poster says rtl8139, but doesn't provide more info. His lspci says RTL8169SC, which sounds more like r8169 to me. Yes, thanks. The r8169 driver has been added a few bugfixes between 2.6.21-rc5 and now. Some are related to latent, timing changes induced bugs. Stephen, would you mind testing 2.6.21 and open a PR at bugzilla.kernel.org if the bug does not go away ? Bugzilla e-mails end directly in my mailbox. l-k traffic can be temporarily unnoticed (especially on saturday night). Sure I'll give it a try in the next couple of days. Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: Loud "pop" coming from hard drive on reboot
Chuck Ebbert wrote: Stephen Clark wrote: Mark Lord wrote: Mark Lord wrote: With the patch applied, I don't see *any* new activity in those S.M.A.R.T. attributes over multiple hibernates (Linux "suspend-to-disk"). Scratch that -- operator failure. ;) The patch makes no difference over hibernates in the SMART logs. It's still logging extra Power-Off_Retract_Count pegs, which it DID NOT USED TO DO not so long ago. Now I'll poke at the shutdown again. Meanwhile, Stephen: Could you try without this line in the patched file: case ATA_16: + dev->needs_sync_cache = 1; Ie. comment out that last "dev->needs_sync_cache" line. No joy - even with that line commented out I get a click and my Power-Off_Retract_Count has incremented. I found a solution of sorts on Fedora 6: Edit /etc/rc0.d/S01halt, changing the third-from-last line so it reads: HALTARGS="-d -h -n" Then use the halt(8) command to shut down and turn off the power manually. No click and the "retract" counter does not increment. (Even this procedure incremented the counter until I changed the script.) Seems safe, using the IDE drivers, since they sync the cache anyway. Hi Chuck, I got a chance to try this and it works for me also. No pop and my retract counter does not increment. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: Loud pop coming from hard drive on reboot
Chuck Ebbert wrote: Stephen Clark wrote: Mark Lord wrote: Mark Lord wrote: With the patch applied, I don't see *any* new activity in those S.M.A.R.T. attributes over multiple hibernates (Linux suspend-to-disk). Scratch that -- operator failure. ;) The patch makes no difference over hibernates in the SMART logs. It's still logging extra Power-Off_Retract_Count pegs, which it DID NOT USED TO DO not so long ago. Now I'll poke at the shutdown again. Meanwhile, Stephen: Could you try without this line in the patched file: case ATA_16: + dev-needs_sync_cache = 1; Ie. comment out that last dev-needs_sync_cache line. No joy - even with that line commented out I get a click and my Power-Off_Retract_Count has incremented. I found a solution of sorts on Fedora 6: Edit /etc/rc0.d/S01halt, changing the third-from-last line so it reads: HALTARGS=-d -h -n Then use the halt(8) command to shut down and turn off the power manually. No click and the retract counter does not increment. (Even this procedure incremented the counter until I changed the script.) Seems safe, using the IDE drivers, since they sync the cache anyway. Hi Chuck, I got a chance to try this and it works for me also. No pop and my retract counter does not increment. Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: Loud "pop" coming from hard drive on reboot
Jan Engelhardt wrote: On Apr 18 2007 09:39, Stephen Clark wrote: So this is the pop I hear on my new laptop that is using libata=combined_mode when I shut my system down. I didn't get the pop with the same disk drive in an older laptop that was only ide. It sounds like a relay closing or opening, but is really my drive head doing an emergency retract/park? Most(?) disks' heads are spring-/power-based so that whenever they lose power, the spring retracts the head back to the park zone. Whether it is the disk head or something else.. take out the disk, and retry. Might not be that easy with laptops, though. Jan It is definitely the disk drive. It is located in the right front corner of my laptop so I put my ear by it during shutdown and that is where the click is coming from. As I said before I had this same drive in another laptop that was strictly ide so it used the older ide driver and it never did this. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: 2.6.21-rc5 from fc7-rc2 problems
Len Brown wrote: On Wednesday 18 April 2007 16:23, Jeff Garzik wrote: Len Brown wrote: < Linux version 2.6.20-1.2933.fc6 < ([EMAIL PROTECTED]) (gcc version 4.1.1 20070105 < (Red Hat 4.1.1-51)) #1 SMP Mon Mar 19 11:38:26 EDT 2007 --- Linux version 2.6.20-1.3023.fc7 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070317 (Red Hat 4.1.2-5)) #1 SMP Sun Mar 25 22:12:02 EDT 2007 I agree that the fc7 version string looks strange, because there are other things in the fc7 dmesg which are clearly from 2.6.21, such as this: < ACPI: Core revision 20060707 --- ACPI: Core revision 20070126 Perhaps you can try building a kernel.org 2.6.21 kernel and running it on your FC6 install? The ALI15X3 stuff exists only in the working FC6 dmesg: < Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 < ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx < ALI15X3: IDE controller at PCI slot :00:0f.0 < ACPI: Unable to derive IRQ for device :00:0f.0 < ACPI: PCI Interrupt :00:0f.0[A]: no GSI < ALI15X3: chipset revision 195 < ALI15X3: not 100% native mode: will probe irqs later < ide0: BM-DMA at 0x1000-0x1007, BIOS settings: hda:DMA, hdb:pio < ide1: BM-DMA at 0x1008-0x100f, BIOS settings: hdc:DMA, hdd:pio < Probing IDE interface ide0... < hda: HITACHI_DK23CA-20, ATA DISK drive < ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 < Probing IDE interface ide1... < hdc: MATSHITADVD-ROM SR-8175, ATAPI CD/DVD-ROM drive < ide1 at 0x170-0x177,0x376 on irq 15 < Probing IDE interface ide2... < Probing IDE interface ide3... < Probing IDE interface ide4... < Probing IDE interface ide5... < hda: max request size: 128KiB < hda: 39070080 sectors (20003 MB) w/2048KiB Cache, CHS=38760/16/63, UDMA(66) < hda: cache flushes not supported < hda: hda1 hda2 < ide-floppy driver 0.99.newide FC7 looks like it is using libata instead: -Len SCSI subsystem initialized libata version 2.20 loaded. ACPI: Unable to derive IRQ for device :00:0f.0 ACPI: PCI Interrupt :00:0f.0[A]: no GSI ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x00011000 irq 14 ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x00011008 irq 15 scsi0 : pata_ali PM: Adding info for No Bus:host0 ata1.00: ATA-5: HITACHI_DK23CA-20, 00H1A0A3, max UDMA/100 < drive can do 100 ata1.00: 39070080 sectors, multi 16: LBA ata1.00: configured for UDMA/33<=== configured as 33 scsi1 : pata_ali PM: Adding info for No Bus:host1 ata2.00: ATAPI, max UDMA/33 <=== cd can't be read now ata2.00: configured for UDMA/33 PM: Adding info for No Bus:target0:0:0 scsi 0:0:0:0: Direct-Access ATA HITACHI_DK23CA-2 00H1 PQ: 0 ANSI: 5 PM: Adding info for scsi:0:0:0:0 PM: Adding info for No Bus:target1:0:0 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: soft resetting port It looks like interrupts are not being delivered? Dunno, both 2.6.20 and 2.6.21 say they're looking on IRQ14 and IRQ15. ACPI isn't involved at all with those IRQs, as it couldn't find any info for :00:0f.0[A] and thus the legacy hard-coding for IDE must rule the day. Is it possible to configure 2.6.21 with the driver that was running in 2.6.20? If yes, and that works, then we know we didn't somehow otherwise break interrupts. -Len These results are from the livecd from FC7-rc2, Chuck Ebbert said a new one is soon to be released. Let's see what the results are for this upcoming release. Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: 2.6.21-rc5 from fc7-rc2 problems
Alan Cox wrote: scsi0 : pata_ali PM: Adding info for No Bus:host0 ata1.00: ATA-5: HITACHI_DK23CA-20, 00H1A0A3, max UDMA/100 < drive can do 100 ata1.00: 39070080 sectors, multi 16: LBA ata1.00: configured for UDMA/33<=== configured as 33 How is this system actually set up - what cable is used on that drive ? ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: soft resetting port It looks like interrupts are not being delivered? We still have a problem with pata_ali and ATAPI. I'm still trying to work out wtf is going on there as I can't find any meaningful difference and even some paranoid 'assume the worst of the comments in the databook' additional code isn't helping. Hi, This is a laptop with both the cd and hardrive connected directly to the mainboard. The key is they both work correctly under 2.6.20. HTH, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: 2.6.21-rc5 from fc7-rc2 problems
Alan Cox wrote: scsi0 : pata_ali PM: Adding info for No Bus:host0 ata1.00: ATA-5: HITACHI_DK23CA-20, 00H1A0A3, max UDMA/100 drive can do 100 ata1.00: 39070080 sectors, multi 16: LBA ata1.00: configured for UDMA/33=== configured as 33 How is this system actually set up - what cable is used on that drive ? ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: soft resetting port It looks like interrupts are not being delivered? We still have a problem with pata_ali and ATAPI. I'm still trying to work out wtf is going on there as I can't find any meaningful difference and even some paranoid 'assume the worst of the comments in the databook' additional code isn't helping. Hi, This is a laptop with both the cd and hardrive connected directly to the mainboard. The key is they both work correctly under 2.6.20. HTH, Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: 2.6.21-rc5 from fc7-rc2 problems
Len Brown wrote: On Wednesday 18 April 2007 16:23, Jeff Garzik wrote: Len Brown wrote: Linux version 2.6.20-1.2933.fc6 ([EMAIL PROTECTED]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 SMP Mon Mar 19 11:38:26 EDT 2007 --- Linux version 2.6.20-1.3023.fc7 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070317 (Red Hat 4.1.2-5)) #1 SMP Sun Mar 25 22:12:02 EDT 2007 I agree that the fc7 version string looks strange, because there are other things in the fc7 dmesg which are clearly from 2.6.21, such as this: ACPI: Core revision 20060707 --- ACPI: Core revision 20070126 Perhaps you can try building a kernel.org 2.6.21 kernel and running it on your FC6 install? The ALI15X3 stuff exists only in the working FC6 dmesg: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ALI15X3: IDE controller at PCI slot :00:0f.0 ACPI: Unable to derive IRQ for device :00:0f.0 ACPI: PCI Interrupt :00:0f.0[A]: no GSI ALI15X3: chipset revision 195 ALI15X3: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x1000-0x1007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x1008-0x100f, BIOS settings: hdc:DMA, hdd:pio Probing IDE interface ide0... hda: HITACHI_DK23CA-20, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: MATSHITADVD-ROM SR-8175, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 Probing IDE interface ide2... Probing IDE interface ide3... Probing IDE interface ide4... Probing IDE interface ide5... hda: max request size: 128KiB hda: 39070080 sectors (20003 MB) w/2048KiB Cache, CHS=38760/16/63, UDMA(66) hda: cache flushes not supported hda: hda1 hda2 ide-floppy driver 0.99.newide FC7 looks like it is using libata instead: -Len SCSI subsystem initialized libata version 2.20 loaded. ACPI: Unable to derive IRQ for device :00:0f.0 ACPI: PCI Interrupt :00:0f.0[A]: no GSI ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x00011000 irq 14 ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x00011008 irq 15 scsi0 : pata_ali PM: Adding info for No Bus:host0 ata1.00: ATA-5: HITACHI_DK23CA-20, 00H1A0A3, max UDMA/100 drive can do 100 ata1.00: 39070080 sectors, multi 16: LBA ata1.00: configured for UDMA/33=== configured as 33 scsi1 : pata_ali PM: Adding info for No Bus:host1 ata2.00: ATAPI, max UDMA/33 === cd can't be read now ata2.00: configured for UDMA/33 PM: Adding info for No Bus:target0:0:0 scsi 0:0:0:0: Direct-Access ATA HITACHI_DK23CA-2 00H1 PQ: 0 ANSI: 5 PM: Adding info for scsi:0:0:0:0 PM: Adding info for No Bus:target1:0:0 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: soft resetting port It looks like interrupts are not being delivered? Dunno, both 2.6.20 and 2.6.21 say they're looking on IRQ14 and IRQ15. ACPI isn't involved at all with those IRQs, as it couldn't find any info for :00:0f.0[A] and thus the legacy hard-coding for IDE must rule the day. Is it possible to configure 2.6.21 with the driver that was running in 2.6.20? If yes, and that works, then we know we didn't somehow otherwise break interrupts. -Len These results are from the livecd from FC7-rc2, Chuck Ebbert said a new one is soon to be released. Let's see what the results are for this upcoming release. Thanks, Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: Loud pop coming from hard drive on reboot
Jan Engelhardt wrote: On Apr 18 2007 09:39, Stephen Clark wrote: So this is the pop I hear on my new laptop that is using libata=combined_mode when I shut my system down. I didn't get the pop with the same disk drive in an older laptop that was only ide. It sounds like a relay closing or opening, but is really my drive head doing an emergency retract/park? Most(?) disks' heads are spring-/power-based so that whenever they lose power, the spring retracts the head back to the park zone. Whether it is the disk head or something else.. take out the disk, and retry. Might not be that easy with laptops, though. Jan It is definitely the disk drive. It is located in the right front corner of my laptop so I put my ear by it during shutdown and that is where the click is coming from. As I said before I had this same drive in another laptop that was strictly ide so it used the older ide driver and it never did this. Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: 2.6.21-rc5 from fc7-rc2 problems
Chuck Ebbert wrote: Stephen Clark wrote: Hello, I have just tried booting the fc7-rc2 live cd on 2 of my laptops and it failed on both. FC7 test4 will be out any day now. Please test that -- test2 is ancient now. - 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/ Ok I'll try that when it comes out - I was actually using the livecd version will the new version have a livecd also? Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: Loud "pop" coming from hard drive on reboot
Mark Lord wrote: Mark Lord wrote: With the patch applied, I don't see *any* new activity in those S.M.A.R.T. attributes over multiple hibernates (Linux "suspend-to-disk"). Scratch that -- operator failure. ;) The patch makes no difference over hibernates in the SMART logs. It's still logging extra Power-Off_Retract_Count pegs, which it DID NOT USED TO DO not so long ago. Now I'll poke at the shutdown again. Meanwhile, Stephen: Could you try without this line in the patched file: case ATA_16: + dev->needs_sync_cache = 1; Ie. comment out that last "dev->needs_sync_cache" line. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html No joy - even with that line commented out I get a click and my Power-Off_Retract_Count has incremented. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: Loud "pop" coming from hard drive on reboot
Mark Lord wrote:
Alan Cox wrote:
+ if (dev->needs_flush && ata_try_flush_cache(dev)) {
return ata_scsi_flush_xlat;
+ dev->needs_flush = 0;
Works better if you swap the dev-> and return lines
Heh, yeah, I noticed that!
Here it is, *tested* now, with another fix.
It would be nice if somebody who can hear the "pop" would also test this,
as it will confirm that this is a complete fix for the problem.
My "pop" drives are busy elsewhere right now.
Tejun might use something like this, or do something better in libata-core,
but it's still helpful to have confirmation that we're on the right track.
This patch eliminates the redundant "SYNCHRONIZE_CACHE" request at shutdown
which is causing undue wear/tear/alarm to various systems.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- old/include/linux/libata.h 2007-04-18 10:30:25.0 -0400
+++ linux/include/linux/libata.h2007-04-18 10:30:28.0 -0400
@@ -499,6 +499,7 @@
struct ata_eringering;
int spdn_cnt;
unsigned inthorkage;/* List of broken features */
+ int needs_sync_cache; /* 0==sync-cache not needed */
#ifdef CONFIG_SATA_ACPI
/* ACPI objects info */
acpi_handle obj_handle;
--- old/drivers/ata/libata-scsi.c 2007-04-18 10:48:34.0 -0400
+++ linux/drivers/ata/libata-scsi.c 2007-04-18 10:51:09.0 -0400
@@ -2749,18 +2749,20 @@
return atapi_xlat;
switch (cmd) {
- case READ_6:
- case READ_10:
- case READ_16:
-
case WRITE_6:
case WRITE_10:
case WRITE_16:
+ dev->needs_sync_cache = 1;
+ case READ_6:
+ case READ_10:
+ case READ_16:
return ata_scsi_rw_xlat;
case SYNCHRONIZE_CACHE:
- if (ata_try_flush_cache(dev))
+ if (dev->needs_sync_cache && ata_try_flush_cache(dev)) {
+ dev->needs_sync_cache = 0;
return ata_scsi_flush_xlat;
+ }
break;
case VERIFY:
@@ -2769,6 +2771,7 @@
case ATA_12:
case ATA_16:
+ dev->needs_sync_cache = 1;
return ata_scsi_pass_thru;
case START_STOP:
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
I tried this on 2.6.20.2 it applied to libata with some fuzz and I had
to manually edit libata.h
When I did a shutdown I still got the click/pop.
I also noticed the last thing displayed on the lcd before it goes blank is
Synchronizing SCSI Disks - then the click/pop.
HTH,
Steve
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
-
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: Loud "pop" coming from hard drive on reboot
Alan Cox wrote: Thought about that and querying power state before doing shutdown sequence but things get somewhat ugly because shutdown sequence is driven from sd->shutdown(). We'll have to snoop both sync and shutdown commands and check whether the system is shutting down. Also, I felt very uneasy about faking successful completion to SYNCHRONIZE_CACHE. If you see a synchronize cache succeed and you then see the drive shutdown succeed then you know that a sync cache can be faked as ok safely. Any other command in between or after and it doesn't get faked This seems pretty easy to deal with at command issue. I dunno. It's already too late for 2.6.21. I was hoping we could get distros to update shutdown utilities in not-too-distant future but I have no experience with that. Is that just a wishful thinking? Probably not, but it will take a year or so and throughout this time period everyone with the wrong combination of shutdown and kernel (which will be a lot of people who compile their own kernels) are going to have problems caused by what is a very obscure piece of libata internal behaviour they'll never even know about. So this is the pop I hear on my new laptop that is using libata=combined_mode when I shut my system down. I didn't get the pop with the same disk drive in an older laptop that was only ide. It sounds like a relay closing or opening, but is really my drive head doing an emergency retract/park? - 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/ -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: Loud pop coming from hard drive on reboot
Alan Cox wrote: Thought about that and querying power state before doing shutdown sequence but things get somewhat ugly because shutdown sequence is driven from sd-shutdown(). We'll have to snoop both sync and shutdown commands and check whether the system is shutting down. Also, I felt very uneasy about faking successful completion to SYNCHRONIZE_CACHE. If you see a synchronize cache succeed and you then see the drive shutdown succeed then you know that a sync cache can be faked as ok safely. Any other command in between or after and it doesn't get faked This seems pretty easy to deal with at command issue. I dunno. It's already too late for 2.6.21. I was hoping we could get distros to update shutdown utilities in not-too-distant future but I have no experience with that. Is that just a wishful thinking? Probably not, but it will take a year or so and throughout this time period everyone with the wrong combination of shutdown and kernel (which will be a lot of people who compile their own kernels) are going to have problems caused by what is a very obscure piece of libata internal behaviour they'll never even know about. So this is the pop I hear on my new laptop that is using libata=combined_mode when I shut my system down. I didn't get the pop with the same disk drive in an older laptop that was only ide. It sounds like a relay closing or opening, but is really my drive head doing an emergency retract/park? - 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/ -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: Loud pop coming from hard drive on reboot
Mark Lord wrote:
Alan Cox wrote:
+ if (dev-needs_flush ata_try_flush_cache(dev)) {
return ata_scsi_flush_xlat;
+ dev-needs_flush = 0;
Works better if you swap the dev- and return lines
Heh, yeah, I noticed that!
Here it is, *tested* now, with another fix.
It would be nice if somebody who can hear the pop would also test this,
as it will confirm that this is a complete fix for the problem.
My pop drives are busy elsewhere right now.
Tejun might use something like this, or do something better in libata-core,
but it's still helpful to have confirmation that we're on the right track.
This patch eliminates the redundant SYNCHRONIZE_CACHE request at shutdown
which is causing undue wear/tear/alarm to various systems.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
--- old/include/linux/libata.h 2007-04-18 10:30:25.0 -0400
+++ linux/include/linux/libata.h2007-04-18 10:30:28.0 -0400
@@ -499,6 +499,7 @@
struct ata_eringering;
int spdn_cnt;
unsigned inthorkage;/* List of broken features */
+ int needs_sync_cache; /* 0==sync-cache not needed */
#ifdef CONFIG_SATA_ACPI
/* ACPI objects info */
acpi_handle obj_handle;
--- old/drivers/ata/libata-scsi.c 2007-04-18 10:48:34.0 -0400
+++ linux/drivers/ata/libata-scsi.c 2007-04-18 10:51:09.0 -0400
@@ -2749,18 +2749,20 @@
return atapi_xlat;
switch (cmd) {
- case READ_6:
- case READ_10:
- case READ_16:
-
case WRITE_6:
case WRITE_10:
case WRITE_16:
+ dev-needs_sync_cache = 1;
+ case READ_6:
+ case READ_10:
+ case READ_16:
return ata_scsi_rw_xlat;
case SYNCHRONIZE_CACHE:
- if (ata_try_flush_cache(dev))
+ if (dev-needs_sync_cache ata_try_flush_cache(dev)) {
+ dev-needs_sync_cache = 0;
return ata_scsi_flush_xlat;
+ }
break;
case VERIFY:
@@ -2769,6 +2771,7 @@
case ATA_12:
case ATA_16:
+ dev-needs_sync_cache = 1;
return ata_scsi_pass_thru;
case START_STOP:
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
I tried this on 2.6.20.2 it applied to libata with some fuzz and I had
to manually edit libata.h
When I did a shutdown I still got the click/pop.
I also noticed the last thing displayed on the lcd before it goes blank is
Synchronizing SCSI Disks - then the click/pop.
HTH,
Steve
--
They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety. (Ben Franklin)
The course of history shows that as a government grows, liberty
decreases. (Thomas Jefferson)
-
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: Loud pop coming from hard drive on reboot
Mark Lord wrote: Mark Lord wrote: With the patch applied, I don't see *any* new activity in those S.M.A.R.T. attributes over multiple hibernates (Linux suspend-to-disk). Scratch that -- operator failure. ;) The patch makes no difference over hibernates in the SMART logs. It's still logging extra Power-Off_Retract_Count pegs, which it DID NOT USED TO DO not so long ago. Now I'll poke at the shutdown again. Meanwhile, Stephen: Could you try without this line in the patched file: case ATA_16: + dev-needs_sync_cache = 1; Ie. comment out that last dev-needs_sync_cache line. Cheers - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html No joy - even with that line commented out I get a click and my Power-Off_Retract_Count has incremented. Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: 2.6.21-rc5 from fc7-rc2 problems
Chuck Ebbert wrote: Stephen Clark wrote: Hello, I have just tried booting the fc7-rc2 live cd on 2 of my laptops and it failed on both. FC7 test4 will be out any day now. Please test that -- test2 is ancient now. - 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/ Ok I'll try that when it comes out - I was actually using the livecd version will the new version have a livecd also? Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: 2.6.21-rc5 from fc7-rc2 problems
Stephen Clark wrote: Andrew Morton wrote: On Sat, 31 Mar 2007 16:14:01 -0400 Stephen Clark <[EMAIL PROTECTED]> wrote: Hello, I have just tried booting the fc7-rc2 live cd on 2 of my laptops and it failed on both. Laptop 1 is an asus vbi s96f that get a panic that says exception in interrupt routine for my rtl8139. This device works fine in 2.6.20.2 That's regression #1. Are you able to take a photograph of the screen when it has crashed? Setting the display to 50 rows would make that more useful. (serial console would be better, but I assume that thing has no serial port). The other laptop is a hp n5430 it fail in the ali-pata driver not being able to read the cdrom, timeing out and dropping into a bash shell telling me to tell it where the root filesystem is. That's #2, I guess. Also it sets my hard drive to udma/33 when it run find at udma/66 under 2.6.20.1. #3. Hopefully it's related to #2. Please send the full dmesg output for 2.6.20.1 on the n5430. It would really be nice if the people makeing all these changes would at least keep things compatible with what they were before. These are regressions guys! We try ;) This hp n5430 system works fine with 2.6.20.1. Thanks, it helps. I'll see if I can get a serial port console setup on each laptop, failing that I'll take a photo. Thanks, Steve First this actually from fc7-rc3 but it is still 2.6.21-rc5 Here is the console output from booting the cd 2.6.21-rc5 on my HP N5430 laptop followed by booting fc6 2.6.20.1-2933 Note: From fedora test 3 release anouncement: System Level Changes * Fedora 7 Test 3 features a 2.6.21rc5 based kernel. Current release information is being tracked on the kernel release notes source page. even though the kernel message below says it is 2.6.20 maybe fedora people can speak to this. Linux version 2.6.20-1.3023.fc7 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070317 (Red Hat 4.1.2-5)) #1 SMP Sun Mar 25 22:12:02 EDT 2007 BIOS-provided physical RAM map: sanitize start sanitize end copy_e820_map() start: size: 0009f000 end: 0009f000 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 0009f000 size: 00061000 end: 0010 type: 2 copy_e820_map() start: 0010 size: 1fef end: 1fff type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 1fff size: f000 end: 1000 type: 3 copy_e820_map() start: 1000 size: 1000 end: 2000 type: 4 copy_e820_map() start: fff8 size: 0008 end: 0001 type: 2 BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 0010 (reserved) BIOS-e820: 0010 - 1fff (usable) BIOS-e820: 1fff - 1000 (ACPI data) BIOS-e820: 1000 - 2000 (ACPI NVS) BIOS-e820: fff8 - 0001 (reserved) 0MB HIGHMEM available. 511MB LOWMEM available. Using x86 segment limits to approximate NX protection Entering add_active_range(0, 0, 131056) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 131056 HighMem131056 -> 131056 early_node_map[1] active PFN ranges 0:0 -> 131056 On node 0 totalpages: 131056 DMA zone: 52 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4044 pages, LIFO batch:0 Normal zone: 1611 pages used for memmap Normal zone: 125349 pages, LIFO batch:31 HighMem zone: 0 pages used for memmap DMI 2.2 present. Using APIC driver default ACPI: RSDP 000F7C20, 0014 (r0 PTLTD ) ACPI: RSDT 1FFFCC46, 002C (r1 PTLTDRSDT604 LTP0) ACPI: FACP 1FFFEF64, 0074 (r1 ALIM1533 604 PTL F4240) ACPI: DSDT 1FFFCC72, 22F2 (r1 COMPAL 736 604 MSFT 10D) ACPI: FACS 1FC0, 0040 ACPI: BOOT 1FFFEFD8, 0028 (r1 PTLTD $SBFTBL$ 604 LTP1) ACPI: PM-Timer IO Port: 0x8008 Allocating PCI resources starting at 3000 (gap: 2000:dff8) Built 1 zonelists. Total pages: 129393 Kernel command line: initrd=initrd.img ro quiet root=CDLABEL=Fedora-7-Test3-KDE-Live rootfstype=iso9660 livecd nousb console=ttyS0,38400 BOOT_IMAGE=vmlinuz Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to d000 (0168e000) Enabling fast FPU save and restore... done. Initializing CPU#0 CPU 0 irqstacks, hard=c079e000 soft=c077e000 PID hash table entries: 2048 (order: 11, 8192 bytes) Detected 850.084 MHz processor. Console: colour VGA+ 80x25 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES:8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS:2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES:
Re: 2.6.21-rc5 from fc7-rc2 problems
Stephen Clark wrote: Andrew Morton wrote: On Sat, 31 Mar 2007 16:14:01 -0400 Stephen Clark [EMAIL PROTECTED] wrote: Hello, I have just tried booting the fc7-rc2 live cd on 2 of my laptops and it failed on both. Laptop 1 is an asus vbi s96f that get a panic that says exception in interrupt routine for my rtl8139. This device works fine in 2.6.20.2 That's regression #1. Are you able to take a photograph of the screen when it has crashed? Setting the display to 50 rows would make that more useful. (serial console would be better, but I assume that thing has no serial port). The other laptop is a hp n5430 it fail in the ali-pata driver not being able to read the cdrom, timeing out and dropping into a bash shell telling me to tell it where the root filesystem is. That's #2, I guess. Also it sets my hard drive to udma/33 when it run find at udma/66 under 2.6.20.1. #3. Hopefully it's related to #2. Please send the full dmesg output for 2.6.20.1 on the n5430. It would really be nice if the people makeing all these changes would at least keep things compatible with what they were before. These are regressions guys! We try ;) This hp n5430 system works fine with 2.6.20.1. Thanks, it helps. I'll see if I can get a serial port console setup on each laptop, failing that I'll take a photo. Thanks, Steve First this actually from fc7-rc3 but it is still 2.6.21-rc5 Here is the console output from booting the cd 2.6.21-rc5 on my HP N5430 laptop followed by booting fc6 2.6.20.1-2933 Note: From fedora test 3 release anouncement: System Level Changes * Fedora 7 Test 3 features a 2.6.21rc5 based kernel. Current release information is being tracked on the kernel release notes source page. even though the kernel message below says it is 2.6.20 maybe fedora people can speak to this. Linux version 2.6.20-1.3023.fc7 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070317 (Red Hat 4.1.2-5)) #1 SMP Sun Mar 25 22:12:02 EDT 2007 BIOS-provided physical RAM map: sanitize start sanitize end copy_e820_map() start: size: 0009f000 end: 0009f000 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 0009f000 size: 00061000 end: 0010 type: 2 copy_e820_map() start: 0010 size: 1fef end: 1fff type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 1fff size: f000 end: 1000 type: 3 copy_e820_map() start: 1000 size: 1000 end: 2000 type: 4 copy_e820_map() start: fff8 size: 0008 end: 0001 type: 2 BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 0010 (reserved) BIOS-e820: 0010 - 1fff (usable) BIOS-e820: 1fff - 1000 (ACPI data) BIOS-e820: 1000 - 2000 (ACPI NVS) BIOS-e820: fff8 - 0001 (reserved) 0MB HIGHMEM available. 511MB LOWMEM available. Using x86 segment limits to approximate NX protection Entering add_active_range(0, 0, 131056) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 131056 HighMem131056 - 131056 early_node_map[1] active PFN ranges 0:0 - 131056 On node 0 totalpages: 131056 DMA zone: 52 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4044 pages, LIFO batch:0 Normal zone: 1611 pages used for memmap Normal zone: 125349 pages, LIFO batch:31 HighMem zone: 0 pages used for memmap DMI 2.2 present. Using APIC driver default ACPI: RSDP 000F7C20, 0014 (r0 PTLTD ) ACPI: RSDT 1FFFCC46, 002C (r1 PTLTDRSDT604 LTP0) ACPI: FACP 1FFFEF64, 0074 (r1 ALIM1533 604 PTL F4240) ACPI: DSDT 1FFFCC72, 22F2 (r1 COMPAL 736 604 MSFT 10D) ACPI: FACS 1FC0, 0040 ACPI: BOOT 1FFFEFD8, 0028 (r1 PTLTD $SBFTBL$ 604 LTP1) ACPI: PM-Timer IO Port: 0x8008 Allocating PCI resources starting at 3000 (gap: 2000:dff8) Built 1 zonelists. Total pages: 129393 Kernel command line: initrd=initrd.img ro quiet root=CDLABEL=Fedora-7-Test3-KDE-Live rootfstype=iso9660 livecd nousb console=ttyS0,38400 BOOT_IMAGE=vmlinuz Local APIC disabled by BIOS -- you can enable it with lapic mapped APIC to d000 (0168e000) Enabling fast FPU save and restore... done. Initializing CPU#0 CPU 0 irqstacks, hard=c079e000 soft=c077e000 PID hash table entries: 2048 (order: 11, 8192 bytes) Detected 850.084 MHz processor. Console: colour VGA+ 80x25 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES:8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS:2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384
Re: 2.6.21-rc5 from fc7-rc2 problems
Andrew Morton wrote: On Sat, 31 Mar 2007 16:14:01 -0400 Stephen Clark <[EMAIL PROTECTED]> wrote: Hello, I have just tried booting the fc7-rc2 live cd on 2 of my laptops and it failed on both. Laptop 1 is an asus vbi s96f that get a panic that says exception in interrupt routine for my rtl8139. This device works fine in 2.6.20.2 That's regression #1. Are you able to take a photograph of the screen when it has crashed? Setting the display to 50 rows would make that more useful. (serial console would be better, but I assume that thing has no serial port). The other laptop is a hp n5430 it fail in the ali-pata driver not being able to read the cdrom, timeing out and dropping into a bash shell telling me to tell it where the root filesystem is. That's #2, I guess. Also it sets my hard drive to udma/33 when it run find at udma/66 under 2.6.20.1. #3. Hopefully it's related to #2. Please send the full dmesg output for 2.6.20.1 on the n5430. It would really be nice if the people makeing all these changes would at least keep things compatible with what they were before. These are regressions guys! We try ;) This hp n5430 system works fine with 2.6.20.1. Thanks, it helps. I'll see if I can get a serial port console setup on each laptop, failing that I'll take a photo. Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21-rc5 from fc7-rc2 problems
Hello, I have just tried booting the fc7-rc2 live cd on 2 of my laptops and it failed on both. Laptop 1 is an asus vbi s96f that get a panic that says exception in interrupt routine for my rtl8139. This device works fine in 2.6.20.2 $ lspci -v 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) Subsystem: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub Flags: bus master, fast devsel, latency 0 Capabilities: 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA]) Subsystem: ASUSTeK Computer Inc. Unknown device 1252 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at feb8 (32-bit, non-prefetchable) [size=512K] I/O ports at ec00 [size=8] Memory at d000 (32-bit, prefetchable) [size=256M] Memory at feb4 (32-bit, non-prefetchable) [size=256K] Capabilities: 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) Subsystem: ASUSTeK Computer Inc. Unknown device 1252 Flags: bus master, fast devsel, latency 0 Memory at fea8 (32-bit, non-prefetchable) [size=512K] Capabilities: 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device 1343 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at feb38000 (64-bit, non-prefetchable) [size=16K] Capabilities: 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 Capabilities: 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 Memory behind bridge: fe70-fe7f Capabilities: 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=02, sec-latency=0 I/O behind bridge: c000-cfff Memory behind bridge: fdf0-fe6f Prefetchable memory behind bridge: bdf0-bfe0 Capabilities: 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 1347 Flags: bus master, medium devsel, latency 0, IRQ 19 I/O ports at e400 [size=32] 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 1347 Flags: bus master, medium devsel, latency 0, IRQ 20 I/O ports at e480 [size=32] 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 1347 Flags: bus master, medium devsel, latency 0, IRQ 18 I/O ports at e800 [size=32] 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 1347 Flags: bus master, medium devsel, latency 0, IRQ 16 I/O ports at e880 [size=32] 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 1347 Flags: bus master, medium devsel, latency 0, IRQ 19 Memory at feb3fc00 (32-bit, non-prefetchable) [size=1K] Capabilities: 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) (prog-if 01 [Subtractive decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=05, subordinate=05, sec-latency=32 I/O behind bridge: d000-dfff Memory behind bridge: fe80-fe8f Prefetchable memory behind bridge: 8000-8000 Capabilities: 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device 1347 Flags: bus master, medium devsel, latency 0 Capabilities: 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 02) (prog-if 80 [Master]) Subsystem: ASUSTeK Computer Inc. Unknown device 1347 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 20 I/O ports at 01f0 [size=8] I/O ports at 03f4
2.6.21-rc5 from fc7-rc2 problems
Hello, I have just tried booting the fc7-rc2 live cd on 2 of my laptops and it failed on both. Laptop 1 is an asus vbi s96f that get a panic that says exception in interrupt routine for my rtl8139. This device works fine in 2.6.20.2 $ lspci -v 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) Subsystem: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub Flags: bus master, fast devsel, latency 0 Capabilities: access denied 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA]) Subsystem: ASUSTeK Computer Inc. Unknown device 1252 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at feb8 (32-bit, non-prefetchable) [size=512K] I/O ports at ec00 [size=8] Memory at d000 (32-bit, prefetchable) [size=256M] Memory at feb4 (32-bit, non-prefetchable) [size=256K] Capabilities: access denied 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) Subsystem: ASUSTeK Computer Inc. Unknown device 1252 Flags: bus master, fast devsel, latency 0 Memory at fea8 (32-bit, non-prefetchable) [size=512K] Capabilities: access denied 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device 1343 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at feb38000 (64-bit, non-prefetchable) [size=16K] Capabilities: access denied 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 Capabilities: access denied 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 Memory behind bridge: fe70-fe7f Capabilities: access denied 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=02, sec-latency=0 I/O behind bridge: c000-cfff Memory behind bridge: fdf0-fe6f Prefetchable memory behind bridge: bdf0-bfe0 Capabilities: access denied 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 1347 Flags: bus master, medium devsel, latency 0, IRQ 19 I/O ports at e400 [size=32] 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 1347 Flags: bus master, medium devsel, latency 0, IRQ 20 I/O ports at e480 [size=32] 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 1347 Flags: bus master, medium devsel, latency 0, IRQ 18 I/O ports at e800 [size=32] 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 1347 Flags: bus master, medium devsel, latency 0, IRQ 16 I/O ports at e880 [size=32] 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 1347 Flags: bus master, medium devsel, latency 0, IRQ 19 Memory at feb3fc00 (32-bit, non-prefetchable) [size=1K] Capabilities: access denied 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) (prog-if 01 [Subtractive decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=05, subordinate=05, sec-latency=32 I/O behind bridge: d000-dfff Memory behind bridge: fe80-fe8f Prefetchable memory behind bridge: 8000-8000 Capabilities: access denied 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device 1347 Flags: bus master, medium devsel, latency 0 Capabilities: access denied 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 02) (prog-if 80 [Master]) Subsystem: ASUSTeK Computer Inc. Unknown device 1347
Re: 2.6.21-rc5 from fc7-rc2 problems
Andrew Morton wrote: On Sat, 31 Mar 2007 16:14:01 -0400 Stephen Clark [EMAIL PROTECTED] wrote: Hello, I have just tried booting the fc7-rc2 live cd on 2 of my laptops and it failed on both. Laptop 1 is an asus vbi s96f that get a panic that says exception in interrupt routine for my rtl8139. This device works fine in 2.6.20.2 That's regression #1. Are you able to take a photograph of the screen when it has crashed? Setting the display to 50 rows would make that more useful. (serial console would be better, but I assume that thing has no serial port). The other laptop is a hp n5430 it fail in the ali-pata driver not being able to read the cdrom, timeing out and dropping into a bash shell telling me to tell it where the root filesystem is. That's #2, I guess. Also it sets my hard drive to udma/33 when it run find at udma/66 under 2.6.20.1. #3. Hopefully it's related to #2. Please send the full dmesg output for 2.6.20.1 on the n5430. It would really be nice if the people makeing all these changes would at least keep things compatible with what they were before. These are regressions guys! We try ;) This hp n5430 system works fine with 2.6.20.1. Thanks, it helps. I'll see if I can get a serial port console setup on each laptop, failing that I'll take a photo. Thanks, Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: RSDL v0.31
Mark Hahn wrote: So in an attempt to summarise the situation, what are the advantages of RSDL over mainline. Fairness why do you think fairness is good, especially always good? Starvation free even starvation is sometimes a good thing - there's a place for processes that only use the CPU if it is otherwise idle. that is, they are deliberately starved all the rest of the time. Much lower and bound latencies in an average sense? also, under what circumstances does this actually matter? (please don't offer something like RT audio on an overloaded machine- that's operator error, not something to design for.) Deterministic not a bad thing, but how does this make itself apparent and of value to the user? I think everyone is extremely comfortable with non-determinism (stemming from networks, caches, interleaved workloads, etc) Better interactivity for the majority of cases. how is this measured? is this statement really just a reiteration of the latency claim? Now concentrating on the very last aspect since that seems to be the sticking point. nah, I think the fairness and latency claims are the real issues. - 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/ I guess I wonder what is wrong with the current scheduler? I am running 2.6.20.2 on a whitebook laptop with a core 2 duo 1.86ghz 2gb of mem with an intel 945 shared memory graphics processor. I am currently running X with beryl have vncserver connected to my main system, which I am using to write this email, I am running also firefox and both of ingo test programs. I also am running a make -j4 on a kernel rebuild without having any pauses or any problem doing anything interactively. So again what does this new scheduler fix? Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: RSDL v0.31
Mark Hahn wrote: So in an attempt to summarise the situation, what are the advantages of RSDL over mainline. Fairness why do you think fairness is good, especially always good? Starvation free even starvation is sometimes a good thing - there's a place for processes that only use the CPU if it is otherwise idle. that is, they are deliberately starved all the rest of the time. Much lower and bound latencies in an average sense? also, under what circumstances does this actually matter? (please don't offer something like RT audio on an overloaded machine- that's operator error, not something to design for.) Deterministic not a bad thing, but how does this make itself apparent and of value to the user? I think everyone is extremely comfortable with non-determinism (stemming from networks, caches, interleaved workloads, etc) Better interactivity for the majority of cases. how is this measured? is this statement really just a reiteration of the latency claim? Now concentrating on the very last aspect since that seems to be the sticking point. nah, I think the fairness and latency claims are the real issues. - 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/ I guess I wonder what is wrong with the current scheduler? I am running 2.6.20.2 on a whitebook laptop with a core 2 duo 1.86ghz 2gb of mem with an intel 945 shared memory graphics processor. I am currently running X with beryl have vncserver connected to my main system, which I am using to write this email, I am running also firefox and both of ingo test programs. I also am running a make -j4 on a kernel rebuild without having any pauses or any problem doing anything interactively. So again what does this new scheduler fix? Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: RSDL v0.28 for 2.6.20
Con Kolivas wrote: Here is an update for RSDL to version 0.28 Full patch: http://ck.kolivas.org/patches/staircase-deadline/2.6.20-sched-rsdl-0.28.patch Series: http://ck.kolivas.org/patches/staircase-deadline/2.6.20/ The patch to get you from 0.26 to 0.28: http://ck.kolivas.org/patches/staircase-deadline/2.6.20/sched-rsdl-0.26-0.28.patch A similar patch and directories will be made for 2.6.21-rc3 without further announcement doesn't apply against 2.6.20.2: patch -p1 <~/2.6.20-sched-rsdl-0.28.patch --dry-run patching file include/linux/list.h patching file fs/proc/array.c patching file fs/pipe.c patching file include/linux/sched.h patching file include/asm-generic/bitops/sched.h patching file include/asm-s390/bitops.h patching file kernel/sched.c Hunk #41 FAILED at 3531. 1 out of 62 hunks FAILED -- saving rejects to file kernel/sched.c.rej patching file include/linux/init_task.h patching file Documentation/sched-design.txt Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: RSDL v0.28 for 2.6.20
Con Kolivas wrote: Here is an update for RSDL to version 0.28 Full patch: http://ck.kolivas.org/patches/staircase-deadline/2.6.20-sched-rsdl-0.28.patch Series: http://ck.kolivas.org/patches/staircase-deadline/2.6.20/ The patch to get you from 0.26 to 0.28: http://ck.kolivas.org/patches/staircase-deadline/2.6.20/sched-rsdl-0.26-0.28.patch A similar patch and directories will be made for 2.6.21-rc3 without further announcement doesn't apply against 2.6.20.2: patch -p1 ~/2.6.20-sched-rsdl-0.28.patch --dry-run patching file include/linux/list.h patching file fs/proc/array.c patching file fs/pipe.c patching file include/linux/sched.h patching file include/asm-generic/bitops/sched.h patching file include/asm-s390/bitops.h patching file kernel/sched.c Hunk #41 FAILED at 3531. 1 out of 62 hunks FAILED -- saving rejects to file kernel/sched.c.rej patching file include/linux/init_task.h patching file Documentation/sched-design.txt Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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] libata: warn if speed limited due to 40-wire cable (v2)
Bill Davidsen wrote: Stephen Clark wrote: Bill Davidsen wrote: Alan Cox wrote: it seems broken to manipulate xfer_mask after returning from the driver's ->mode_filter hook. this patch is more than just a speed-limited warning printk, afaics I actually suggested that order because the only way the printk can be done correctly is for it to be the very last test made. Since the mode filter is not told what mode will be used but just subtracts modes that are not allowed this should be safe. Far better to have a drive which works slowly than one which works unreliably. That would be true if the 40 wire detection was 100% accurate! The statement is completely correct, even though the detection may not be. ;-) With the current set(s) of patches to do better detection, cable evaluation should be better. But even if not, a slow system is more useful than one which doesn't work, crashes because of swap i/o errors, etc. I have had problems with cable detection on my previous laptop and my current laptop. It almost made my systems unusable. On my current laptop I was getting a thruput of a little over 1 mbps instead of the 44 mbps I get with udma set to the correct value. It took hours to upgrade my laptop from fc5 to fc6 because of this mis detection. -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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] libata: warn if speed limited due to 40-wire cable (v2)
Bill Davidsen wrote: Alan Cox wrote: it seems broken to manipulate xfer_mask after returning from the driver's ->mode_filter hook. this patch is more than just a speed-limited warning printk, afaics I actually suggested that order because the only way the printk can be done correctly is for it to be the very last test made. Since the mode filter is not told what mode will be used but just subtracts modes that are not allowed this should be safe. Far better to have a drive which works slowly than one which works unreliably. That would be true if the 40 wire detection was 100% accurate! -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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] libata: warn if speed limited due to 40-wire cable (v2)
Bill Davidsen wrote: Alan Cox wrote: it seems broken to manipulate xfer_mask after returning from the driver's -mode_filter hook. this patch is more than just a speed-limited warning printk, afaics I actually suggested that order because the only way the printk can be done correctly is for it to be the very last test made. Since the mode filter is not told what mode will be used but just subtracts modes that are not allowed this should be safe. Far better to have a drive which works slowly than one which works unreliably. That would be true if the 40 wire detection was 100% accurate! -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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] libata: warn if speed limited due to 40-wire cable (v2)
Bill Davidsen wrote: Stephen Clark wrote: Bill Davidsen wrote: Alan Cox wrote: it seems broken to manipulate xfer_mask after returning from the driver's -mode_filter hook. this patch is more than just a speed-limited warning printk, afaics I actually suggested that order because the only way the printk can be done correctly is for it to be the very last test made. Since the mode filter is not told what mode will be used but just subtracts modes that are not allowed this should be safe. Far better to have a drive which works slowly than one which works unreliably. That would be true if the 40 wire detection was 100% accurate! The statement is completely correct, even though the detection may not be. ;-) With the current set(s) of patches to do better detection, cable evaluation should be better. But even if not, a slow system is more useful than one which doesn't work, crashes because of swap i/o errors, etc. I have had problems with cable detection on my previous laptop and my current laptop. It almost made my systems unusable. On my current laptop I was getting a thruput of a little over 1 mbps instead of the 44 mbps I get with udma set to the correct value. It took hours to upgrade my laptop from fc5 to fc6 because of this mis detection. -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: GPL vs non-GPL device drivers
Pavel Machek wrote: Hi! Actually, it's quite clear under US law what a derivative work is and what rights you need to distribute it, and equally clear that compiling code does not make a "translation" in a copyright sense. Read Micro Star v. Formgen -- it's good law and it's funny and readable. I've drafted summaries from a couple of different angles since VJ requested a "translation into English", and I think this is the most coherent (and least foaming-at-the-mouth) I've crafted yet. It was written as an answer to a private query to this effect: "I write a POP server and release it under the GPL. The Evil Linker adds some hooks to my code, calls those hooks (along some of the existing ones) from his newly developed program, and only provides recipients of the binaries with source code for the modified POP server. His code depends on, and only works with, this modified version of my POP server. Doesn't he have to GPL his whole product, because he's combined his work with mine?" This is a fundamental misconception. A <> is not a "work Ok, but this is not realistic. I agree that if Evil Linker only adds two hooks "void pop_server_starting(), void pop_server_stopping()", he can get away with that. But... how does situation change when Evil Linker does #include from his binary-only part? I believe situation in this case changes a lot... And that's what embedded people are doing; I do not think they are creating their own headers or their own inline functions where headers contain them. Pavel The amount copied has to be significant. A few lines against the millions in the kernel would not be enough to be copyright infringement. -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: GPL vs non-GPL device drivers
Pavel Machek wrote: Hi! Actually, it's quite clear under US law what a derivative work is and what rights you need to distribute it, and equally clear that compiling code does not make a translation in a copyright sense. Read Micro Star v. Formgen -- it's good law and it's funny and readable. I've drafted summaries from a couple of different angles since VJ requested a translation into English, and I think this is the most coherent (and least foaming-at-the-mouth) I've crafted yet. It was written as an answer to a private query to this effect: I write a POP server and release it under the GPL. The Evil Linker adds some hooks to my code, calls those hooks (along some of the existing ones) from his newly developed program, and only provides recipients of the binaries with source code for the modified POP server. His code depends on, and only works with, this modified version of my POP server. Doesn't he have to GPL his whole product, because he's combined his work with mine? This is a fundamental misconception. A product is not a work Ok, but this is not realistic. I agree that if Evil Linker only adds two hooks void pop_server_starting(), void pop_server_stopping(), he can get away with that. But... how does situation change when Evil Linker does #include pop3/gpl_header_file_with_some_inline_functions.h from his binary-only part? I believe situation in this case changes a lot... And that's what embedded people are doing; I do not think they are creating their own headers or their own inline functions where headers contain them. Pavel The amount copied has to be significant. A few lines against the millions in the kernel would not be enough to be copyright infringement. -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: hdparm for lib_pata
Patrick Ale wrote: On 2/4/07, Stephen Clark <[EMAIL PROTECTED]> wrote: Robert Hancock wrote: But why are we taking away the users capability to control his/her own hardware. Sounds like windows. I wouldn't go as far as making that comparsion, most of all cause it's totaly invalid, with all respect. In my opinion the new pata drivers are work in progress, they only appear in the latest kernel and snapshots so please, let's allow the drivers to evolve, I am no kernel hacker or coder, nor does my interest lay here at the moment to be honest, I am a system administrator working with Unix and Linux and am interested in helping out where I can. By using the new pata drivers in favor of the old IDE drivers I took a risk, well calculated and with the very thought of encountering these kind of problems and reporting them to make things better. However, I do have to agree with the point that if the drivers/kernel, for whatever reason they might have, to switch to a lower UDMA mode, and when none is left, even to PIO mode, I should have at least the chance to switch back to a higher level of datatransfer speed. How it looks now is that the kernel and its drivers treat the devices as ATA devices with their features, but the userland programs like hdparm and sdparm and blkutil see the devices as SCSI/SATA devices, and dont allow the ioctl commands which are valid for ATA drives. Just my two euros/canadian dollars/croatian kunas in the pocket :) Patrick My point is that the driver can't be tested on every combination of hardware, so if the user doesn't have the capability to override assumptions the driver makes then he is stuck. I have had two different laptops that had to have boot time command line overrides to get the driver to allow the hardware work at what it was spec-ed at. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: hdparm for lib_pata
Robert Hancock wrote: Hi guys, Me again, sorry. Is it possible to make hdparm work with libata? I have some drives that for some reason fall back to lower UDMA settings (like UDMA/44) while the drive is UDMA/100. I blame the way I set-up my raid arrays for this and the bus not being able to handle all the data that goes trough it but that isnt really the case now. Anyway, I used to be able to force the drive back with using hdparm -X68 -d 1 /dev/sdk But with the new lib_pata drivers I get "Inappropriate iotcl for device" and HD_IO_DRIVE_CMD Input/Output errors. Or! Is there some other way to force the drive not to failback to lower UDMA settings? (Yep, I know, if this is answer, it's my risk, I cant and wont blame you for destructing my pr0n or severe trauma I suffer from losing data) Only some of the hdparm functionality is supported in libata, which is partially by design. Presently there's no way to override the DMA settings in libata, it starts out at the fastest supported settings and falls back if it gets too many errors of certain types. You shouldn't be seeing errors like this unless you have bad IDE cables or are using 40-wire cables with high UDMA modes. Can you post the output you're seeing? Ok, But why are we taking away the users capability to control his/her own hardware. Sounds like windows. My $.02 Steve Clark -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: hdparm for lib_pata
Robert Hancock wrote: Hi guys, Me again, sorry. Is it possible to make hdparm work with libata? I have some drives that for some reason fall back to lower UDMA settings (like UDMA/44) while the drive is UDMA/100. I blame the way I set-up my raid arrays for this and the bus not being able to handle all the data that goes trough it but that isnt really the case now. Anyway, I used to be able to force the drive back with using hdparm -X68 -d 1 /dev/sdk But with the new lib_pata drivers I get Inappropriate iotcl for device and HD_IO_DRIVE_CMD Input/Output errors. Or! Is there some other way to force the drive not to failback to lower UDMA settings? (Yep, I know, if this is answer, it's my risk, I cant and wont blame you for destructing my pr0n or severe trauma I suffer from losing data) Only some of the hdparm functionality is supported in libata, which is partially by design. Presently there's no way to override the DMA settings in libata, it starts out at the fastest supported settings and falls back if it gets too many errors of certain types. You shouldn't be seeing errors like this unless you have bad IDE cables or are using 40-wire cables with high UDMA modes. Can you post the output you're seeing? Ok, But why are we taking away the users capability to control his/her own hardware. Sounds like windows. My $.02 Steve Clark -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: hdparm for lib_pata
Patrick Ale wrote: On 2/4/07, Stephen Clark [EMAIL PROTECTED] wrote: Robert Hancock wrote: But why are we taking away the users capability to control his/her own hardware. Sounds like windows. I wouldn't go as far as making that comparsion, most of all cause it's totaly invalid, with all respect. In my opinion the new pata drivers are work in progress, they only appear in the latest kernel and snapshots so please, let's allow the drivers to evolve, I am no kernel hacker or coder, nor does my interest lay here at the moment to be honest, I am a system administrator working with Unix and Linux and am interested in helping out where I can. By using the new pata drivers in favor of the old IDE drivers I took a risk, well calculated and with the very thought of encountering these kind of problems and reporting them to make things better. However, I do have to agree with the point that if the drivers/kernel, for whatever reason they might have, to switch to a lower UDMA mode, and when none is left, even to PIO mode, I should have at least the chance to switch back to a higher level of datatransfer speed. How it looks now is that the kernel and its drivers treat the devices as ATA devices with their features, but the userland programs like hdparm and sdparm and blkutil see the devices as SCSI/SATA devices, and dont allow the ioctl commands which are valid for ATA drives. Just my two euros/canadian dollars/croatian kunas in the pocket :) Patrick My point is that the driver can't be tested on every combination of hardware, so if the user doesn't have the capability to override assumptions the driver makes then he is stuck. I have had two different laptops that had to have boot time command line overrides to get the driver to allow the hardware work at what it was spec-ed at. Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - 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: Abysmal disk performance, how to debug?
Willy Tarreau wrote: On Sat, Jan 20, 2007 at 02:56:20PM -0500, Stephen Clark wrote: Sunil Naidu wrote: On 1/20/07, Willy Tarreau <[EMAIL PROTECTED]> wrote: It is not expected to increase write performance, but it should help you do something else during that time, or also give more responsiveness to Ctrl-C. It is possible that you have fast and slow RAM, or that your video card uses shared memory which slows down some parts of memory which are not used anymore with those parameters. I did test some SATA drives, am getting these value for 2.6.20-rc5:- [EMAIL PROTECTED] ~]$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 21.0962 seconds, 50.9 MB/s What can you suggest here w.r.t my RAM & disk? Willy Thanks, ~Akula2 - 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/ Hi, whitebook vbi s96f core 2 duo t5600 2gb hitachi ATA HTS721060G9AT00 using libata time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 10.0092 seconds, 107 MB/s real0m10.196s user0m0.004s sys 0m3.440s You have too much RAM, it's possible that writes did not complete before the end of your measurement. Try this instead : $ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 | sync Willy Yeah that make a difference: time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 | sync 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 8.86719 seconds, 121 MB/s real0m43.601s user0m0.004s sys 0m3.912s -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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: Abysmal disk performance, how to debug?
Sunil Naidu wrote: On 1/20/07, Willy Tarreau <[EMAIL PROTECTED]> wrote: It is not expected to increase write performance, but it should help you do something else during that time, or also give more responsiveness to Ctrl-C. It is possible that you have fast and slow RAM, or that your video card uses shared memory which slows down some parts of memory which are not used anymore with those parameters. I did test some SATA drives, am getting these value for 2.6.20-rc5:- [EMAIL PROTECTED] ~]$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 21.0962 seconds, 50.9 MB/s What can you suggest here w.r.t my RAM & disk? Willy Thanks, ~Akula2 - 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/ Hi, whitebook vbi s96f core 2 duo t5600 2gb hitachi ATA HTS721060G9AT00 using libata time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 10.0092 seconds, 107 MB/s real0m10.196s user0m0.004s sys 0m3.440s -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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/
