linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [regression] 2.6.37-rc5: scsi_eh_11 CPU loop
@ 2010-12-20 10:05 Martin Steigerwald
  2010-12-20 17:12 ` Tejun Heo
  0 siblings, 1 reply; 4+ messages in thread
From: Martin Steigerwald @ 2010-12-20 10:05 UTC (permalink / raw)
  To: linux-kernel, linux-ide, linux-scsi

[-- Attachment #1: Type: text/plain, Size: 7130 bytes --]

Hi!

top - 10:49:07 up 3 days, 14:24,  8 users,  load average: 2.31, 2.62, 2.28
Tasks: 198 total,   2 running, 194 sleeping,   0 stopped,   2 zombie
Cpu(s):  6.8%us, 93.2%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  
0.0%st
Mem:   2073660k total,  1941152k used,   132508k free,   153876k buffers
Swap:  4000180k total,   243452k used,  3756728k free,   676612k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                               
  735 root      20   0     0    0    0 R 85.2  0.0 137:28.94 scsi_eh_11

I don't see anything in dmesg. Everything appears to work as normal, 
except for the slowness. Which got a bit better upon renicing scsi_eh_11 
to 19 (not knowing whether its really safe, but it works for now).

Interrupts appear to be within usual range as well:

martin@shambhala:~> vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----
cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id 
wa
 2  0 243052  88528 154520 677228   10   28   171   374  416  195 36 20 38  
6
 3  0 243052  88512 154520 677228    0    0     0     0 1471  992 45 55  0  
0
 2  0 243052  88324 154520 677228    0    0     0     0 1181  985 49 51  0  
0
 3  0 243052  88932 154520 677228    0    0     0     0 1339 1672 46 54  0  
0
 2  0 243052  88900 154520 677228    0    0     0    44 1222 1327 50 50  0  
0
 3  0 243052  88900 154520 677228    0    0     0     0 1216 1409 48 52  0  
0

Kernel in use:

martin@shambhala:~> cat /proc/version
Linux version 2.6.37-rc6-tp42-00009-gb3444d1 (martin@shambhala) (gcc 
version 4.4.5 (Debian 4.4.5-8) ) #6 PREEMPT Thu Dec 16 19:25:32 CET 2010

I never saw this with 2.6.36 or 2.7.37-rc3.

I am using a Delock PCMCIA eSATA adapter with Silicon Image controller 
from time to time. Yesterday evening for example. Maybe it has to do with 
removing it again. Well it got scsi11 for one of its port:

Dec 19 21:56:24 shambhala kernel: pcmcia_socket pcmcia_socket0: pccard: 
CardBus card inserted into slot 0
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: [1095:3512] type 0 
class 0x000180
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: reg 10: [io  
0x0000-0x0007]
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: reg 14: [io  
0x0000-0x0003]
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: reg 18: [io  
0x0000-0x0007]
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: reg 1c: [io  
0x0000-0x0003]
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: reg 20: [io  
0x0000-0x000f]
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: reg 24: [mem 
0x00000000-0x000001ff]
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: reg 30: [mem 
0x00000000-0x0007ffff pref]
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: supports D1 D2
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: BAR 6: assigned [mem 
0xeff80000-0xefffffff pref]
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: BAR 5: assigned [mem 
0xcffffe00-0xcfffffff]
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: BAR 5: set to [mem 
0xcffffe00-0xcfffffff] (PCI address [0xcffffe00-0xcfffffff])
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: BAR 4: assigned [io  
0x8cf0-0x8cff]
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: BAR 4: set to [io  
0x8cf0-0x8cff] (PCI address [0x8cf0-0x8cff])
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: BAR 0: assigned [io  
0x8ce8-0x8cef]
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: BAR 0: set to [io  
0x8ce8-0x8cef] (PCI address [0x8ce8-0x8cef])
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: BAR 2: assigned [io  
0x8ce0-0x8ce7]
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: BAR 2: set to [io  
0x8ce0-0x8ce7] (PCI address [0x8ce0-0x8ce7])
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: BAR 1: assigned [io  
0x8cdc-0x8cdf]
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: BAR 1: set to [io  
0x8cdc-0x8cdf] (PCI address [0x8cdc-0x8cdf])
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: BAR 3: assigned [io  
0x8cd8-0x8cdb]
Dec 19 21:56:24 shambhala kernel: pci 0000:03:00.0: BAR 3: set to [io  
0x8cd8-0x8cdb] (PCI address [0x8cd8-0x8cdb])
Dec 19 21:56:24 shambhala kernel: sata_sil 0000:03:00.0: enabling device 
(0000 -> 0003)
Dec 19 21:56:24 shambhala kernel: sata_sil 0000:03:00.0: PCI INT A -> 
Link[LNKA] -> GSI 11 (level, low) -> IRQ 11
Dec 19 21:56:24 shambhala kernel: sata_sil 0000:03:00.0: Applying R_ERR on 
DMA activate FIS errata fix
Dec 19 21:56:24 shambhala kernel: sata_sil 0000:03:00.0: setting latency 
timer to 64
Dec 19 21:56:24 shambhala kernel: scsi11 : sata_sil
Dec 19 21:56:24 shambhala kernel: scsi12 : sata_sil
Dec 19 21:56:24 shambhala kernel: ata9: SATA max UDMA/100 mmio 
m512@0xcffffe00 tf 0xcffffe80 irq 11
Dec 19 21:56:24 shambhala kernel: ata10: SATA max UDMA/100 mmio 
m512@0xcffffe00 tf 0xcffffec0 irq 11
Dec 19 21:56:24 shambhala kernel: ata9: SATA link down (SStatus 0 SControl 
310)
Dec 19 21:56:24 shambhala kernel: ata10: SATA link down (SStatus 0 
SControl 310)
Dec 19 21:56:27 shambhala kernel: ata9: hard resetting link
Dec 19 21:56:30 shambhala kernel: ata9: SATA link up 1.5 Gbps (SStatus 113 
SControl 310)
Dec 19 21:56:30 shambhala kernel: ata9.00: ATA-8: Hitachi HTS545050B9A300, 
PB4OC60G, max UDMA/133
Dec 19 21:56:30 shambhala kernel: ata9.00: 976773168 sectors, multi 0: 
LBA48 NCQ (depth 0/32)
Dec 19 21:56:30 shambhala kernel: ata9.00: configured for UDMA/100
Dec 19 21:56:30 shambhala kernel: ata9: EH complete
Dec 19 21:56:30 shambhala kernel: scsi 11:0:0:0: Direct-Access     ATA      
Hitachi HTS54505 PB4O PQ: 0 ANSI: 5
Dec 19 21:56:30 shambhala kernel: sd 11:0:0:0: Attached scsi generic sg2 
type 0
Dec 19 21:56:30 shambhala kernel: sd 11:0:0:0: [sdb] 976773168 512-byte 
logical blocks: (500 GB/465 GiB)
Dec 19 21:56:30 shambhala kernel: sd 11:0:0:0: [sdb] Write Protect is off
Dec 19 21:56:30 shambhala kernel: sd 11:0:0:0: [sdb] Mode Sense: 00 3a 00 
00
Dec 19 21:56:30 shambhala kernel: sd 11:0:0:0: [sdb] Write cache: enabled, 
read cache: enabled, doesn't support DPO
Dec 19 21:56:30 shambhala kernel: sdb: sdb1 sdb3
Dec 19 21:56:30 shambhala kernel: sd 11:0:0:0: [sdb] Attached SCSI disk

Removal appeared to be fine:

Dec 19 23:10:34 shambhala kernel: ata9.00: disabled
Dec 19 23:10:34 shambhala kernel: sd 11:0:0:0: [sdb] Synchronizing SCSI 
cache
Dec 19 23:10:34 shambhala kernel: sd 11:0:0:0: [sdb]  Result: 
hostbyte=0x04 driverbyte=0x00
Dec 19 23:10:34 shambhala kernel: sd 11:0:0:0: [sdb] Stopping disk
Dec 19 23:10:34 shambhala kernel: sd 11:0:0:0: [sdb] START_STOP FAILED
Dec 19 23:10:34 shambhala kernel: sd 11:0:0:0: [sdb]  Result: 
hostbyte=0x04 driverbyte=0x00
Dec 19 23:10:34 shambhala kernel: sata_sil 0000:03:00.0: PCI INT A 
disabled

Any hints on what to try to get more information? I keep the ThinkPad T42 
running for a while to wait for some hints.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [regression] 2.6.37-rc5: scsi_eh_11 CPU loop
  2010-12-20 10:05 [regression] 2.6.37-rc5: scsi_eh_11 CPU loop Martin Steigerwald
@ 2010-12-20 17:12 ` Tejun Heo
  2010-12-21 10:31   ` Martin Steigerwald
  0 siblings, 1 reply; 4+ messages in thread
From: Tejun Heo @ 2010-12-20 17:12 UTC (permalink / raw)
  To: Martin Steigerwald; +Cc: linux-kernel, linux-ide, linux-scsi

Hello,

On 12/20/2010 11:05 AM, Martin Steigerwald wrote:
> Hi!
> 
> top - 10:49:07 up 3 days, 14:24,  8 users,  load average: 2.31, 2.62, 2.28
> Tasks: 198 total,   2 running, 194 sleeping,   0 stopped,   2 zombie
> Cpu(s):  6.8%us, 93.2%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  
> 0.0%st
> Mem:   2073660k total,  1941152k used,   132508k free,   153876k buffers
> Swap:  4000180k total,   243452k used,  3756728k free,   676612k cached
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                               
>   735 root      20   0     0    0    0 R 85.2  0.0 137:28.94 scsi_eh_11
> 
> I don't see anything in dmesg. Everything appears to work as normal, 
> except for the slowness. Which got a bit better upon renicing scsi_eh_11 
> to 19 (not knowing whether its really safe, but it works for now).
> 
> Interrupts appear to be within usual range as well:

Can you please apply the following patch, trigger the problem and
attach the kernel log?

diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 5e59050..c748b5a 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -888,12 +888,19 @@ void ata_eh_fastdrain_timerfn(unsigned long arg)
  */
 static void ata_eh_set_pending(struct ata_port *ap, int fastdrain)
 {
+	static int xxx;
 	int cnt;

 	/* already scheduled? */
 	if (ap->pflags & ATA_PFLAG_EH_PENDING)
 		return;

+	if (!(ap->pflags & ATA_PFLAG_LOADING) && xxx < 16) {
+		ata_port_printk(ap, KERN_WARNING, "XXX ata_eh_set_pending()\n");
+		dump_stack();
+		xxx++;
+	}
+
 	ap->pflags |= ATA_PFLAG_EH_PENDING;

 	if (!fastdrain)

-- 
tejun

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [regression] 2.6.37-rc5: scsi_eh_11 CPU loop
  2010-12-20 17:12 ` Tejun Heo
@ 2010-12-21 10:31   ` Martin Steigerwald
  2010-12-21 11:03     ` Tejun Heo
  0 siblings, 1 reply; 4+ messages in thread
From: Martin Steigerwald @ 2010-12-21 10:31 UTC (permalink / raw)
  To: Tejun Heo; +Cc: linux-kernel, linux-ide, linux-scsi

[-- Attachment #1: Type: Text/Plain, Size: 2227 bytes --]

Am Monday 20 December 2010 schrieb Tejun Heo:
> Hello,
> 
> On 12/20/2010 11:05 AM, Martin Steigerwald wrote:
> > Hi!
> > 
> > top - 10:49:07 up 3 days, 14:24,  8 users,  load average: 2.31, 2.62,
> > 2.28 Tasks: 198 total,   2 running, 194 sleeping,   0 stopped,   2
> > zombie Cpu(s):  6.8%us, 93.2%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,
> >  0.0%si, 0.0%st
> > Mem:   2073660k total,  1941152k used,   132508k free,   153876k
> > buffers Swap:  4000180k total,   243452k used,  3756728k free,  
> > 676612k cached
> > 
> >   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> >   735 root      20   0     0    0    0 R 85.2  0.0 137:28.94
> >   scsi_eh_11
> > 
> > I don't see anything in dmesg. Everything appears to work as normal,
> > except for the slowness. Which got a bit better upon renicing
> > scsi_eh_11 to 19 (not knowing whether its really safe, but it works
> > for now).
> 
> > Interrupts appear to be within usual range as well:

> Can you please apply the following patch, trigger the problem and
> attach the kernel log?
> 
> diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
> index 5e59050..c748b5a 100644
[...]
> 
> +	if (!(ap->pflags & ATA_PFLAG_LOADING) && xxx < 16) {
> +		ata_port_printk(ap, KERN_WARNING, "XXX ata_eh_set_pending()\n");
> +		dump_stack();
> +		xxx++;
> +	}
> +

I will do so with my next kernel compile - likely rc7 if it comes out 
before Christmas.

As I do not know what exactly triggers it, it can take a while till I 
experience it again. I hope to be able to trigger it by inserting and 
removing the PCMCIA eSATA adapter lots of times. As the bug happened, I 
forgot to vgchange -an the LVM on the external drive. That might be or 
might not be related to triggering the issue. I will try this as well.

Reported-as: https://bugzilla.kernel.org/show_bug.cgi?id=25392

Might make sense to switch this bugzilla report to mail. Or use the 
bugzilla. Or just use the bugzilla for tracking and continue using mail. 
I'll do whatever suits you best (but prefer mail).

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [regression] 2.6.37-rc5: scsi_eh_11 CPU loop
  2010-12-21 10:31   ` Martin Steigerwald
@ 2010-12-21 11:03     ` Tejun Heo
  0 siblings, 0 replies; 4+ messages in thread
From: Tejun Heo @ 2010-12-21 11:03 UTC (permalink / raw)
  To: Martin Steigerwald; +Cc: linux-kernel, linux-ide, linux-scsi

Hello,

On Tue, Dec 21, 2010 at 11:31:15AM +0100, Martin Steigerwald wrote:
> > diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
> > index 5e59050..c748b5a 100644
> [...]
> > 
> > +	if (!(ap->pflags & ATA_PFLAG_LOADING) && xxx < 16) {
> > +		ata_port_printk(ap, KERN_WARNING, "XXX ata_eh_set_pending()\n");
> > +		dump_stack();
> > +		xxx++;
> > +	}
> > +
> 
> I will do so with my next kernel compile - likely rc7 if it comes out 
> before Christmas.
> 
> As I do not know what exactly triggers it, it can take a while till I 
> experience it again. I hope to be able to trigger it by inserting and 
> removing the PCMCIA eSATA adapter lots of times. As the bug happened, I 
> forgot to vgchange -an the LVM on the external drive. That might be or 
> might not be related to triggering the issue. I will try this as well.
> 
> Reported-as: https://bugzilla.kernel.org/show_bug.cgi?id=25392
> 
> Might make sense to switch this bugzilla report to mail. Or use the 
> bugzilla. Or just use the bugzilla for tracking and continue using mail. 
> I'll do whatever suits you best (but prefer mail).

I don't care either way.  Just ping me whenever you hit the problem
again.

Thanks.

-- 
tejun

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2010-12-21 11:03 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-20 10:05 [regression] 2.6.37-rc5: scsi_eh_11 CPU loop Martin Steigerwald
2010-12-20 17:12 ` Tejun Heo
2010-12-21 10:31   ` Martin Steigerwald
2010-12-21 11:03     ` Tejun Heo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).