drm/radeon: take the mode_config mutex when dealing with hpds (v2) crashes
Dear Alex,
on my old P4 based non-SMP router your patch (commit
32d12fc20e3c726ca858d0e5055fb596fce2f8bc in linux stable) crashes on
Linux 4.1.4 and above. I was only able to take a picture of the whole
trace https://ferdi.naasa.net/url/jplatte/IMG_3116.JPG
Reverting the patch resolves the issue.
This is my old graphics hardware:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] RV100 [Radeon 7000 / Radeon VE]
Just for the reference, here is the full patch:
commit 32d12fc20e3c726ca858d0e5055fb596fce2f8bc
Author: Alex Deucher
Date: Fri May 15 11:48:52 2015 -0400
drm/radeon: take the mode_config mutex when dealing with hpds (v2)
commit 39fa10f7e21574a70cecf1fed0f9b36535aa68a0 upstream.
Since we are messing with state in the worker.
v2: drop the changes in the mst worker
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 7162c93..f682e53 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -79,10 +79,12 @@ static void radeon_hotplug_work_func(struct
work_struct *work)
struct drm_mode_config *mode_config = >mode_config;
struct drm_connector *connector;
+ mutex_lock(_config->mutex);
if (mode_config->num_connector) {
list_for_each_entry(connector,
_config->connector_list, head)
radeon_connector_hotplug(connector);
}
+ mutex_unlock(_config->mutex);
/* Just fire off a uevent and let userspace tell us what to do */
drm_helper_hpd_irq_event(dev);
}
Is it possible that the mutex is not defined on non-SMP systems? Can you
help to resolve this regression?
Best regards,
Joerg
--
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/
drm/radeon: take the mode_config mutex when dealing with hpds (v2) crashes
Dear Alex,
on my old P4 based non-SMP router your patch (commit
32d12fc20e3c726ca858d0e5055fb596fce2f8bc in linux stable) crashes on
Linux 4.1.4 and above. I was only able to take a picture of the whole
trace https://ferdi.naasa.net/url/jplatte/IMG_3116.JPG
Reverting the patch resolves the issue.
This is my old graphics hardware:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] RV100 [Radeon 7000 / Radeon VE]
Just for the reference, here is the full patch:
commit 32d12fc20e3c726ca858d0e5055fb596fce2f8bc
Author: Alex Deucher alexander.deuc...@amd.com
Date: Fri May 15 11:48:52 2015 -0400
drm/radeon: take the mode_config mutex when dealing with hpds (v2)
commit 39fa10f7e21574a70cecf1fed0f9b36535aa68a0 upstream.
Since we are messing with state in the worker.
v2: drop the changes in the mst worker
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 7162c93..f682e53 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -79,10 +79,12 @@ static void radeon_hotplug_work_func(struct
work_struct *work)
struct drm_mode_config *mode_config = dev-mode_config;
struct drm_connector *connector;
+ mutex_lock(mode_config-mutex);
if (mode_config-num_connector) {
list_for_each_entry(connector,
mode_config-connector_list, head)
radeon_connector_hotplug(connector);
}
+ mutex_unlock(mode_config-mutex);
/* Just fire off a uevent and let userspace tell us what to do */
drm_helper_hpd_irq_event(dev);
}
Is it possible that the mutex is not defined on non-SMP systems? Can you
help to resolve this regression?
Best regards,
Joerg
--
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/
Re: Linux 3.11-rc2 (acpi backlight, revert)
On 25.07.2013 21:47, Rafael J. Wysocki wrote: Other people who experienced problems with backlight in 3.11-rc2, please let me know whether or not the revert works for you too if you can. Before reverting the patch /sys/class/backlight was empty and backlight brightness was set to max, now it again contains a link to acpi_video0 on my Thinkpad 420s with intel video and adjusting the backlight works again. Joerg -- 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/
Re: Linux 3.11-rc2 (acpi backlight, revert)
On 25.07.2013 21:47, Rafael J. Wysocki wrote: Other people who experienced problems with backlight in 3.11-rc2, please let me know whether or not the revert works for you too if you can. Before reverting the patch /sys/class/backlight was empty and backlight brightness was set to max, now it again contains a link to acpi_video0 on my Thinkpad 420s with intel video and adjusting the backlight works again. Joerg -- 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/
Re: [PATCH - BUGFIX] Smack: Check for 'struct socket' with NULL sk
Am Dienstag, 12. Februar 2008 schrieb Ahmed S. Darwish: > Hi Joerg, > > There's a small problem with smack and NFS. A similar report was also > sent here: http://lkml.org/lkml/2007/10/27/85 > > Could you please check below patch ? I think it should fix your problem. Hi Ahmed, your patch fixes the nfs problem! Thank you! regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- 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 - BUGFIX] Smack: Check for 'struct socket' with NULL sk
Am Dienstag, 12. Februar 2008 schrieb Ahmed S. Darwish: Hi Joerg, There's a small problem with smack and NFS. A similar report was also sent here: http://lkml.org/lkml/2007/10/27/85 Could you please check below patch ? I think it should fix your problem. Hi Ahmed, your patch fixes the nfs problem! Thank you! regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- 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: BUG with 2.6.25-rc1 and smack
Am Montag, 11. Februar 2008 schrieb Casey Schaufler: > First analysis is that I've got an issue with kernel sockets. > If you can turn off NFS for the time being (I know that may not > be a helpful suggestion) you should be able to move forward. > Thank you for the trace, I hope to have the fix in short order. Thank you for your quick reply. Just tell me if you need more information. regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG with 2.6.25-rc1 and smack
Hi, when booting linux 2.6.25-rc1 I get the following error: BUG: unable to handle kernel NULL pointer dereference at 0138 IP: [] smack_netlabel+0x13/0xc8 *pde = Oops: [#1] PREEMPT Modules linked in: nfsd auth_rpcgss exportfs af_packet autofs4 ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 xt_state ipt_REJECT ipt_LOG xt_limit xt_mark xt_tcpudp xt_mac iptable_filter xt_ MARK xt_multiport iptable_mangle ip_tables x_tables nf_conntrack_ftp nf_conntrack cpufreq_userspace cpufreq_stats cpufreq_powersave nfs lockd nfs_acl sunrpc deflate zlib_deflate zlib_inflate ctr twofish twofish_common camellia serpent blowfish des_generic cbc aes_i586 aes_generic xcbc sha256_generic sha1_generic md5 crypto_null hmac crypto_hash af_key nls_utf8 ntfs nls_base ext2 fuse ebt able_broute bridge llc ebtable_nat ebtable_filter ebtables deadline_iosched as_iosched ircomm_tty ircomm tun acpi_cpufreq video output sbs sbshc joydev arc4 ecb crypto_blkcipher cryptomgr crypto_ algapi snd_intel8x0m irtty_sir sir_dev snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_pcm snd_mixer_oss nsc_ircc irda crc_ccitt parport_pc snd_seq_oss parport 8250_pnp snd_seq_midi snd_rawm idi snd_seq_midi_event snd_seq serio_raw snd_timer snd_seq_device psmouse ath5k snd mac80211 pcspkr 8250_pci yenta_socket rsrc_nonstatic cinergyT2 8250 cfg80211 pcmcia firmware_class dvb_core ser ial_core soundcore snd_page_alloc pcmcia_core i2c_i801 rng_core iTCO_wdt iTCO_vendor_support battery ac button intel_agp agpgart thinkpad_acpi hwmon evdev nvram ext3 jbd mbcache sg usbhid hid ff_ memless sr_mod cdrom sd_mod ata_generic pata_acpi floppy ata_piix e1000 libata scsi_mod ehci_hcd uhci_hcd usbcore thermal processor fan unix cpufreq_conservative cpufreq_ondemand freq_table bay d ock fbcon tileblit font bitblit softcursor radeonfb fb fb_ddc backlight i2c_algo_bit cfbcopyarea i2c_core cfbimgblt cfbfillrect Pid: 5307, comm: nfsd Not tainted (2.6.25-rc1 #1) EIP: 0060:[] EFLAGS: 00010286 CPU: 0 EIP is at smack_netlabel+0x13/0xc8 EAX: EBX: f682edf4 ECX: 0006 EDX: 0002 ESI: EDI: 0001 EBP: f682ee18 ESP: f682edd8 DS: 007b ES: 007b FS: GS: SS: 0068 Process nfsd (pid: 5307, ti=f682e000 task=f7f54e50 task.ti=f682e000) Stack: 0040 f732e1a4 c0331998 f732e290 f682edf8 c01aacf8 f732e1a4 f7468400 f682ee04 c01aad52 f732e1a4 f682ee0c c01a7510 c0331668 f732e180 0001 f682ee20 c01aa665 f682ee34 c01a7a06 0006 0001 fff4 f682ee58 Call Trace: [] ? new_inode_smack+0x39/0x3f [] ? smack_inode_alloc_security+0x16/0x27 [] ? security_inode_alloc+0x19/0x1b [] ? smack_socket_post_create+0x12/0x18 [] ? security_socket_post_create+0x16/0x1b [] ? sock_create_lite+0x44/0x64 [] ? kernel_accept+0x24/0x5f [] ? svc_tcp_accept+0x51/0x526 [sunrpc] [] ? getnstimeofday+0x2f/0xb4 [] ? ktime_get_ts+0x3b/0x3f [] ? hrtick_start_fair+0xcb/0x107 [] ? lock_sock_nested+0xab/0xb3 [] ? kernel_recvmsg+0x2b/0x3d [] ? svc_xprt_received+0x1e/0x20 [sunrpc] [] ? svc_udp_recvfrom+0xd3/0x2ed [sunrpc] [] ? enqueue_task_fair+0x41/0x4c [] ? svc_xprt_put+0x10/0x12 [sunrpc] [] ? svc_xprt_release+0x92/0x9a [sunrpc] [] ? svc_recv+0x335/0x665 [sunrpc] [] ? default_wake_function+0x0/0xd [] ? nfsd+0xd5/0x28e [nfsd] [] ? nfsd+0x0/0x28e [nfsd] [] ? kernel_thread_helper+0x7/0x10 === Code: 5d f0 74 0d 46 8b 5d f0 c6 45 ef 80 83 eb 08 eb c6 59 5b 5b 5e 5f 5d c3 55 b9 06 00 00 00 89 e5 57 56 89 c6 53 83 ec 34 8d 5d dc <8b> 90 38 01 00 00 31 c0 89 df f3 ab 83 3d f4 19 33 c0 03 8 b 3a EIP: [] smack_netlabel+0x13/0xc8 SS:ESP 0068:f682edd8 ---[ end trace 499ec328c921ccf2 ]--- regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- 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: BUG with 2.6.25-rc1 and smack
Am Montag, 11. Februar 2008 schrieb Casey Schaufler: First analysis is that I've got an issue with kernel sockets. If you can turn off NFS for the time being (I know that may not be a helpful suggestion) you should be able to move forward. Thank you for the trace, I hope to have the fix in short order. Thank you for your quick reply. Just tell me if you need more information. regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG with 2.6.25-rc1 and smack
Hi, when booting linux 2.6.25-rc1 I get the following error: BUG: unable to handle kernel NULL pointer dereference at 0138 IP: [c01aa59e] smack_netlabel+0x13/0xc8 *pde = Oops: [#1] PREEMPT Modules linked in: nfsd auth_rpcgss exportfs af_packet autofs4 ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 xt_state ipt_REJECT ipt_LOG xt_limit xt_mark xt_tcpudp xt_mac iptable_filter xt_ MARK xt_multiport iptable_mangle ip_tables x_tables nf_conntrack_ftp nf_conntrack cpufreq_userspace cpufreq_stats cpufreq_powersave nfs lockd nfs_acl sunrpc deflate zlib_deflate zlib_inflate ctr twofish twofish_common camellia serpent blowfish des_generic cbc aes_i586 aes_generic xcbc sha256_generic sha1_generic md5 crypto_null hmac crypto_hash af_key nls_utf8 ntfs nls_base ext2 fuse ebt able_broute bridge llc ebtable_nat ebtable_filter ebtables deadline_iosched as_iosched ircomm_tty ircomm tun acpi_cpufreq video output sbs sbshc joydev arc4 ecb crypto_blkcipher cryptomgr crypto_ algapi snd_intel8x0m irtty_sir sir_dev snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_pcm snd_mixer_oss nsc_ircc irda crc_ccitt parport_pc snd_seq_oss parport 8250_pnp snd_seq_midi snd_rawm idi snd_seq_midi_event snd_seq serio_raw snd_timer snd_seq_device psmouse ath5k snd mac80211 pcspkr 8250_pci yenta_socket rsrc_nonstatic cinergyT2 8250 cfg80211 pcmcia firmware_class dvb_core ser ial_core soundcore snd_page_alloc pcmcia_core i2c_i801 rng_core iTCO_wdt iTCO_vendor_support battery ac button intel_agp agpgart thinkpad_acpi hwmon evdev nvram ext3 jbd mbcache sg usbhid hid ff_ memless sr_mod cdrom sd_mod ata_generic pata_acpi floppy ata_piix e1000 libata scsi_mod ehci_hcd uhci_hcd usbcore thermal processor fan unix cpufreq_conservative cpufreq_ondemand freq_table bay d ock fbcon tileblit font bitblit softcursor radeonfb fb fb_ddc backlight i2c_algo_bit cfbcopyarea i2c_core cfbimgblt cfbfillrect Pid: 5307, comm: nfsd Not tainted (2.6.25-rc1 #1) EIP: 0060:[c01aa59e] EFLAGS: 00010286 CPU: 0 EIP is at smack_netlabel+0x13/0xc8 EAX: EBX: f682edf4 ECX: 0006 EDX: 0002 ESI: EDI: 0001 EBP: f682ee18 ESP: f682edd8 DS: 007b ES: 007b FS: GS: SS: 0068 Process nfsd (pid: 5307, ti=f682e000 task=f7f54e50 task.ti=f682e000) Stack: 0040 f732e1a4 c0331998 f732e290 f682edf8 c01aacf8 f732e1a4 f7468400 f682ee04 c01aad52 f732e1a4 f682ee0c c01a7510 c0331668 f732e180 0001 f682ee20 c01aa665 f682ee34 c01a7a06 0006 0001 fff4 f682ee58 Call Trace: [c01aacf8] ? new_inode_smack+0x39/0x3f [c01aad52] ? smack_inode_alloc_security+0x16/0x27 [c01a7510] ? security_inode_alloc+0x19/0x1b [c01aa665] ? smack_socket_post_create+0x12/0x18 [c01a7a06] ? security_socket_post_create+0x16/0x1b [c02116ce] ? sock_create_lite+0x44/0x64 [c0211712] ? kernel_accept+0x24/0x5f [f9f77ef3] ? svc_tcp_accept+0x51/0x526 [sunrpc] [c012f200] ? getnstimeofday+0x2f/0xb4 [c012db9e] ? ktime_get_ts+0x3b/0x3f [c011508c] ? hrtick_start_fair+0xcb/0x107 [c0212730] ? lock_sock_nested+0xab/0xb3 [c0211e5f] ? kernel_recvmsg+0x2b/0x3d [f9f7dcf0] ? svc_xprt_received+0x1e/0x20 [sunrpc] [f9f77c88] ? svc_udp_recvfrom+0xd3/0x2ed [sunrpc] [c01153da] ? enqueue_task_fair+0x41/0x4c [f9f7dd02] ? svc_xprt_put+0x10/0x12 [sunrpc] [f9f7de5b] ? svc_xprt_release+0x92/0x9a [sunrpc] [f9f7ed20] ? svc_recv+0x335/0x665 [sunrpc] [c01172d6] ? default_wake_function+0x0/0xd [fa0676b3] ? nfsd+0xd5/0x28e [nfsd] [fa0675de] ? nfsd+0x0/0x28e [nfsd] [c01054a7] ? kernel_thread_helper+0x7/0x10 === Code: 5d f0 74 0d 46 8b 5d f0 c6 45 ef 80 83 eb 08 eb c6 59 5b 5b 5e 5f 5d c3 55 b9 06 00 00 00 89 e5 57 56 89 c6 53 83 ec 34 8d 5d dc 8b 90 38 01 00 00 31 c0 89 df f3 ab 83 3d f4 19 33 c0 03 8 b 3a EIP: [c01aa59e] smack_netlabel+0x13/0xc8 SS:ESP 0068:f682edd8 ---[ end trace 499ec328c921ccf2 ]--- regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- 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: regression: 100% io-wait with 2.6.24-rcX
Am Montag, 14. Januar 2008 schrieb Fengguang Wu: > Joerg, this patch fixed the bug for me :-) Fengguang, congratulations, I can confirm that your patch fixed the bug! With previous kernels the bug showed up after each reboot. Now, when booting the patched kernel everything is fine and there is no longer any suspicious iowait! Do you have an idea why this problem appeared in 2.6.24? Did somebody change the ext2 code or is it related to the changes in the scheduler? regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- 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: regression: 100% io-wait with 2.6.24-rcX
Am Montag, 14. Januar 2008 schrieb Fengguang Wu: Joerg, this patch fixed the bug for me :-) Fengguang, congratulations, I can confirm that your patch fixed the bug! With previous kernels the bug showed up after each reboot. Now, when booting the patched kernel everything is fine and there is no longer any suspicious iowait! Do you have an idea why this problem appeared in 2.6.24? Did somebody change the ext2 code or is it related to the changes in the scheduler? regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- 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: regression: 100% io-wait with 2.6.24-rcX
Am Sonntag, 13. Januar 2008 schrieb Fengguang Wu: > On Sun, Jan 13, 2008 at 09:05:43AM +0100, Joerg Platte wrote: > > Am Sonntag, 13. Januar 2008 schrieb Fengguang Wu: > > > No idea yet :-/ I'm afraid I have to trouble you again - the bug just > > > refused to appear in my system. I prepared a kernel module for you to > > > gather more information: > > > > > > make && insmod ext2-writeback-debug.ko && sleep 1s && rmmod > > > ext2-writeback-debug dmesg > ext2-writeback-debug.dmesg > > > > Unfortunately, I unable to compile the module: > > > > make -C /lib/modules/2.6.24-rc7-ext2/build SUBDIRS=/export/src modules > > make[1]: Entering directory `/export/src/linux-2.6.24-rc7' > > CC [M] /export/src/ext2-writeback-debug.o > > /export/src/ext2-writeback-debug.c:89: error: variable ‘my_kprobe’ has > > initializer but incomplete type > > Do you have CONFIG_KPROBES=y? Now I have :) Here is the result. regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 Linux version 2.6.24-rc7-ext2 ([EMAIL PROTECTED]) (gcc version 4.2.3 20080102 (prerelease) (Debian 4.2.2-5)) #1 PREEMPT Sun Jan 13 09:48:55 CET 2008 BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000d2000 - 000d4000 (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 5ff5 (usable) BIOS-e820: 5ff5 - 5ff67000 (ACPI data) BIOS-e820: 5ff67000 - 5ff79000 (ACPI NVS) BIOS-e820: 5ff8 - 6000 (reserved) BIOS-e820: ff80 - 0001 (reserved) 639MB HIGHMEM available. 896MB LOWMEM available. Entering add_active_range(0, 0, 393040) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 HighMem229376 -> 393040 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -> 393040 On node 0 totalpages: 393040 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 HighMem zone: 1278 pages used for memmap HighMem zone: 162386 pages, LIFO batch:31 Movable zone: 0 pages used for memmap DMI present. ACPI: RSDP 000F6D70, 0024 (r2 IBM ) ACPI: XSDT 5FF5A672, 004C (r1 IBMTP-1R3230 LTP0) ACPI: FACP 5FF5A700, 00F4 (r3 IBMTP-1R3230 IBM 1) ACPI Warning (tbfadt-0442): Optional field "Gpe1Block" has zero address or length: 102C/0 [20070126] ACPI: DSDT 5FF5A8E7, C530 (r1 IBMTP-1R3230 MSFT 10E) ACPI: FACS 5FF78000, 0040 ACPI: SSDT 5FF5A8B4, 0033 (r1 IBMTP-1R3230 MSFT 10E) ACPI: ECDT 5FF66E17, 0052 (r1 IBMTP-1R3230 IBM 1) ACPI: TCPA 5FF66E69, 0032 (r1 IBMTP-1R3230 PTL 1) ACPI: BOOT 5FF66FD8, 0028 (r1 IBMTP-1R3230 LTP1) ACPI: PM-Timer IO Port: 0x1008 Allocating PCI resources starting at 7000 (gap: 6000:9f80) swsusp: Registered nosave memory region: 0009f000 - 000a swsusp: Registered nosave memory region: 000a - 000d2000 swsusp: Registered nosave memory region: 000d2000 - 000d4000 swsusp: Registered nosave memory region: 000d4000 - 000dc000 swsusp: Registered nosave memory region: 000dc000 - 0010 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 389970 Kernel command line: root=LABEL=ROOT ro resume=LABEL=SWAP panic=10 usbcore.autosuspend=1 hpet=force Unknown boot option `usbcore.autosuspend=1': ignoring Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to b000 (01c06000) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c0343000 soft=c0342000 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 1598.683 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1547564k/1572160k available (1494k kernel code, 23352k reserved, 597k data, 204k init, 654656k highmem) virtual kernel memory layout: fixmap : 0xfffa8000 - 0xf000 ( 348 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xf880 - 0xff7fe000 ( 111 MB) lowmem : 0xc000 - 0xf800 ( 896 MB) .init : 0xc030c000 - 0xc033f000 ( 204 kB) .data : 0xc0275a5f - 0xc030aef0 ( 597 kB) .text : 0xc010
Re: regression: 100% io-wait with 2.6.24-rcX
Am Sonntag, 13. Januar 2008 schrieb Fengguang Wu: > No idea yet :-/ I'm afraid I have to trouble you again - the bug just > refused to appear in my system. I prepared a kernel module for you to > gather more information: > make && insmod ext2-writeback-debug.ko && sleep 1s && rmmod > ext2-writeback-debug dmesg > ext2-writeback-debug.dmesg Unfortunately, I unable to compile the module: make -C /lib/modules/2.6.24-rc7-ext2/build SUBDIRS=/export/src modules make[1]: Entering directory `/export/src/linux-2.6.24-rc7' CC [M] /export/src/ext2-writeback-debug.o /export/src/ext2-writeback-debug.c:89: error: variable ‘my_kprobe’ has initializer but incomplete type /export/src/ext2-writeback-debug.c:90: error: unknown field ‘pre_handler’ specified in initializer /export/src/ext2-writeback-debug.c:90: warning: excess elements in struct initializer /export/src/ext2-writeback-debug.c:90: warning: (near initialization for ‘my_kprobe’) /export/src/ext2-writeback-debug.c:91: error: unknown field ‘post_handler’ specified in initializer /export/src/ext2-writeback-debug.c:91: warning: excess elements in struct initializer /export/src/ext2-writeback-debug.c:91: warning: (near initialization for ‘my_kprobe’) /export/src/ext2-writeback-debug.c:92: error: unknown field ‘symbol_name’ specified in initializer /export/src/ext2-writeback-debug.c:93: warning: excess elements in struct initializer /export/src/ext2-writeback-debug.c:93: warning: (near initialization for ‘my_kprobe’) /export/src/ext2-writeback-debug.c:109: error: variable ‘jprobe_ext2_writepage’ has initializer but incomplete type /export/src/ext2-writeback-debug.c:110: error: unknown field ‘entry’ specified in initializer /export/src/ext2-writeback-debug.c:110: warning: excess elements in struct initializer /export/src/ext2-writeback-debug.c:110: warning: (near initialization for ‘jprobe_ext2_writepage’) /export/src/ext2-writeback-debug.c:111: error: unknown field ‘kp’ specified in initializer /export/src/ext2-writeback-debug.c:112: warning: excess elements in struct initializer /export/src/ext2-writeback-debug.c:112: warning: (near initialization for ‘jprobe_ext2_writepage’) /export/src/ext2-writeback-debug.c:124: error: variable ‘jprobe_requeue_io’ has initializer but incomplete type /export/src/ext2-writeback-debug.c:125: error: unknown field ‘entry’ specified in initializer /export/src/ext2-writeback-debug.c:125: warning: excess elements in struct initializer /export/src/ext2-writeback-debug.c:125: warning: (near initialization for ‘jprobe_requeue_io’) /export/src/ext2-writeback-debug.c:126: error: unknown field ‘kp’ specified in initializer /export/src/ext2-writeback-debug.c:127: warning: excess elements in struct initializer /export/src/ext2-writeback-debug.c:127: warning: (near initialization for ‘jprobe_requeue_io’) /export/src/ext2-writeback-debug.c: In function ‘setup_kprobe’: /export/src/ext2-writeback-debug.c:132: error: dereferencing pointer to incomplete type /export/src/ext2-writeback-debug.c: In function ‘setup_jprobe’: /export/src/ext2-writeback-debug.c:139: error: dereferencing pointer to incomplete type make[2]: *** [/export/src/ext2-writeback-debug.o] Error 1 make[1]: *** [_module_/export/src] Error 2 make[1]: Leaving directory `/export/src/linux-2.6.24-rc7' make: *** [default] Error 2 regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- 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: regression: 100% io-wait with 2.6.24-rcX
Am Sonntag, 13. Januar 2008 schrieb Fengguang Wu: No idea yet :-/ I'm afraid I have to trouble you again - the bug just refused to appear in my system. I prepared a kernel module for you to gather more information: make insmod ext2-writeback-debug.ko sleep 1s rmmod ext2-writeback-debug dmesg ext2-writeback-debug.dmesg Unfortunately, I unable to compile the module: make -C /lib/modules/2.6.24-rc7-ext2/build SUBDIRS=/export/src modules make[1]: Entering directory `/export/src/linux-2.6.24-rc7' CC [M] /export/src/ext2-writeback-debug.o /export/src/ext2-writeback-debug.c:89: error: variable ‘my_kprobe’ has initializer but incomplete type /export/src/ext2-writeback-debug.c:90: error: unknown field ‘pre_handler’ specified in initializer /export/src/ext2-writeback-debug.c:90: warning: excess elements in struct initializer /export/src/ext2-writeback-debug.c:90: warning: (near initialization for ‘my_kprobe’) /export/src/ext2-writeback-debug.c:91: error: unknown field ‘post_handler’ specified in initializer /export/src/ext2-writeback-debug.c:91: warning: excess elements in struct initializer /export/src/ext2-writeback-debug.c:91: warning: (near initialization for ‘my_kprobe’) /export/src/ext2-writeback-debug.c:92: error: unknown field ‘symbol_name’ specified in initializer /export/src/ext2-writeback-debug.c:93: warning: excess elements in struct initializer /export/src/ext2-writeback-debug.c:93: warning: (near initialization for ‘my_kprobe’) /export/src/ext2-writeback-debug.c:109: error: variable ‘jprobe_ext2_writepage’ has initializer but incomplete type /export/src/ext2-writeback-debug.c:110: error: unknown field ‘entry’ specified in initializer /export/src/ext2-writeback-debug.c:110: warning: excess elements in struct initializer /export/src/ext2-writeback-debug.c:110: warning: (near initialization for ‘jprobe_ext2_writepage’) /export/src/ext2-writeback-debug.c:111: error: unknown field ‘kp’ specified in initializer /export/src/ext2-writeback-debug.c:112: warning: excess elements in struct initializer /export/src/ext2-writeback-debug.c:112: warning: (near initialization for ‘jprobe_ext2_writepage’) /export/src/ext2-writeback-debug.c:124: error: variable ‘jprobe_requeue_io’ has initializer but incomplete type /export/src/ext2-writeback-debug.c:125: error: unknown field ‘entry’ specified in initializer /export/src/ext2-writeback-debug.c:125: warning: excess elements in struct initializer /export/src/ext2-writeback-debug.c:125: warning: (near initialization for ‘jprobe_requeue_io’) /export/src/ext2-writeback-debug.c:126: error: unknown field ‘kp’ specified in initializer /export/src/ext2-writeback-debug.c:127: warning: excess elements in struct initializer /export/src/ext2-writeback-debug.c:127: warning: (near initialization for ‘jprobe_requeue_io’) /export/src/ext2-writeback-debug.c: In function ‘setup_kprobe’: /export/src/ext2-writeback-debug.c:132: error: dereferencing pointer to incomplete type /export/src/ext2-writeback-debug.c: In function ‘setup_jprobe’: /export/src/ext2-writeback-debug.c:139: error: dereferencing pointer to incomplete type make[2]: *** [/export/src/ext2-writeback-debug.o] Error 1 make[1]: *** [_module_/export/src] Error 2 make[1]: Leaving directory `/export/src/linux-2.6.24-rc7' make: *** [default] Error 2 regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- 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: regression: 100% io-wait with 2.6.24-rcX
Am Sonntag, 13. Januar 2008 schrieb Fengguang Wu: On Sun, Jan 13, 2008 at 09:05:43AM +0100, Joerg Platte wrote: Am Sonntag, 13. Januar 2008 schrieb Fengguang Wu: No idea yet :-/ I'm afraid I have to trouble you again - the bug just refused to appear in my system. I prepared a kernel module for you to gather more information: make insmod ext2-writeback-debug.ko sleep 1s rmmod ext2-writeback-debug dmesg ext2-writeback-debug.dmesg Unfortunately, I unable to compile the module: make -C /lib/modules/2.6.24-rc7-ext2/build SUBDIRS=/export/src modules make[1]: Entering directory `/export/src/linux-2.6.24-rc7' CC [M] /export/src/ext2-writeback-debug.o /export/src/ext2-writeback-debug.c:89: error: variable ‘my_kprobe’ has initializer but incomplete type Do you have CONFIG_KPROBES=y? Now I have :) Here is the result. regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 Linux version 2.6.24-rc7-ext2 ([EMAIL PROTECTED]) (gcc version 4.2.3 20080102 (prerelease) (Debian 4.2.2-5)) #1 PREEMPT Sun Jan 13 09:48:55 CET 2008 BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000d2000 - 000d4000 (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 5ff5 (usable) BIOS-e820: 5ff5 - 5ff67000 (ACPI data) BIOS-e820: 5ff67000 - 5ff79000 (ACPI NVS) BIOS-e820: 5ff8 - 6000 (reserved) BIOS-e820: ff80 - 0001 (reserved) 639MB HIGHMEM available. 896MB LOWMEM available. Entering add_active_range(0, 0, 393040) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 229376 HighMem229376 - 393040 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 - 393040 On node 0 totalpages: 393040 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 HighMem zone: 1278 pages used for memmap HighMem zone: 162386 pages, LIFO batch:31 Movable zone: 0 pages used for memmap DMI present. ACPI: RSDP 000F6D70, 0024 (r2 IBM ) ACPI: XSDT 5FF5A672, 004C (r1 IBMTP-1R3230 LTP0) ACPI: FACP 5FF5A700, 00F4 (r3 IBMTP-1R3230 IBM 1) ACPI Warning (tbfadt-0442): Optional field Gpe1Block has zero address or length: 102C/0 [20070126] ACPI: DSDT 5FF5A8E7, C530 (r1 IBMTP-1R3230 MSFT 10E) ACPI: FACS 5FF78000, 0040 ACPI: SSDT 5FF5A8B4, 0033 (r1 IBMTP-1R3230 MSFT 10E) ACPI: ECDT 5FF66E17, 0052 (r1 IBMTP-1R3230 IBM 1) ACPI: TCPA 5FF66E69, 0032 (r1 IBMTP-1R3230 PTL 1) ACPI: BOOT 5FF66FD8, 0028 (r1 IBMTP-1R3230 LTP1) ACPI: PM-Timer IO Port: 0x1008 Allocating PCI resources starting at 7000 (gap: 6000:9f80) swsusp: Registered nosave memory region: 0009f000 - 000a swsusp: Registered nosave memory region: 000a - 000d2000 swsusp: Registered nosave memory region: 000d2000 - 000d4000 swsusp: Registered nosave memory region: 000d4000 - 000dc000 swsusp: Registered nosave memory region: 000dc000 - 0010 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 389970 Kernel command line: root=LABEL=ROOT ro resume=LABEL=SWAP panic=10 usbcore.autosuspend=1 hpet=force Unknown boot option `usbcore.autosuspend=1': ignoring Local APIC disabled by BIOS -- you can enable it with lapic mapped APIC to b000 (01c06000) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c0343000 soft=c0342000 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 1598.683 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1547564k/1572160k available (1494k kernel code, 23352k reserved, 597k data, 204k init, 654656k highmem) virtual kernel memory layout: fixmap : 0xfffa8000 - 0xf000 ( 348 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xf880 - 0xff7fe000 ( 111 MB) lowmem : 0xc000 - 0xf800 ( 896 MB) .init : 0xc030c000 - 0xc033f000 ( 204 kB) .data : 0xc0275a5f - 0xc030aef0 ( 597 kB) .text : 0xc010 - 0xc0275a5f (1494 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. SLUB: Genslabs=11, HWalign=64, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Calibrating delay using timer specific routine
Re: regression: 100% io-wait with 2.6.24-rcX
Am Freitag, 11. Januar 2008 schrieb Fengguang Wu:
> On Thu, Jan 10, 2008 at 11:03:05AM +0100, Joerg Platte wrote:
> > Am Donnerstag, 10. Januar 2008 schrieb Fengguang Wu:
> > > > problem, because the iowait problem disappeared today after the
> > > > regular Debian update. I'll try to install the old package versions
> > > > to make it show up again. Maybe that helps to debug it.
> > >
> > > Thank you. I'm running sid, ext2 as rootfs now ;-)
> >
> > The error is back and I'm getting thousands of messages like this with
> > the patched kernel:
> >
> > mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3936 0 0 wc
> > _M > tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7)
> > mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3936 0 0 wc
> > _M > tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7)
> > mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3936 0 0 wc
> > _M > tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7)
>
> Joerg, what's the output of `dumpe2fs /dev/sda7` and `lsof|grep /tmp`?
After another reboot I tried to get more information about the konqueror
process possibly causing the iowait load by using strace -p. Here is the
output:
gettimeofday({1200180588, 878508}, NULL) = 0
setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
rt_sigaction(SIGVTALRM, {SIG_DFL}, {0xb5cffed0, [VTALRM], SA_RESTART}, 8) = 0
gettimeofday({1200180588, 879942}, NULL) = 0
time(NULL) = 1200180588
gettimeofday({1200180588, 880838}, NULL) = 0
gettimeofday({1200180588, 881284}, NULL) = 0
time(NULL) = 1200180588
gettimeofday({1200180588, 882131}, NULL) = 0
gettimeofday({1200180588, 882572}, NULL) = 0
ioctl(5, FIONREAD, [0]) = 0
gettimeofday({1200180588, 883477}, NULL) = 0
select(16, [5 6 7 9 11 14 15], [], [], {0, 150095}) = 0 (Timeout)
gettimeofday({1200180589, 34269}, NULL) = 0
gettimeofday({1200180589, 34885}, NULL) = 0
time(NULL) = 1200180589
gettimeofday({1200180589, 36672}, NULL) = 0
rt_sigaction(SIGVTALRM, {0xb5cffed0, [VTALRM], SA_RESTART}, {SIG_DFL}, 8) = 0
setitimer(ITIMER_VIRTUAL, {it_interval={10, 0}, it_value={5, 0}},
{it_interval={0, 0}, it_value={0, 0}}) = 0
gettimeofday({1200180589, 38555}, NULL) = 0
time(NULL) = 1200180589
gettimeofday({1200180589, 39802}, NULL) = 0
setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
rt_sigaction(SIGVTALRM, {SIG_DFL}, {0xb5cffed0, [VTALRM], SA_RESTART}, 8) = 0
gettimeofday({1200180589, 40912}, NULL) = 0
time(NULL) = 1200180589
gettimeofday({1200180589, 42019}, NULL) = 0
gettimeofday({1200180589, 42458}, NULL) = 0
time(NULL) = 1200180589
gettimeofday({1200180589, 43303}, NULL) = 0
gettimeofday({1200180589, 43747}, NULL) = 0
ioctl(5, FIONREAD, [0]) = 0
gettimeofday({1200180589, 45834}, NULL) = 0
select(16, [5 6 7 9 11 14 15], [], [], {0, 149913}) = 0 (Timeout)
gettimeofday({1200180589, 194815}, NULL) = 0
ioctl(5, FIONREAD, [0]) = 0
gettimeofday({1200180589, 195730}, NULL) = 0
select(16, [5 6 7 9 11 14 15], [], [], {0, 17}) = 0 (Timeout)
gettimeofday({1200180589, 197555}, NULL) = 0
gettimeofday({1200180589, 198020}, NULL) = 0
time(NULL) = 1200180589
gettimeofday({1200180589, 198884}, NULL) = 0
rt_sigaction(SIGVTALRM, {0xb5cffed0, [VTALRM], SA_RESTART}, {SIG_DFL}, 8) = 0
setitimer(ITIMER_VIRTUAL, {it_interval={10, 0}, it_value={5, 0}},
{it_interval={0, 0}, it_value={0, 0}}) = 0
gettimeofday({1200180589, 200702}, NULL) = 0
time(NULL) = 1200180589
gettimeofday({1200180589, 200806}, NULL) = 0
setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
rt_sigaction(SIGVTALRM, {SIG_DFL}, {0xb5cffed0, [VTALRM], SA_RESTART}, 8) = 0
gettimeofday({1200180589, 202975}, NULL) = 0
time(NULL) = 1200180589
gettimeofday({1200180589, 203837}, NULL) = 0
gettimeofday({1200180589, 204319}, NULL) = 0
time(NULL) = 1200180589
gettimeofday({1200180589, 205169}, NULL) = 0
gettimeofday({1200180589, 205613}, NULL) = 0
ioctl(5, FIONREAD, [0]) = 0
gettimeofday({1200180589, 206515}, NULL) = 0
select(16, [5 6 7 9 11 14 15], [], [], {0, 149098}
Fengguang, do you have any idea what's going wrong here?
regards,
Jörg
--
PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D
PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605
--
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: regression: 100% io-wait with 2.6.24-rcX
Am Freitag, 11. Januar 2008 schrieb Joerg Platte: > konqueror 987jplatte mem REG8,6 2590525 > 1336104 /var/tmp/kdecache-jplatte/ksycoca > konqueror 987jplatte 12r REG8,6 2590525 > 1336104 /var/tmp/kdecache-jplatte/ksycoca > konqueror 987jplatte 13u REG8,7 579 > 97731 /tmp/kde-jplatte/konqueror-crash-Jv2u8a.log > konqueror 987jplatte 14u REG8,7 128289 > 97734 /tmp/kde-jplatte/khtmlcacheA7VjAa.tmp (deleted) > konqueror 987jplatte 16u REG8,743334 > 97750 /tmp/kde-jplatte/khtmlcacheZUNlsc.tmp (deleted) > konqueror 987jplatte 22u REG8,7 797 > 97751 /tmp/kde-jplatte/khtmlcache76bZYa.tmp (deleted) > konqueror 987jplatte 27u REG8,7 102347 > 97735 /tmp/kde-jplatte/khtmlcacheMhlDJb.tmp (deleted) > konqueror 987jplatte 31u REG8,7 354 > 97738 /tmp/kde-jplatte/khtmlcacheq21uoc.tmp (deleted) > konqueror 987jplatte 32u REG8,7 1360 > 97742 /tmp/kde-jplatte/khtmlcacheo2Ms2a.tmp (deleted) > konqueror 987jplatte 34u REG8,7 6378 > 97745 /tmp/kde-jplatte/khtmlcacheLETtgc.tmp (deleted) > konqueror 987jplatte 35u REG8,797350 > 97746 /tmp/kde-jplatte/khtmlcache5jit8a.tmp (deleted) > konqueror 987jplatte 36u REG8,7 354 > 97747 /tmp/kde-jplatte/khtmlcache7VBSNa.tmp (deleted) > konqueror 987jplatte 37u REG8,7 1360 > 97748 /tmp/kde-jplatte/khtmlcachetSNbub.tmp (deleted) > konqueror 987jplatte 38u REG8,7 6073 > 97749 /tmp/kde-jplatte/khtmlcacheKAKhuc.tmp (deleted) Fengguang, a few minutes after killing this konqueror process the high iowait load has disappeared. Lets see if it'll come back... regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- 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: regression: 100% io-wait with 2.6.24-rcX
Am Freitag, 11. Januar 2008 schrieb Fengguang Wu: > Joerg, what's the output of `dumpe2fs /dev/sda7` and `lsof|grep /tmp`? Fengang, here is the output (kernel 2.6.24-rc7 without your patches): Filesystem volume name: TMP Last mounted on: Filesystem UUID: e23ae961-bbdc-44bc-b662-f28f7314939b Filesystem magic number: 0xEF53 Filesystem revision #:1 (dynamic) Filesystem features: has_journal resize_inode dir_index filetype sparse_super large_file Filesystem flags: signed directory hash Default mount options:(none) Filesystem state: not clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 244320 Block count: 487966 Reserved block count: 24398 Free blocks: 468728 Free inodes: 244162 First block: 0 Block size: 4096 Fragment size:4096 Reserved GDT blocks: 119 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 16288 Inode blocks per group: 509 Filesystem created: Thu Feb 8 18:46:19 2007 Last mount time: Thu Jan 10 11:09:35 2008 Last write time: Fri Jan 11 06:12:58 2008 Mount count: 25 Maximum mount count: 39 Last checked: Tue Dec 11 22:07:03 2007 Check interval: 15552000 (6 months) Next check after: Sun Jun 8 23:07:03 2008 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Journal inode:8 Default directory hash: tea Directory Hash Seed: 79e271e9-b874-4e11-92b0-cdb36d07e1c1 Journal backup: inode blocks Journal size: 32M Group 0: (Blocks 0-32767) Primary superblock at 0, Group descriptors at 1-1 Reserved GDT blocks at 2-120 Block bitmap at 121 (+121), Inode bitmap at 122 (+122) Inode table at 123-631 (+123) 23926 free blocks, 16275 free inodes, 2 directories Free blocks: 638-10239, 16384, 18444-30719, 30721-32767 Free inodes: 14-16288 Group 1: (Blocks 32768-65535) Backup superblock at 32768, Group descriptors at 32769-32769 Reserved GDT blocks at 32770-32888 Block bitmap at 32889 (+121), Inode bitmap at 32890 (+122) Inode table at 32891-33399 (+123) 32135 free blocks, 16287 free inodes, 1 directories Free blocks: 33400-57343, 57345-65535 Free inodes: 16290-32576 Group 2: (Blocks 65536-98303) Block bitmap at 65536 (+0), Inode bitmap at 65537 (+1) Inode table at 65538-66046 (+2) 32256 free blocks, 16286 free inodes, 1 directories Free blocks: 66047-96255, 96257-98303 Free inodes: 32579-48864 Group 3: (Blocks 98304-131071) Backup superblock at 98304, Group descriptors at 98305-98305 Reserved GDT blocks at 98306-98424 Block bitmap at 98425 (+121), Inode bitmap at 98426 (+122) Inode table at 98427-98935 (+123) 32135 free blocks, 16286 free inodes, 1 directories Free blocks: 98936-120831, 120833-131071 Free inodes: 48867-65152 Group 4: (Blocks 131072-163839) Block bitmap at 131072 (+0), Inode bitmap at 131073 (+1) Inode table at 131074-131582 (+2) 32256 free blocks, 16287 free inodes, 1 directories Free blocks: 131583-133119, 133121-163839 Free inodes: 65154-81440 Group 5: (Blocks 163840-196607) Backup superblock at 163840, Group descriptors at 163841-163841 Reserved GDT blocks at 163842-163960 Block bitmap at 163961 (+121), Inode bitmap at 163962 (+122) Inode table at 163963-164471 (+123) 32135 free blocks, 16286 free inodes, 1 directories Free blocks: 164472-182271, 182273-196607 Free inodes: 81443-97728 Group 6: (Blocks 196608-229375) Block bitmap at 196608 (+0), Inode bitmap at 196609 (+1) Inode table at 196610-197118 (+2) 32087 free blocks, 16265 free inodes, 1 directories Free blocks: 197119-200703, 200705-210943, 210945-210951, 210970-210975, 210988-215039, 215041-215047, 215058-215071, 215090-217087, 217089-219135, 219137-219143, 219177-219199, 219226-219255, 219257-219263, 219265-219271, 219274-219279, 219305-219335, 219337-219343, 219345-219351, 219354-219359, 219371-219383, 219385-227327, 227331-229375 Free inodes: 97752-114016 Group 7: (Blocks 229376-262143) Backup superblock at 229376, Group descriptors at 229377-229377 Reserved GDT blocks at 229378-229496 Block bitmap at 229497 (+121), Inode bitmap at 229498 (+122) Inode table at 229499-230007 (+123) 32134 free blocks, 16278 free inodes, 1 directories Free blocks: 230008-253951, 253953-260095, 260097-262143 Free inodes: 114022, 114025-114027, 114031-130304 Group 8: (Blocks 262144-294911) Block bitmap at 262144 (+0), Inode bitmap at 262145 (+1) Inode table at 262146-262654 (+2) 29809 free blocks, 16193 free inodes, 17 directories Free blocks: 262661-264191, 264244, 264250, 264263, 264272, 264281, 264288-266239, 266870-266871, 266877-268287, 268289-270335, 270965-274431, 274434-282623, 282625-290815, 291897-292863,
Re: regression: 100% io-wait with 2.6.24-rcX
Am Donnerstag, 10. Januar 2008 schrieb Fengguang Wu: > > problem, because the iowait problem disappeared today after the regular > > Debian update. I'll try to install the old package versions to make it > > show up again. Maybe that helps to debug it. > > Thank you. I'm running sid, ext2 as rootfs now ;-) The error is back and I'm getting thousands of messages like this with the patched kernel: mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3936 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3936 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3936 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3936 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3936 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3936 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3936 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3936 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3936 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3936 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3937 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3937 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3937 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3937 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3937 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3937 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3937 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3937 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3938 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3938 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3939 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3939 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3939 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3939 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3939 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3939 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3939 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3939 0 0 wc _M tw 1024 sk 2 regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- 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: regression: 100% io-wait with 2.6.24-rcX
Am Donnerstag, 10. Januar 2008 schrieb Fengguang Wu: > On Thu, Jan 10, 2008 at 03:30:46PM +0800, Fengguang Wu wrote: > > Joerg, > > > > Can you try the attached patches? Thank you. > > I cannot reliably reproduce the bug yet. > > Please ignore the first patch and only apply the two debugging > patches. They will produce many printk messages. The output of > `dmesg` will be enough for me. Too late, I'm already compiling the kernel. But I have currently another problem, because the iowait problem disappeared today after the regular Debian update. I'll try to install the old package versions to make it show up again. Maybe that helps to debug it. Grüße, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- 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: regression: 100% io-wait with 2.6.24-rcX
Am Donnerstag, 10. Januar 2008 schrieb Fengguang Wu: On Thu, Jan 10, 2008 at 03:30:46PM +0800, Fengguang Wu wrote: Joerg, Can you try the attached patches? Thank you. I cannot reliably reproduce the bug yet. Please ignore the first patch and only apply the two debugging patches. They will produce many printk messages. The output of `dmesg` will be enough for me. Too late, I'm already compiling the kernel. But I have currently another problem, because the iowait problem disappeared today after the regular Debian update. I'll try to install the old package versions to make it show up again. Maybe that helps to debug it. Grüße, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- 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: regression: 100% io-wait with 2.6.24-rcX
Am Donnerstag, 10. Januar 2008 schrieb Fengguang Wu: problem, because the iowait problem disappeared today after the regular Debian update. I'll try to install the old package versions to make it show up again. Maybe that helps to debug it. Thank you. I'm running sid, ext2 as rootfs now ;-) The error is back and I'm getting thousands of messages like this with the patched kernel: mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3936 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3936 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3936 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3936 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3936 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3936 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3936 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3936 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3936 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3936 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3937 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3937 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3937 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3937 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3937 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3937 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3937 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3937 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3938 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3938 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3939 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3939 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3939 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3939 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3939 0 0 wc _M tw 1024 sk 2 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3939 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(146) 21115 global 3939 0 0 wc _M tw 1024 sk 0 requeue_io 301: inode 81441 size 0 at 08:07(sda7) mm/page-writeback.c 668 wb_kupdate: pdflush(147) 17451 global 3939 0 0 wc _M tw 1024 sk 2 regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- 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: regression: 100% io-wait with 2.6.24-rcX
Am Freitag, 11. Januar 2008 schrieb Fengguang Wu: Joerg, what's the output of `dumpe2fs /dev/sda7` and `lsof|grep /tmp`? Fengang, here is the output (kernel 2.6.24-rc7 without your patches): Filesystem volume name: TMP Last mounted on: not available Filesystem UUID: e23ae961-bbdc-44bc-b662-f28f7314939b Filesystem magic number: 0xEF53 Filesystem revision #:1 (dynamic) Filesystem features: has_journal resize_inode dir_index filetype sparse_super large_file Filesystem flags: signed directory hash Default mount options:(none) Filesystem state: not clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 244320 Block count: 487966 Reserved block count: 24398 Free blocks: 468728 Free inodes: 244162 First block: 0 Block size: 4096 Fragment size:4096 Reserved GDT blocks: 119 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 16288 Inode blocks per group: 509 Filesystem created: Thu Feb 8 18:46:19 2007 Last mount time: Thu Jan 10 11:09:35 2008 Last write time: Fri Jan 11 06:12:58 2008 Mount count: 25 Maximum mount count: 39 Last checked: Tue Dec 11 22:07:03 2007 Check interval: 15552000 (6 months) Next check after: Sun Jun 8 23:07:03 2008 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Journal inode:8 Default directory hash: tea Directory Hash Seed: 79e271e9-b874-4e11-92b0-cdb36d07e1c1 Journal backup: inode blocks Journal size: 32M Group 0: (Blocks 0-32767) Primary superblock at 0, Group descriptors at 1-1 Reserved GDT blocks at 2-120 Block bitmap at 121 (+121), Inode bitmap at 122 (+122) Inode table at 123-631 (+123) 23926 free blocks, 16275 free inodes, 2 directories Free blocks: 638-10239, 16384, 18444-30719, 30721-32767 Free inodes: 14-16288 Group 1: (Blocks 32768-65535) Backup superblock at 32768, Group descriptors at 32769-32769 Reserved GDT blocks at 32770-32888 Block bitmap at 32889 (+121), Inode bitmap at 32890 (+122) Inode table at 32891-33399 (+123) 32135 free blocks, 16287 free inodes, 1 directories Free blocks: 33400-57343, 57345-65535 Free inodes: 16290-32576 Group 2: (Blocks 65536-98303) Block bitmap at 65536 (+0), Inode bitmap at 65537 (+1) Inode table at 65538-66046 (+2) 32256 free blocks, 16286 free inodes, 1 directories Free blocks: 66047-96255, 96257-98303 Free inodes: 32579-48864 Group 3: (Blocks 98304-131071) Backup superblock at 98304, Group descriptors at 98305-98305 Reserved GDT blocks at 98306-98424 Block bitmap at 98425 (+121), Inode bitmap at 98426 (+122) Inode table at 98427-98935 (+123) 32135 free blocks, 16286 free inodes, 1 directories Free blocks: 98936-120831, 120833-131071 Free inodes: 48867-65152 Group 4: (Blocks 131072-163839) Block bitmap at 131072 (+0), Inode bitmap at 131073 (+1) Inode table at 131074-131582 (+2) 32256 free blocks, 16287 free inodes, 1 directories Free blocks: 131583-133119, 133121-163839 Free inodes: 65154-81440 Group 5: (Blocks 163840-196607) Backup superblock at 163840, Group descriptors at 163841-163841 Reserved GDT blocks at 163842-163960 Block bitmap at 163961 (+121), Inode bitmap at 163962 (+122) Inode table at 163963-164471 (+123) 32135 free blocks, 16286 free inodes, 1 directories Free blocks: 164472-182271, 182273-196607 Free inodes: 81443-97728 Group 6: (Blocks 196608-229375) Block bitmap at 196608 (+0), Inode bitmap at 196609 (+1) Inode table at 196610-197118 (+2) 32087 free blocks, 16265 free inodes, 1 directories Free blocks: 197119-200703, 200705-210943, 210945-210951, 210970-210975, 210988-215039, 215041-215047, 215058-215071, 215090-217087, 217089-219135, 219137-219143, 219177-219199, 219226-219255, 219257-219263, 219265-219271, 219274-219279, 219305-219335, 219337-219343, 219345-219351, 219354-219359, 219371-219383, 219385-227327, 227331-229375 Free inodes: 97752-114016 Group 7: (Blocks 229376-262143) Backup superblock at 229376, Group descriptors at 229377-229377 Reserved GDT blocks at 229378-229496 Block bitmap at 229497 (+121), Inode bitmap at 229498 (+122) Inode table at 229499-230007 (+123) 32134 free blocks, 16278 free inodes, 1 directories Free blocks: 230008-253951, 253953-260095, 260097-262143 Free inodes: 114022, 114025-114027, 114031-130304 Group 8: (Blocks 262144-294911) Block bitmap at 262144 (+0), Inode bitmap at 262145 (+1) Inode table at 262146-262654 (+2) 29809 free blocks, 16193 free inodes, 17 directories Free blocks: 262661-264191, 264244, 264250, 264263, 264272, 264281, 264288-266239, 266870-266871, 266877-268287, 268289-270335, 270965-274431, 274434-282623, 282625-290815,
Re: regression: 100% io-wait with 2.6.24-rcX
Am Freitag, 11. Januar 2008 schrieb Joerg Platte: konqueror 987jplatte mem REG8,6 2590525 1336104 /var/tmp/kdecache-jplatte/ksycoca konqueror 987jplatte 12r REG8,6 2590525 1336104 /var/tmp/kdecache-jplatte/ksycoca konqueror 987jplatte 13u REG8,7 579 97731 /tmp/kde-jplatte/konqueror-crash-Jv2u8a.log konqueror 987jplatte 14u REG8,7 128289 97734 /tmp/kde-jplatte/khtmlcacheA7VjAa.tmp (deleted) konqueror 987jplatte 16u REG8,743334 97750 /tmp/kde-jplatte/khtmlcacheZUNlsc.tmp (deleted) konqueror 987jplatte 22u REG8,7 797 97751 /tmp/kde-jplatte/khtmlcache76bZYa.tmp (deleted) konqueror 987jplatte 27u REG8,7 102347 97735 /tmp/kde-jplatte/khtmlcacheMhlDJb.tmp (deleted) konqueror 987jplatte 31u REG8,7 354 97738 /tmp/kde-jplatte/khtmlcacheq21uoc.tmp (deleted) konqueror 987jplatte 32u REG8,7 1360 97742 /tmp/kde-jplatte/khtmlcacheo2Ms2a.tmp (deleted) konqueror 987jplatte 34u REG8,7 6378 97745 /tmp/kde-jplatte/khtmlcacheLETtgc.tmp (deleted) konqueror 987jplatte 35u REG8,797350 97746 /tmp/kde-jplatte/khtmlcache5jit8a.tmp (deleted) konqueror 987jplatte 36u REG8,7 354 97747 /tmp/kde-jplatte/khtmlcache7VBSNa.tmp (deleted) konqueror 987jplatte 37u REG8,7 1360 97748 /tmp/kde-jplatte/khtmlcachetSNbub.tmp (deleted) konqueror 987jplatte 38u REG8,7 6073 97749 /tmp/kde-jplatte/khtmlcacheKAKhuc.tmp (deleted) Fengguang, a few minutes after killing this konqueror process the high iowait load has disappeared. Lets see if it'll come back... regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- 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: regression: 100% io-wait with 2.6.24-rcX
Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu: > On Wed, Jan 09, 2008 at 01:22:33PM +0100, Joerg Platte wrote: > > Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu: > > > > Thank your for the hint with the filesystems! > > > > > Thank you for the clue. However I cannot reproduce the bug on > > > ext2/2.6.24-rc7. Can you provide more details? Thank you. > > > > I attached some more information. I'm using the ata_piix driver for my > > PATA disk and cdrom drive and booted with hpet=force. Kernel 2.6.23.X has > > been > > > not 2.6.24-rc7? > No, 2.6.23.X was the last working kernel without this problem, the bug shows up with 2.6.24-rcX. I just wanted to emphasis, that I don't think that it has something to do with the hpet stuff. Kernel 2.6.24-rcX is unpatched, because the hrt stuff has been merged. > > patched with the -hrt patches to enable the hidden hpet time on the > > ICH4-M chipset. I just rebooted the notebook and mounted /tmp again as > > ext2 and now the iowait problem is back. Seems to be reproducible on my > > computer. What additional information do you need? > > I mounted an ext2 as tmp and find no problem. My config options are: > > CONFIG_EXT2_FS=y > CONFIG_EXT2_FS_XATTR=y > CONFIG_EXT2_FS_POSIX_ACL=y > CONFIG_EXT2_FS_SECURITY=y > # CONFIG_EXT2_FS_XIP is not set > > Fengguang CONFIG_EXT2_FS=m CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT2_FS_XIP=y Here it is modular and I enabled CONFIG_EXT2_FS_XIP, but the same is enabled on 2.6.23.X. Maybe it is related to libata? I additionally discovered, that the problem disappears for a few seconds when I press the eject button for the ultra bay of my thinkpad. Pressing the button unregisters the cdrom drive to be able to replace it with a hard drive or a battery. Maybe this bug is thinkpad relared? regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- 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: regression: 100% io-wait with 2.6.24-rcX
Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu: Thank your for the hint with the filesystems! > Thank you for the clue. However I cannot reproduce the bug on > ext2/2.6.24-rc7. Can you provide more details? Thank you. I attached some more information. I'm using the ata_piix driver for my PATA disk and cdrom drive and booted with hpet=force. Kernel 2.6.23.X has been patched with the -hrt patches to enable the hidden hpet time on the ICH4-M chipset. I just rebooted the notebook and mounted /tmp again as ext2 and now the iowait problem is back. Seems to be reproducible on my computer. What additional information do you need? regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03) 00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81) 00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) 00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 [Mobility FireGL 9000] (rev 02) 02:00.0 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01) 02:00.1 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01) 02:01.0 Ethernet controller: Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile) (rev 03) 02:02.0 Ethernet controller: Atheros Communications, Inc. AR5211 802.11ab NIC (rev 01) Module Size Used by radeon112644 2 drm73684 3 radeon binfmt_misc10568 1 rfcomm 35924 1 l2cap 22660 5 rfcomm bluetooth 51872 4 rfcomm,l2cap snd_rtctimer3616 1 nfsd 201652 13 auth_rpcgss39492 1 nfsd exportfs4544 1 nfsd af_packet 20292 4 autofs420356 2 ipt_MASQUERADE 3328 3 iptable_nat 6660 1 nf_nat 17948 2 ipt_MASQUERADE,iptable_nat nf_conntrack_ipv4 16328 11 iptable_nat xt_state2304 9 ipt_LOG 5632 9 xt_limit2432 9 ipt_REJECT 4288 2 xt_mark 1728 2 xt_tcpudp 2944 12 xt_mac 1728 38 iptable_filter 2752 1 xt_MARK 2048 3 xt_multiport2880 8 iptable_mangle 2560 1 ip_tables 12168 3 iptable_nat,iptable_filter,iptable_mangle x_tables 13828 12 ipt_MASQUERADE,iptable_nat,xt_state,ipt_LOG,xt_limit,ipt_REJECT,xt_mark,xt_tcpudp,xt_mac,xt_MARK,xt_multiport,ip_tables nf_conntrack_ftp8224 0 nf_conntrack 61200 6 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4,xt_state,nf_conntrack_ftp cpufreq_userspace 3800 0 cpufreq_stats 4868 0 cpufreq_powersave 1600 0 nfs 227136 0 lockd 59576 3 nfsd,nfs nfs_acl 3264 2 nfsd,nfs sunrpc169308 11 nfsd,auth_rpcgss,nfs,lockd,nfs_acl deflate 3520 0 zlib_deflate 17960 1 deflate zlib_inflate 15488 1 deflate twofish 6592 0 twofish_common 36416 1 twofish camellia 28736 0 serpent18368 0 blowfish8128 0 des_generic16128 0 cbc 4288 0 ecb 3328 0 aes_generic26536 0 aes_i586 32436 0 geode_aes 5700 0 blkcipher 6404 3 cbc,ecb,geode_aes xcbc5384 0 sha256_generic 11008 0 sha1_generic2432 0 md5 3840 0 crypto_null 2368 0 hmac4352 0 crypto_hash 2048 2 xcbc,hmac cryptomgr 3520 0 crypto_algapi 16256 19
Re: regression: 100% io-wait with 2.6.24-rcX
Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu: Thank your for the hint with the filesystems! Thank you for the clue. However I cannot reproduce the bug on ext2/2.6.24-rc7. Can you provide more details? Thank you. I attached some more information. I'm using the ata_piix driver for my PATA disk and cdrom drive and booted with hpet=force. Kernel 2.6.23.X has been patched with the -hrt patches to enable the hidden hpet time on the ICH4-M chipset. I just rebooted the notebook and mounted /tmp again as ext2 and now the iowait problem is back. Seems to be reproducible on my computer. What additional information do you need? regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03) 00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81) 00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) 00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 [Mobility FireGL 9000] (rev 02) 02:00.0 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01) 02:00.1 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01) 02:01.0 Ethernet controller: Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile) (rev 03) 02:02.0 Ethernet controller: Atheros Communications, Inc. AR5211 802.11ab NIC (rev 01) Module Size Used by radeon112644 2 drm73684 3 radeon binfmt_misc10568 1 rfcomm 35924 1 l2cap 22660 5 rfcomm bluetooth 51872 4 rfcomm,l2cap snd_rtctimer3616 1 nfsd 201652 13 auth_rpcgss39492 1 nfsd exportfs4544 1 nfsd af_packet 20292 4 autofs420356 2 ipt_MASQUERADE 3328 3 iptable_nat 6660 1 nf_nat 17948 2 ipt_MASQUERADE,iptable_nat nf_conntrack_ipv4 16328 11 iptable_nat xt_state2304 9 ipt_LOG 5632 9 xt_limit2432 9 ipt_REJECT 4288 2 xt_mark 1728 2 xt_tcpudp 2944 12 xt_mac 1728 38 iptable_filter 2752 1 xt_MARK 2048 3 xt_multiport2880 8 iptable_mangle 2560 1 ip_tables 12168 3 iptable_nat,iptable_filter,iptable_mangle x_tables 13828 12 ipt_MASQUERADE,iptable_nat,xt_state,ipt_LOG,xt_limit,ipt_REJECT,xt_mark,xt_tcpudp,xt_mac,xt_MARK,xt_multiport,ip_tables nf_conntrack_ftp8224 0 nf_conntrack 61200 6 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4,xt_state,nf_conntrack_ftp cpufreq_userspace 3800 0 cpufreq_stats 4868 0 cpufreq_powersave 1600 0 nfs 227136 0 lockd 59576 3 nfsd,nfs nfs_acl 3264 2 nfsd,nfs sunrpc169308 11 nfsd,auth_rpcgss,nfs,lockd,nfs_acl deflate 3520 0 zlib_deflate 17960 1 deflate zlib_inflate 15488 1 deflate twofish 6592 0 twofish_common 36416 1 twofish camellia 28736 0 serpent18368 0 blowfish8128 0 des_generic16128 0 cbc 4288 0 ecb 3328 0 aes_generic26536 0 aes_i586 32436 0 geode_aes 5700 0 blkcipher 6404 3 cbc,ecb,geode_aes xcbc5384 0 sha256_generic 11008 0 sha1_generic2432 0 md5 3840 0 crypto_null 2368 0 hmac4352 0 crypto_hash 2048 2 xcbc,hmac cryptomgr 3520 0 crypto_algapi 16256 19
Re: regression: 100% io-wait with 2.6.24-rcX
Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu: On Wed, Jan 09, 2008 at 01:22:33PM +0100, Joerg Platte wrote: Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu: Thank your for the hint with the filesystems! Thank you for the clue. However I cannot reproduce the bug on ext2/2.6.24-rc7. Can you provide more details? Thank you. I attached some more information. I'm using the ata_piix driver for my PATA disk and cdrom drive and booted with hpet=force. Kernel 2.6.23.X has been not 2.6.24-rc7? No, 2.6.23.X was the last working kernel without this problem, the bug shows up with 2.6.24-rcX. I just wanted to emphasis, that I don't think that it has something to do with the hpet stuff. Kernel 2.6.24-rcX is unpatched, because the hrt stuff has been merged. patched with the -hrt patches to enable the hidden hpet time on the ICH4-M chipset. I just rebooted the notebook and mounted /tmp again as ext2 and now the iowait problem is back. Seems to be reproducible on my computer. What additional information do you need? I mounted an ext2 as tmp and find no problem. My config options are: CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y # CONFIG_EXT2_FS_XIP is not set Fengguang CONFIG_EXT2_FS=m CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT2_FS_XIP=y Here it is modular and I enabled CONFIG_EXT2_FS_XIP, but the same is enabled on 2.6.23.X. Maybe it is related to libata? I additionally discovered, that the problem disappears for a few seconds when I press the eject button for the ultra bay of my thinkpad. Pressing the button unregisters the cdrom drive to be able to replace it with a hard drive or a battery. Maybe this bug is thinkpad relared? regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- 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: regression: 100% io-wait with 2.6.24-rcX
Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu: > > /dev/sda6 on / type ext3 (rw,noatime,errors=remount-ro,acl) > > tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) > > proc on /proc type proc (rw,noexec,nosuid,nodev) > > sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) > > procbususb on /proc/bus/usb type usbfs (rw) > > udev on /dev type tmpfs (rw,mode=0755) > > tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) > > devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) > > fusectl on /sys/fs/fuse/connections type fusectl (rw) > > /dev/sda7 on /tmp type ext2 (rw,noatime,errors=remount-ro,acl) > > /dev/sda8 on /export type ext3 (rw,noatime,errors=remount-ro,acl) > > /dev/sda1 on /winxp type ntfs (rw,umask=002,gid=1,nls=utf8) > > So they are ext3/ext2/ntfs. What if you umount ntfs? and ext2 if possible? Unmounting ntfs doesn't help, hence I converted the remaining ext2 filesystem to ext3, modified the fstab entry accordingly and rebooted. Now everything seems to be fine! Top reports an idle system and there is no abnormal iowait any longer! Seems to be ext2 was causing this! Later today I can try to remount the filesystem as ext2 to be sure the bug shows up again. regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- 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: regression: 100% io-wait with 2.6.24-rcX
Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu: /dev/sda6 on / type ext3 (rw,noatime,errors=remount-ro,acl) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) procbususb on /proc/bus/usb type usbfs (rw) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) fusectl on /sys/fs/fuse/connections type fusectl (rw) /dev/sda7 on /tmp type ext2 (rw,noatime,errors=remount-ro,acl) /dev/sda8 on /export type ext3 (rw,noatime,errors=remount-ro,acl) /dev/sda1 on /winxp type ntfs (rw,umask=002,gid=1,nls=utf8) So they are ext3/ext2/ntfs. What if you umount ntfs? and ext2 if possible? Unmounting ntfs doesn't help, hence I converted the remaining ext2 filesystem to ext3, modified the fstab entry accordingly and rebooted. Now everything seems to be fine! Top reports an idle system and there is no abnormal iowait any longer! Seems to be ext2 was causing this! Later today I can try to remount the filesystem as ext2 to be sure the bug shows up again. regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- 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: regression: 100% io-wait with 2.6.24-rcX
Am Montag, 7. Januar 2008 schrieb Peter Zijlstra: > On Mon, 2008-01-07 at 14:24 +0100, Joerg Platte wrote: > > This is from: 2.6.24-rc7 > > > kernel: pdflush D f41c2f14 0 18822 2 > > kernel:f673f000 0046 0286 f41c2f14 f5194ce0 0286 > > 0286 f41c2f14 kernel:00175279 f41c2f6c c0271f6c > > f5ff363c f5ff3644 c0354a90 c0354a90 kernel:00175279 c0123251 > > f5194b80 c03546c0 c0271f67 6c666470 00687375 kernel: Call Trace: > > kernel: [] schedule_timeout+0x6e/0x8b > > kernel: [] process_timeout+0x0/0x5 > > kernel: [] schedule_timeout+0x69/0x8b > > kernel: [] __sched_text_start+0x3a/0x70 > > kernel: [] congestion_wait+0x4e/0x62 > > kernel: [] autoremove_wake_function+0x0/0x33 > > kernel: [] pdflush+0x0/0x1bf > > kernel: [] wb_kupdate+0x8c/0xd1 > > kernel: [] pdflush+0x0/0x1bf > > kernel: [] pdflush+0x11b/0x1bf > > kernel: [] wb_kupdate+0x0/0xd1 > > kernel: [] kthread+0x36/0x5d > > kernel: [] kthread+0x0/0x5d > > kernel: [] kernel_thread_helper+0x7/0x10 > > kernel: === > > What filesystem are you using? Here you can see all currently mounted filesystems: /dev/sda6 on / type ext3 (rw,noatime,errors=remount-ro,acl) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) procbususb on /proc/bus/usb type usbfs (rw) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) fusectl on /sys/fs/fuse/connections type fusectl (rw) /dev/sda7 on /tmp type ext2 (rw,noatime,errors=remount-ro,acl) /dev/sda8 on /export type ext3 (rw,noatime,errors=remount-ro,acl) /dev/sda1 on /winxp type ntfs (rw,umask=002,gid=1,nls=utf8) rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) automount(pid4936) on /amnt type autofs (rw,fd=4,pgrp=4936,minproto=2,maxproto=4) automount(pid4965) on /home type autofs (rw,fd=4,pgrp=4965,minproto=2,maxproto=4) nfsd on /proc/fs/nfsd type nfsd (rw) /export/home/jplatte on /home/jplatte type none (rw,bind) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- 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: regression: 100% io-wait with 2.6.24-rcX
Am Montag, 7. Januar 2008 schrieb Ingo Molnar: > do: > > echo t > /proc/sysrq-trigger > > and send us the dmesg output. If the dmesg output does not include the > bootup bits then increase CONFIG_LOG_BUF_SHIFT to 20 or so: > > CONFIG_LOG_BUF_SHIFT=20 > > to have a large enough kernel messages buffer. The buffer was too small, hence I copied the relevant parts of /var/log/kern.log, I hope it contains all required information as well. regards, Jörg kernel: f509eb84 f50dc700 f50f3be4 0246 f50f3be4 f5c37b80 c01672ef kernel: Call Trace: kernel: [] schedule_timeout+0x13/0x8b kernel: [] pipe_poll+0x24/0x7f kernel: [] do_select+0x370/0x3b9 kernel: [] __pollwait+0x0/0xa9 kernel: [] default_wake_function+0x0/0x5 last message repeated 4 times kernel: [] __rmqueue+0x14/0x196 kernel: [] enqueue_entity+0x2b/0x3d kernel: [] enqueue_task_fair+0x16/0x24 kernel: [] enqueue_task+0x3f/0x4a kernel: [] __wake_up_common+0x31/0x56 kernel: [] __slab_free+0x5b/0x279 kernel: [] __kfree_skb+0x8/0x63 kernel: [] sock_wfree+0x20/0x34 kernel: [] skb_release_all+0xa1/0xf6 kernel: [] unix_stream_recvmsg+0x3e9/0x4d6 [unix] kernel: [] core_sys_select+0x1ec/0x282 kernel: [] sock_aio_read+0xf2/0xfa kernel: [] recalc_sigpending+0xa/0x2d kernel: [] do_sync_read+0xc6/0x109 kernel: [] autoremove_wake_function+0x0/0x33 kernel: [] unix_ioctl+0xa4/0xac [unix] kernel: [] sock_ioctl+0x1b2/0x1d7 kernel: [] sys_select+0xa0/0x167 kernel: [] sysenter_past_esp+0x5f/0x85 kernel: [] netlbl_unlabel_list+0x9f/0x1bf kernel: === kernel: bash R running 0 8034 7712 kernel: bash S 00fd 0 8062 7713 kernel:dfcc0a80 0082 12210264 00fd f537ace0 01366da4 7fff kernel:dfc77000 0001 bf9130cf c0271f11 f78127b0 f535ffb8 f535ff90 kernel:f537b034 bf9130cf f535ffb8 f535f000 c010348a 080c5c60 kernel: Call Trace: kernel: [] schedule_timeout+0x13/0x8b kernel: [] do_notify_resume+0x81/0x5f6 kernel: [] read_chan+0x2fc/0x521 kernel: [] default_wake_function+0x0/0x5 kernel: [] read_chan+0x0/0x521 kernel: [] tty_read+0x6f/0xad kernel: [] tty_read+0x0/0xad kernel: [] vfs_read+0x9f/0x149 kernel: [] sys_read+0x41/0x67 kernel: [] sysenter_past_esp+0x5f/0x85 kernel: === kernel: kwalletmanage S 0648 0 8371 1 kernel:f4128600 00200086 fcf08470 0648 f52fd860 0006eb74 7fff kernel:f407a500 0400 f4176f4c c0271f11 f414b200 00200200 kernel:0016e496 c0123251 f4123e00 f4176be4 00200246 f4176be4 f407a500 001672ef kernel: Call Trace: kernel: [] schedule_timeout+0x13/0x8b kernel: [] process_timeout+0x0/0x5 kernel: [] do_select+0x370/0x3b9 kernel: [] __pollwait+0x0/0xa9 kernel: [] default_wake_function+0x0/0x5 last message repeated 4 times kernel: [] elv_insert+0xa6/0x146 kernel: [] enqueue_entity+0x2b/0x3d kernel: [] enqueue_task_fair+0x16/0x24 kernel: [] enqueue_task+0x3f/0x4a kernel: [] enqueue_entity+0x2b/0x3d kernel: [] enqueue_task_fair+0x16/0x24 kernel: [] enqueue_task+0x3f/0x4a kernel: [] __wake_up_common+0x31/0x56 kernel: [] sock_alloc_send_skb+0x7c/0x193 kernel: [] __wake_up_common+0x31/0x56 kernel: [] sock_def_readable+0x31/0x6b kernel: [] unix_stream_sendmsg+0x263/0x32c [unix] kernel: [] core_sys_select+0x1ec/0x282 kernel: [] sock_aio_write+0xe0/0xe8 kernel: [] pipe_read+0x32c/0x338 kernel: [] do_sync_write+0xc6/0x109 kernel: [] autoremove_wake_function+0x0/0x33 kernel: [] free_pgtables+0x90/0xa0 kernel: [] unix_ioctl+0xa4/0xac [unix] kernel: [] sock_ioctl+0x1b2/0x1d7 kernel: [] sys_select+0xa0/0x167 kernel: [] sysenter_past_esp+0x5f/0x85 kernel: === kernel: kttsd S 0655 0 8384 1 kernel:dfcc0900 00200086 af7cbb2c 0655 f52bcce0 00044e4d 7fff kernel:f4131180 0400 f4050f4c c0271f11 c010478b f889407c f4ba7000 kernel:f416a600 0020 f4075c40 f4050be4 00200246 f4050be4 f4131180 c01672ef kernel: Call Trace: kernel: [] schedule_timeout+0x13/0x8b kernel: [] common_interrupt+0x23/0x28 kernel: [] pipe_poll+0x24/0x7f kernel: [] do_select+0x370/0x3b9 kernel: [] __pollwait+0x0/0xa9 kernel: [] default_wake_function+0x0/0x5 last message repeated 4 times kernel: [] __getblk+0x14/0x1cd kernel: [] get_unused_fd_flags+0x55/0xcb kernel: [] ext3_getblk+0xb9/0x173 [ext3] kernel: [] scm_detach_fds+0xec/0x125 kernel: [] __scm_destroy+0x23/0x38 kernel: [] enqueue_entity+0x2b/0x3d kernel: [] enqueue_task_fair+0x16/0x24 kernel: [] enqueue_task+0x3f/0x4a kernel: [] __wake_up_common+0x31/0x56 kernel: [] unix_write_space+0x32/0x6a [unix] kernel: [] sock_wfree+0x20/0x34 kernel: [] skb_release_all+0xa1/0xf6 kernel: [] unix_stream_recvmsg+0x3e9/0x4d6 [unix] kernel: [] core_sys_select+0x1ec/0x282 kernel: [] sock_aio_read+0xf2/0xfa kernel: [] recalc_sigpending+0xa/0x2d kernel: []
regression: 100% io-wait with 2.6.24-rcX
Hi,
when booting kernel 2.6.24-rc{4,5,6,7} top reports up to 100% iowait, even if
no program accesses the disc on my Thinkpad T40p. Kernel 2.6.23.12 does not
suffer from this. Is there anything I can do to find out which process or
which part of the kernel is responsible for this? I can try to bisect it, but
maybe there are other possibilities to debug this, since I cannot boot this
computer frequently. I discovered, that there is no iowait within the first
few seconds after waking up from suspend to ram...
regards,
Jörg
--
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/
regression: 100% io-wait with 2.6.24-rcX
Hi,
when booting kernel 2.6.24-rc{4,5,6,7} top reports up to 100% iowait, even if
no program accesses the disc on my Thinkpad T40p. Kernel 2.6.23.12 does not
suffer from this. Is there anything I can do to find out which process or
which part of the kernel is responsible for this? I can try to bisect it, but
maybe there are other possibilities to debug this, since I cannot boot this
computer frequently. I discovered, that there is no iowait within the first
few seconds after waking up from suspend to ram...
regards,
Jörg
--
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: regression: 100% io-wait with 2.6.24-rcX
Am Montag, 7. Januar 2008 schrieb Ingo Molnar: do: echo t /proc/sysrq-trigger and send us the dmesg output. If the dmesg output does not include the bootup bits then increase CONFIG_LOG_BUF_SHIFT to 20 or so: CONFIG_LOG_BUF_SHIFT=20 to have a large enough kernel messages buffer. The buffer was too small, hence I copied the relevant parts of /var/log/kern.log, I hope it contains all required information as well. regards, Jörg kernel: f509eb84 f50dc700 f50f3be4 0246 f50f3be4 f5c37b80 c01672ef kernel: Call Trace: kernel: [c0271f11] schedule_timeout+0x13/0x8b kernel: [c01672ef] pipe_poll+0x24/0x7f kernel: [c016d53f] do_select+0x370/0x3b9 kernel: [c016daf0] __pollwait+0x0/0xa9 kernel: [c0118a51] default_wake_function+0x0/0x5 last message repeated 4 times kernel: [c0146ba7] __rmqueue+0x14/0x196 kernel: [c01169ce] enqueue_entity+0x2b/0x3d kernel: [c01169f6] enqueue_task_fair+0x16/0x24 kernel: [c011642e] enqueue_task+0x3f/0x4a kernel: [c01162b8] __wake_up_common+0x31/0x56 kernel: [c015e1ef] __slab_free+0x5b/0x279 kernel: [c0215e3a] __kfree_skb+0x8/0x63 kernel: [c0214a2c] sock_wfree+0x20/0x34 kernel: [c0216521] skb_release_all+0xa1/0xf6 kernel: [f8892813] unix_stream_recvmsg+0x3e9/0x4d6 [unix] kernel: [c016d774] core_sys_select+0x1ec/0x282 kernel: [c0210d34] sock_aio_read+0xf2/0xfa kernel: [c0123d9a] recalc_sigpending+0xa/0x2d kernel: [c0162077] do_sync_read+0xc6/0x109 kernel: [c012be2b] autoremove_wake_function+0x0/0x33 kernel: [f88929a4] unix_ioctl+0xa4/0xac [unix] kernel: [c0210adb] sock_ioctl+0x1b2/0x1d7 kernel: [c016dc39] sys_select+0xa0/0x167 kernel: [c0103d7a] sysenter_past_esp+0x5f/0x85 kernel: [c027] netlbl_unlabel_list+0x9f/0x1bf kernel: === kernel: bash R running 0 8034 7712 kernel: bash S 00fd 0 8062 7713 kernel:dfcc0a80 0082 12210264 00fd f537ace0 01366da4 7fff kernel:dfc77000 0001 bf9130cf c0271f11 f78127b0 f535ffb8 f535ff90 kernel:f537b034 bf9130cf f535ffb8 f535f000 c010348a 080c5c60 kernel: Call Trace: kernel: [c0271f11] schedule_timeout+0x13/0x8b kernel: [c010348a] do_notify_resume+0x81/0x5f6 kernel: [c01f014b] read_chan+0x2fc/0x521 kernel: [c0118a51] default_wake_function+0x0/0x5 kernel: [c01efe4f] read_chan+0x0/0x521 kernel: [c01ed351] tty_read+0x6f/0xad kernel: [c01ed2e2] tty_read+0x0/0xad kernel: [c01628e5] vfs_read+0x9f/0x149 kernel: [c0162c74] sys_read+0x41/0x67 kernel: [c0103d7a] sysenter_past_esp+0x5f/0x85 kernel: === kernel: kwalletmanage S 0648 0 8371 1 kernel:f4128600 00200086 fcf08470 0648 f52fd860 0006eb74 7fff kernel:f407a500 0400 f4176f4c c0271f11 f414b200 00200200 kernel:0016e496 c0123251 f4123e00 f4176be4 00200246 f4176be4 f407a500 001672ef kernel: Call Trace: kernel: [c0271f11] schedule_timeout+0x13/0x8b kernel: [c0123251] process_timeout+0x0/0x5 kernel: [c016d53f] do_select+0x370/0x3b9 kernel: [c016daf0] __pollwait+0x0/0xa9 kernel: [c0118a51] default_wake_function+0x0/0x5 last message repeated 4 times kernel: [c01abd85] elv_insert+0xa6/0x146 kernel: [c01169ce] enqueue_entity+0x2b/0x3d kernel: [c01169f6] enqueue_task_fair+0x16/0x24 kernel: [c011642e] enqueue_task+0x3f/0x4a kernel: [c01169ce] enqueue_entity+0x2b/0x3d kernel: [c01169f6] enqueue_task_fair+0x16/0x24 kernel: [c011642e] enqueue_task+0x3f/0x4a kernel: [c01162b8] __wake_up_common+0x31/0x56 kernel: [c02131ab] sock_alloc_send_skb+0x7c/0x193 kernel: [c01162b8] __wake_up_common+0x31/0x56 kernel: [c021474d] sock_def_readable+0x31/0x6b kernel: [f8892c62] unix_stream_sendmsg+0x263/0x32c [unix] kernel: [c016d774] core_sys_select+0x1ec/0x282 kernel: [c0210c3a] sock_aio_write+0xe0/0xe8 kernel: [c01681c4] pipe_read+0x32c/0x338 kernel: [c0161f6e] do_sync_write+0xc6/0x109 kernel: [c012be2b] autoremove_wake_function+0x0/0x33 kernel: [c01508b4] free_pgtables+0x90/0xa0 kernel: [f88929a4] unix_ioctl+0xa4/0xac [unix] kernel: [c0210adb] sock_ioctl+0x1b2/0x1d7 kernel: [c016dc39] sys_select+0xa0/0x167 kernel: [c0103d7a] sysenter_past_esp+0x5f/0x85 kernel: === kernel: kttsd S 0655 0 8384 1 kernel:dfcc0900 00200086 af7cbb2c 0655 f52bcce0 00044e4d 7fff kernel:f4131180 0400 f4050f4c c0271f11 c010478b f889407c f4ba7000 kernel:f416a600 0020 f4075c40 f4050be4 00200246 f4050be4 f4131180 c01672ef kernel: Call Trace: kernel: [c0271f11] schedule_timeout+0x13/0x8b kernel: [c010478b] common_interrupt+0x23/0x28 kernel: [c01672ef] pipe_poll+0x24/0x7f kernel: [c016d53f] do_select+0x370/0x3b9 kernel: [c016daf0] __pollwait+0x0/0xa9 kernel: [c0118a51] default_wake_function+0x0/0x5 last message repeated 4 times kernel: [c017e48d] __getblk+0x14/0x1cd kernel: [c0160960] get_unused_fd_flags+0x55/0xcb kernel: [f9a154ff]
Re: regression: 100% io-wait with 2.6.24-rcX
Am Montag, 7. Januar 2008 schrieb Peter Zijlstra: On Mon, 2008-01-07 at 14:24 +0100, Joerg Platte wrote: This is from: 2.6.24-rc7 kernel: pdflush D f41c2f14 0 18822 2 kernel:f673f000 0046 0286 f41c2f14 f5194ce0 0286 0286 f41c2f14 kernel:00175279 f41c2f6c c0271f6c f5ff363c f5ff3644 c0354a90 c0354a90 kernel:00175279 c0123251 f5194b80 c03546c0 c0271f67 6c666470 00687375 kernel: Call Trace: kernel: [c0271f6c] schedule_timeout+0x6e/0x8b kernel: [c0123251] process_timeout+0x0/0x5 kernel: [c0271f67] schedule_timeout+0x69/0x8b kernel: [c027179a] __sched_text_start+0x3a/0x70 kernel: [c014d34b] congestion_wait+0x4e/0x62 kernel: [c012be2b] autoremove_wake_function+0x0/0x33 kernel: [c014971e] pdflush+0x0/0x1bf kernel: [c01493c6] wb_kupdate+0x8c/0xd1 kernel: [c014971e] pdflush+0x0/0x1bf kernel: [c0149839] pdflush+0x11b/0x1bf kernel: [c014933a] wb_kupdate+0x0/0xd1 kernel: [c012bd71] kthread+0x36/0x5d kernel: [c012bd3b] kthread+0x0/0x5d kernel: [c010493b] kernel_thread_helper+0x7/0x10 kernel: === What filesystem are you using? Here you can see all currently mounted filesystems: /dev/sda6 on / type ext3 (rw,noatime,errors=remount-ro,acl) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) procbususb on /proc/bus/usb type usbfs (rw) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) fusectl on /sys/fs/fuse/connections type fusectl (rw) /dev/sda7 on /tmp type ext2 (rw,noatime,errors=remount-ro,acl) /dev/sda8 on /export type ext3 (rw,noatime,errors=remount-ro,acl) /dev/sda1 on /winxp type ntfs (rw,umask=002,gid=1,nls=utf8) rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) automount(pid4936) on /amnt type autofs (rw,fd=4,pgrp=4936,minproto=2,maxproto=4) automount(pid4965) on /home type autofs (rw,fd=4,pgrp=4965,minproto=2,maxproto=4) nfsd on /proc/fs/nfsd type nfsd (rw) /export/home/jplatte on /home/jplatte type none (rw,bind) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 -- 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.23-rcX SG_GET_SCSI_ID regression?
Am Mittwoch, 3. Oktober 2007 schrieb Joerg Platte:
Hi,
> 2.6.22.8:
> open("/dev/scanner", O_RDWR|O_NONBLOCK|O_EXCL) = 3
> ioctl(3, SG_SET_TIMEOUT, 0xbfe40624)= 0
> ioctl(3, SG_GET_VERSION_NUM, 0x8063fa4) = 0
> ioctl(3, SG_GET_SCSI_ID, 0xbfe405e0)= 0
>
> 2.6.23-rc9:
> open("/dev/scanner", O_RDWR|O_NONBLOCK|O_EXCL) = 3
> ioctl(3, SG_SET_TIMEOUT, 0xbf84a834)= 0
> ioctl(3, SG_GET_VERSION_NUM, 0x8062524) = 0
> ioctl(3, SG_GET_SCSI_ID, 0xbf84a7f0)= -1 ENOTTY (Inappropriate ioctl
> for device)
After some reboots and tests I discovered, that this error occurs only when
the scanner was turned off during system boot and was discovered later by
invoking the following script:
for device in /sys/class/scsi_host/host*/scan ; do
echo "0 - -" > $device
done
With 2.6.22 and before the scanner was fully functional when discovered by a
bus rescan.
regards,
Jörg
--
PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D
PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605
-
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.23-rcX SG_GET_SCSI_ID regression?
Hi,
sane is not able to detect my old SCSI scanner with kernel 2.6.23-rc9. The
scanner was found with 2.6.22.8. According to strace the behavior of the
SG_GET_SCSI_ID ioctl changed:
2.6.22.8:
open("/dev/scanner", O_RDWR|O_NONBLOCK|O_EXCL) = 3
ioctl(3, SG_SET_TIMEOUT, 0xbfe40624)= 0
ioctl(3, SG_GET_VERSION_NUM, 0x8063fa4) = 0
ioctl(3, SG_GET_SCSI_ID, 0xbfe405e0)= 0
2.6.23-rc9:
open("/dev/scanner", O_RDWR|O_NONBLOCK|O_EXCL) = 3
ioctl(3, SG_SET_TIMEOUT, 0xbf84a834)= 0
ioctl(3, SG_GET_VERSION_NUM, 0x8062524) = 0
ioctl(3, SG_GET_SCSI_ID, 0xbf84a7f0)= -1 ENOTTY (Inappropriate ioctl for
device)
Is this an intentional change?
regards,
Jörg
--
PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D
PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605
-
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.23-rcX SG_GET_SCSI_ID regression?
Hi, sane is not able to detect my old SCSI scanner with kernel 2.6.23-rc9. The scanner was found with 2.6.22.8. According to strace the behavior of the SG_GET_SCSI_ID ioctl changed: 2.6.22.8: open(/dev/scanner, O_RDWR|O_NONBLOCK|O_EXCL) = 3 ioctl(3, SG_SET_TIMEOUT, 0xbfe40624)= 0 ioctl(3, SG_GET_VERSION_NUM, 0x8063fa4) = 0 ioctl(3, SG_GET_SCSI_ID, 0xbfe405e0)= 0 2.6.23-rc9: open(/dev/scanner, O_RDWR|O_NONBLOCK|O_EXCL) = 3 ioctl(3, SG_SET_TIMEOUT, 0xbf84a834)= 0 ioctl(3, SG_GET_VERSION_NUM, 0x8062524) = 0 ioctl(3, SG_GET_SCSI_ID, 0xbf84a7f0)= -1 ENOTTY (Inappropriate ioctl for device) Is this an intentional change? regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 - 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.23-rcX SG_GET_SCSI_ID regression?
Am Mittwoch, 3. Oktober 2007 schrieb Joerg Platte: Hi, 2.6.22.8: open(/dev/scanner, O_RDWR|O_NONBLOCK|O_EXCL) = 3 ioctl(3, SG_SET_TIMEOUT, 0xbfe40624)= 0 ioctl(3, SG_GET_VERSION_NUM, 0x8063fa4) = 0 ioctl(3, SG_GET_SCSI_ID, 0xbfe405e0)= 0 2.6.23-rc9: open(/dev/scanner, O_RDWR|O_NONBLOCK|O_EXCL) = 3 ioctl(3, SG_SET_TIMEOUT, 0xbf84a834)= 0 ioctl(3, SG_GET_VERSION_NUM, 0x8062524) = 0 ioctl(3, SG_GET_SCSI_ID, 0xbf84a7f0)= -1 ENOTTY (Inappropriate ioctl for device) After some reboots and tests I discovered, that this error occurs only when the scanner was turned off during system boot and was discovered later by invoking the following script: for device in /sys/class/scsi_host/host*/scan ; do echo 0 - - $device done With 2.6.22 and before the scanner was fully functional when discovered by a bus rescan. regards, Jörg -- PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605 - 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: AMD64 kernel oops
Am Freitag, 16. März 2007 03:06 schrieben Sie: > Check out http://bugzilla.kernel.org/show_bug.cgi?id=8067 which is a > duplicate of http://bugzilla.kernel.org/show_bug.cgi?id=7727 which is > fixed. There is a patch available on the bugzilla if you want to try it > out. Thank you, I'll test this patch as soon as possible. regards, Jörg - 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: AMD64 kernel oops
Am Freitag, 16. März 2007 03:06 schrieben Sie: Check out http://bugzilla.kernel.org/show_bug.cgi?id=8067 which is a duplicate of http://bugzilla.kernel.org/show_bug.cgi?id=7727 which is fixed. There is a patch available on the bugzilla if you want to try it out. Thank you, I'll test this patch as soon as possible. regards, Jörg - 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/
AMD64 kernel oops
Hi! On our file server we have the following problem (the full dmesg output is available at http://www-ds.e-technik.uni-dortmund.de/~jplatte/dmesg.txt ): Unable to handle kernel paging request at 00100108 RIP: [] keyring_destroy+0x32/0x96 PGD 195d33067 PUD 193202067 PMD 0 Oops: 0002 [1] SMP CPU 0 Modules linked in: ppdev lp nfs nfsd exportfs lockd nfs_acl sunrpc button ac battery ipv6 quota_v1 dm_snapshot dm_mirror dm_mod loop tsdev parport_pc parport floppy psmouse pcspkr serio_raw i2c_i801 i2c_core shpchp pci_hotplug e752x_edac edac_mc evdev sg ext3 jbd mbcache ide_cd cdrom sd_mod piix megaraid_mbox scsi_mod megaraid_mm generic ide_core ehci_hcd uhci_hcd tg3 thermal processor fan Pid: 14, comm: events/0 Not tainted 2.6.18-4-amd64 #1 RIP: 0010:[] [] keyring_destroy+0x32/0x96 RSP: 0018:8101f7cd7e30 EFLAGS: 00010217 RAX: 00200200 RBX: 81009c324200 RCX: 81009c324278 RDX: 00100100 RSI: RDI: 804629e0 RBP: 81009c324208 R08: R09: 8101f4a55040 R10: 8101f7cce830 R11: 561c R12: 8101f8cad8c0 R13: 0282 R14: R15: 802eb97d FS: () GS:80521000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 00100108 CR3: 0001e0027000 CR4: 06e0 Process events/0 (pid: 14, threadinfo 8101f7cd6000, task 8101f7cce830) Stack: 81009c324200 81009c324208 8101f8cad8c0 802eba52 80462920 80462928 8024947a ff56 8101f8cad8c0 80245e7b 8101f8c7dd40 Call Trace: [] key_cleanup+0xd5/0xf2 [] run_workqueue+0x94/0xe5 [] worker_thread+0x0/0x122 [] worker_thread+0xf0/0x122 [] default_wake_function+0x0/0xe [] kthread+0xd4/0x107 [] child_rip+0xa/0x12 [] kthread+0x0/0x107 [] child_rip+0x0/0x12 Code: 48 89 42 08 48 89 10 48 c7 41 08 00 02 20 00 48 c7 43 78 00 RIP [] keyring_destroy+0x32/0x96 RSP CR2: 00100108 <3>BUG: soft lockup detected on CPU#0! Call Trace: [] softlockup_tick+0xdb/0xed [] update_process_times+0x42/0x68 [] smp_local_timer_interrupt+0x23/0x47 [] smp_apic_timer_interrupt+0x41/0x47 [] apic_timer_interrupt+0x66/0x6c [] __write_lock_failed+0x9/0x20 [] __down_write_nested+0x12/0x9a [] .text.lock.spinlock+0x11/0x8a [] keyring_publish_name+0x38/0x92 [] keyring_instantiate+0x13/0x18 [] __key_instantiate_and_link+0x46/0xc5 [] keyring_alloc+0x46/0x5e [] alloc_uid_keyring+0x3d/0xa6 [] thread_return+0x0/0xe7 [] alloc_uid+0xd7/0x17e [] set_user+0xf/0x97 [] sys_setresuid+0x15e/0x23b [] system_call+0x7e/0x83 The server is a Fujitsu-Siemens RX-300 S2 with 8 GB RAM and this is the second kernel oops this week. We are using the current stable debian kernel (Linux 2.6.18-4-amd64 #1 SMP Wed Feb 21 14:29:38 UTC 2007 x86_64). Currently, I don't know how to reproduce the oops and compiling and testing a newer kernel is currently not possible. Can this oops be caused by a known and already fixed problem in a newer kernel versions? In this case I would submit a bug to the Debian BTS. Otherwise what can I do to further reproduce and debug this oops? regards, Jörg - 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/
AMD64 kernel oops
Hi! On our file server we have the following problem (the full dmesg output is available at http://www-ds.e-technik.uni-dortmund.de/~jplatte/dmesg.txt ): Unable to handle kernel paging request at 00100108 RIP: [802ec036] keyring_destroy+0x32/0x96 PGD 195d33067 PUD 193202067 PMD 0 Oops: 0002 [1] SMP CPU 0 Modules linked in: ppdev lp nfs nfsd exportfs lockd nfs_acl sunrpc button ac battery ipv6 quota_v1 dm_snapshot dm_mirror dm_mod loop tsdev parport_pc parport floppy psmouse pcspkr serio_raw i2c_i801 i2c_core shpchp pci_hotplug e752x_edac edac_mc evdev sg ext3 jbd mbcache ide_cd cdrom sd_mod piix megaraid_mbox scsi_mod megaraid_mm generic ide_core ehci_hcd uhci_hcd tg3 thermal processor fan Pid: 14, comm: events/0 Not tainted 2.6.18-4-amd64 #1 RIP: 0010:[802ec036] [802ec036] keyring_destroy+0x32/0x96 RSP: 0018:8101f7cd7e30 EFLAGS: 00010217 RAX: 00200200 RBX: 81009c324200 RCX: 81009c324278 RDX: 00100100 RSI: RDI: 804629e0 RBP: 81009c324208 R08: R09: 8101f4a55040 R10: 8101f7cce830 R11: 561c R12: 8101f8cad8c0 R13: 0282 R14: R15: 802eb97d FS: () GS:80521000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 00100108 CR3: 0001e0027000 CR4: 06e0 Process events/0 (pid: 14, threadinfo 8101f7cd6000, task 8101f7cce830) Stack: 81009c324200 81009c324208 8101f8cad8c0 802eba52 80462920 80462928 8024947a ff56 8101f8cad8c0 80245e7b 8101f8c7dd40 Call Trace: [802eba52] key_cleanup+0xd5/0xf2 [8024947a] run_workqueue+0x94/0xe5 [80245e7b] worker_thread+0x0/0x122 [80245f6b] worker_thread+0xf0/0x122 [8027d27d] default_wake_function+0x0/0xe [8023055a] kthread+0xd4/0x107 [80259360] child_rip+0xa/0x12 [80230486] kthread+0x0/0x107 [80259356] child_rip+0x0/0x12 Code: 48 89 42 08 48 89 10 48 c7 41 08 00 02 20 00 48 c7 43 78 00 RIP [802ec036] keyring_destroy+0x32/0x96 RSP 8101f7cd7e30 CR2: 00100108 3BUG: soft lockup detected on CPU#0! Call Trace: IRQ [802a3fec] softlockup_tick+0xdb/0xed [802881df] update_process_times+0x42/0x68 [8026cbd8] smp_local_timer_interrupt+0x23/0x47 [8026d2cc] smp_apic_timer_interrupt+0x41/0x47 [8025904a] apic_timer_interrupt+0x66/0x6c EOI [8025c11d] __write_lock_failed+0x9/0x20 [8025e244] __down_write_nested+0x12/0x9a [8025e915] .text.lock.spinlock+0x11/0x8a [802ebf3a] keyring_publish_name+0x38/0x92 [802ebfa7] keyring_instantiate+0x13/0x18 [802eb1f2] __key_instantiate_and_link+0x46/0xc5 [802ec7c2] keyring_alloc+0x46/0x5e [802ede3d] alloc_uid_keyring+0x3d/0xa6 [8025cc4e] thread_return+0x0/0xe7 [80288581] alloc_uid+0xd7/0x17e [8028ae65] set_user+0xf/0x97 [8028c985] sys_setresuid+0x15e/0x23b [802584d6] system_call+0x7e/0x83 The server is a Fujitsu-Siemens RX-300 S2 with 8 GB RAM and this is the second kernel oops this week. We are using the current stable debian kernel (Linux 2.6.18-4-amd64 #1 SMP Wed Feb 21 14:29:38 UTC 2007 x86_64). Currently, I don't know how to reproduce the oops and compiling and testing a newer kernel is currently not possible. Can this oops be caused by a known and already fixed problem in a newer kernel versions? In this case I would submit a bug to the Debian BTS. Otherwise what can I do to further reproduce and debug this oops? regards, Jörg - 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/
