headers
Borislav Petkov | 1 Jun 2011 09:29
Picon

Re: PROBLEM: udevd appears to loop and use CPU in 2.6.39-git11 (32bit build)

On Wed, Jun 01, 2011 at 01:31:47AM -0400, Chris Davies wrote:
> [1.] One line summary of the problem:    2.6.39-git11 experiences loop on /dev creation and later udevd
loops using CPU
> [2.] Full description of the problem/report:

Great, udev looping rings the big bell here:

There's a user running 2.6.39 fedora kernels and reports the same
issue of udev looping but only when loading a module which fails
loading with -EINVAL. Reportedly, udev keeps trying indefinitely there:
https://bugzilla.kernel.org/show_bug.cgi?id=35522

Anyway, just a datapoint, it could be unrelated.

Thanks.

--

-- 
Regards/Gruss,
    Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Pallav Bose | 1 Jun 2011 20:25
Picon

Re: Disabling Command Completion Coalescing (CCC) in SATA AHCI

On Tue, May 24, 2011 at 1:16 AM, Pallav Bose <pallavbose <at> gmail.com> wrote:
> Another question that I have is regarding my second experiment. It's as follows:
>
> Create a bio structure in my driver and call the __make_request()
> function of the lower level driver. Only one 2560 bytes write request
> is sent from my driver.
>
> Once this write is serviced, an interrupt is generated which is
> intercepted by do_IRQ(). Finally, the function blk_complete_request()
> is called. Keep in mind that we are still in the top half of the
> interrupt handler. Now, we compose another struct bio in
> blk_complete_request() and call the
> __make_request() function. We record a timestamp at this point
> (say T0). When the request completion callback is obtained, we
> record another timestamp (call it T1). The difference - T1 - T0 - is
> always above 1 millisec. This experiment was repeated numerous times,
> and each time, the destination sector affected this difference - T1 - T0.
> It was observed that if the destination sectors are separated by
> approximately 350 sectors, the time difference is about 1.2 millisec
> (never below
> 1 millisec) for requests of size 2560 bytes.
>
> My understanding is that since the destination sectors of consecutive
> requests have been separated by a fairly large amount, by the time the
> next request is issued, the requested sector would be almost below the
> disk head and thus the write should happen immediately and T1 - T0
> should be small (at least < 1 millisec).
>
> The Serial ATA AHCI 1.3 Specification (page 114) states that:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Moyer | 1 Jun 2011 21:51
Picon
Favicon

Re: New driver mtipx2xx submission

"Asai Thambi Samymuthu Pattrayasamy (asamymuthupa) [CONTRACTOR]"
<asamymuthupa <at> micron.com> writes:

> On 5/25/2011 8:36 AM, Jeff Moyer wrote:
>> Asai Thambi S P<asamymuthupa <at> micron.com>  writes:
>>
>>> On 5/11/2011 1:20 PM, Alan Cox wrote:
>>>> So a bigger queue helped (at least in 2006). The AHCI driver can be
>>>> taught your bigger queue easily enough. The question is where with a
>>>> *current* kernel are any remaining bottlenecks if you do that and
> how do
>>>> we fix them.
>>>
>>> Attached image/table shows the performance numbers on current kernel.
>>>
>>> The main objectives of our new mtipx2xx driver are
>>> 	1.) highest performance (see attached image/table),
>>> 	2.) lowest CPU utilization, and
>>
>> Can you collect perf data to show why the ahci driver is taking up so
>> much more CPU for the random I/O case?
>>
>
> Collected the perf data for ahci driver. As the call graph is getting 
> distorted in the email, attaching the perf data call graph report.

Thanks, Asai!  I don't think cfq is the ideal I/O scheduler to be
testing.  Could you run again with deadline and/or noop and see how that
changes your throughput and perf report?  Also, just for completeness,
could you tell us which kernel you ran this against?
(Continue reading)

Permalink | Reply | 19 comments |
headers
Alan Cox | 1 Jun 2011 22:21
Face
Picon

Re: New driver mtipx2xx submission

> Thanks, Asai!  I don't think cfq is the ideal I/O scheduler to be
> testing.  Could you run again with deadline and/or noop and see how that
> changes your throughput and perf report?  Also, just for completeness,
> could you tell us which kernel you ran this against?

How many processors is this system, just looking at the lock contention
which is pretty horrible.

I'd been expecting various red flags in the AHCI/libata/scsi queue code
but it seems at first glance that the block queue stuff is killing us and
the scsi/ata code is a distraction (unless of course its causing a lot of
the lock time)

No-op would be most interesting but the I/O scheduler numbers don't look
pretty.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 15 comments |
headers
David Dillow | 2 Jun 2011 03:21

Re: New driver mtipx2xx submission

On Wed, 2011-06-01 at 15:51 -0400, Jeff Moyer wrote:
> "Asai Thambi Samymuthu Pattrayasamy (asamymuthupa) [CONTRACTOR]"
> <asamymuthupa <at> micron.com> writes:
> > Collected the perf data for ahci driver. As the call graph is getting 
> > distorted in the email, attaching the perf data call graph report.
> 
> Thanks, Asai!  I don't think cfq is the ideal I/O scheduler to be
> testing.  Could you run again with deadline and/or noop and see how that
> changes your throughput and perf report?  Also, just for completeness,
> could you tell us which kernel you ran this against?

Did the cc list get trimmed, or was the message too big for vger? It
didn't seem to make it to the list...

If it was too big, could someone trim it down a bit and repost?
Inquiring minds want to play along at home...

Thanks!

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Connor Hansen | 2 Jun 2011 07:52
Picon

[PATCH] ide-cd: signedness warning fix again

One of the legit warnings 'make W=3 drivers/ide/ide-cd.c'
generates is:
drivers/ide/ide-cd.c: In function ide_cd_do_request
drivers/ide/ide-cd.c:828:2: warning: conversion to int from \
unsigned int may change the sign of the result
drivers/ide/ide-cd.c:833:2: warning: conversion to int from \
unsigned int may change the sign of the result

nsectors is declared int, should be unsigned int.

blk_rq-sectors() returns unsigned int, and ide_complete_rq
expects unsigned int as well.  Fixes both warnings.

Signed-off-by: Connor Hansen <cmdkhh <at> gmail.com>
---
 drivers/ide/ide-cd.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index 5d17ab4..0a61f63 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
 <at>  <at>  -778,7 +778,8  <at>  <at>  static ide_startstop_t ide_cd_do_request(ide_drive_t *drive, struct request *rq,
 					sector_t block)
 {
 	struct ide_cmd cmd;
-	int uptodate = 0, nsectors;
+	int uptodate = 0;
+	unsigned int nsectors;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marc MERLIN | 2 Jun 2011 17:34

My laptop HD went RO, WRITE FPDMA QUEUED / SECURITY FREEZE LOCK?

Howdy,

My laptop's hd, after over a year of good behaviour, went read only
last night, and this is what I got in dmesg.

I power cycled the laptop, but I wasn't able to reboot properly.
I then tried again with a boot cdrom and I was able to mount my partitions
and write to them.
After another reboot, the system came back online.

Any idea what happened, and if it's a random burp, or if it's likely to
happen again and I should swap the drive?

Thanks,
Marc

ata1: SError: { RecovData UnrecovData Handshk }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/08:00:66:92:38/00:00:0d:00:00/40 tag 0 ncq 4096 out
         res 50/00:08:3d:ab:54/00:00:0e:00:00/40 Emask 0x10 (ATA bus error)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/08:08:56:74:74/00:00:0c:00:00/40 tag 1 ncq 4096 out
         res 50/00:08:3d:ab:54/00:00:0e:00:00/40 Emask 0x10 (ATA bus error)
ata1.00: status: { DRDY }
ata1.00: failed command: READ FPDMA QUEUED
ata1.00: cmd 60/10:10:d2:9a:ec/00:00:09:00:00/40 tag 2 ncq 8192 in
         res 50/00:08:3d:ab:54/00:00:0e:00:00/40 Emask 0x10 (ATA bus error)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
(Continue reading)

Permalink | Reply | 0 comments |
headers
BU66ER BAD6ER | 6 Jun 2011 12:09
Picon

Re: Seagate hard disk firmware issue

I replaced that one, too, and got a Western Digital "Green" 2TB.

No funny noises, and it works excellent, so-far!

Thanks for your input!

On Sun, May 1, 2011 at 7:18 PM, gene heskett <gheskett <at> wdtv.com> wrote:
> On Sunday, May 01, 2011 01:16:34 PM BU66ER BAD6ER did opine:
>
>> On Sat, Apr 30, 2011 at 2:08 PM, gene heskett <gheskett <at> wdtv.com> wrote:
>> > On Saturday, April 30, 2011 07:56:21 AM BU66ER BAD6ER did opine:
>> > This <linux-ide <at> vger.kernel.org> is a mailing list. �WTH when I click
>> > on reply-to-list, do I always have to copy/paste the lists address in
>> > the To: line? �fscking PIMA!
>> >
>> > More below, where it should be.
>> >
>> >> Hi,
>> >>
>> >> Some time ago, I returned my hard disk and got a new one. Lately, I'm
>> >> having performance issues again and I suspect there is a hardware
>> >> error again like last time. If you could confirm this I would be most
>> >> grateful.
>> >>
>> >> Thanks in advance!
>> >>
>> >> # smartctl -a /dev/sdb
>> >> smartctl 5.41 2011-03-16 r3296
>> >> [x86_64-unknown-linux-gnu-2.6.38-2-amd64] (local build)
>> >> Copyright (C) 2002-11 by Bruce Allen,
(Continue reading)

Permalink | Reply | 1 comment |
headers
gene heskett | 6 Jun 2011 12:36
Favicon

Re: Seagate hard disk firmware issue

On Monday, June 06, 2011 06:34:05 AM BU66ER BAD6ER did opine:

> I replaced that one, too, and got a Western Digital "Green" 2TB.
> 
> No funny noises, and it works excellent, so-far!
> 
> Thanks for your input!
> 
I appreciate being told that my advice was good, but please clip your 
replies.

[...]

Cheers, gene
--

-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Maybe Computer Science should be in the College of Theology.
		-- R. S. Barton
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Manuel Reimer | 6 Jun 2011 20:51
Picon
Favicon

WRITE DMA EXT failures with JM20330 based sata2ide

Hello,

I already posted this to the file-systems list, but as this might be the wrong 
list, I'm copying this request to here.

I've converted a 1,5TB SATA drive to IDE to run it on a UDMA100 IDE controller.

Low traffic applications work well. I'm able to create a xfs or ext4 filesystem 
and even a fsck runs without problems and without causing error messages on dmesg.

If I start to copy a file with some gigabytes in size to the new disc, then 
errors like the following keep coming on dmesg:

ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata2.00: failed command: WRITE DMA EXT
ata2.00: cmd 35/00:00:30:07:8a/00:04:57:00:00/e0 tag 0 dma 524288 out
          res 40/00:ff:00:00:00/00:00:00:00:00/40 Emask 0x4 (timeout)
ata2.00: status: { DRDY }
ata2: link is slow to respond, please be patient (ready=0)
ata2: device not ready (errno=-16), forcing hardreset
ata2: soft resetting link
ata2.00: configured for UDMA/25
ata2.00: device reported invalid CHS sector 0
ata2: EH complete

The error repeats many times.

Copying a big file from this disc to another location on the disc, then this 
also works without errors (maybe because of the slow down of the mixed 
read/write access). This copy from disc to same disc also failed before I
(Continue reading)

Permalink | Reply | 2 comments |

Gmane