headers
Alan Cox | 1 Aug 2007 01:56
Picon

Re: [PATCH 2/2] [POWERPC] MPC8349E-mITX: use platform IDE driver for CF interface

> The hardware is called (E)IDE, the protocol is called ATA.
> Or that's what I was told -- I think there's some historic
> revisionism involved, too.

ATA is the interface and standards for the ANSI standards based disk
attachment. IDE "Integrated Drive Electronics" is a marketing name used
to cover all sorts of ST412 compatible-ish early interfaces that moved
the brains onto the disk. IDE doesn't really mean much but "brains on
disk", ATA is a real standard.
-
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
Alan Cox | 1 Aug 2007 02:12
Picon

Re: Access beyond end of device

On Tue, 31 Jul 2007 15:15:46 -0300
"Luiz Fernando N. Capitulino" <lcapitulino <at> mandriva.com.br> wrote:

> Em Tue, 31 Jul 2007 15:04:14 -0300
> "Luiz Fernando N. Capitulino" <lcapitulino <at> mandriva.com.br> escreveu:
> 
> |  Since I've started using the pata_via driver in 2.6.22, I'm getting
> | zillions of these messages:
> | 
> | """
> | attempt to access beyond end of device
> | sda: rw=0, want=156367809, limit=156365903
> | printk: 22 messages suppressed
> | Buffer I/O error on device sda1, logical block 78183872

Does your disk have a host protected area set and if so are you telling
libata to disable it ?
-
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
Alan Cox | 1 Aug 2007 02:41
Picon

Early ATA devices

So I've been doing a scan of the code versus the early ATA specifications
(English translation not the original Latin ;))

I've found a couple of problem cases we don't deal with but I'm not sure
matter, and an inconsistency

#1	We assume identify works. Early ATA actually lists this command
as optional
#2	We don't allow for INIT_DEV_PARAMS failing which it may do on
some early IDE pre ATA devices

and the inconsistency

We check ATA < 4 || non-LBA capable when deciding whether to issue
INIT_DEV_PARAMS. ATA 4+ however mandate LBA so the second case isn't
theoretically at least possible.

Aside from those cases the command issue (but not the detection paths)
appear to be clean for everything from ST412 upwards providing a drive is
being used in 16 head mode and does its own write precompensation
selection.

So in theory we can persuade libata to drive original MFM/RLL disks with
relatively few changes
-
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
(Continue reading)

Permalink | Reply | 7 comments |
headers
Craig Block | 1 Aug 2007 03:06
Picon
Favicon

Re: IRQ Delivery Problem for MCP65

--- Bartlomiej Zolnierkiewicz <bzolnier <at> gmail.com> wrote:

> > --- Craig Block <chblock3 <at> yahoo.com> wrote:

> > I'm having trouble getting Linux to see any hard drives on an ASUS M2N-X
> > motherboard with an MCP65 (nForce 520) chipset.  When the kernel probes the
> > AHCI controllers, it hangs for a minute or so on each one and returns the
> > following;
> >
> > ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> 
> I googled for some more info about similar issues and found very similar
> problem being discussed on Gentoo forum:
> 
> The important part is here:
>
> "when I disabled Message Signaled Interrupts (MSI and MSI-X) under "Bus
> Options" in the kernel, the problem magically went away (disabling MSI)"
> 
> which indicates IRQ routing problems (as suspected from dmesg output and also
> stated by Tejun).  Have you already tried disabling MSI IRQs with "pci=nomsi"
> (not "nomsi") or even completely disabling CONFIG_PCI_MSI support?

Thanks a ton, building the kernel with PCI_MSI not set did the trick. 
Attempting to disable MSI using pci=nomsi at the boot prompt did not eliminate
the problem.  I had to build the kernel without MSI support.  There's a few
interesting differences in the dmesg output with "PCI_MSI=y" and PCI_MSI not
set;

With PCI_MSI not set;
(Continue reading)

Permalink | Reply | 752 comments |
headers
Tejun Heo | 1 Aug 2007 05:20
Picon

Re: [patch 2/4] Expose Power Management Policy option to users

Kristen Carlson Accardi wrote:
> So at current rate of development and kernel release schedule, the best
> possible scenario is still 6 months away - whereas this patchset is already 
> tested and ready for merging now.

The best possible scenario is .24-rc1 merge window with or without
waiting.  With waiting, the best possible scenario is harder to achieve tho.

> Out of tree patches don't work.  Nobody tests them.  A module parameter
> will not work - we need to be able to expose the sysfs interface so that
> users may chose to turn the feature off and on at will - mainly according
> to their usage.  For example, at boot time - you want ALPM off to maximize
> performance.  Lets say when you are plugged into the wall socket, you leave
> it off, but then when you go on battery power you would want to enable it.

You can turn on and off dynamically using a module parameter.  Although
it's not a pretty interface, it should work as an interim solution if we
absolutely must merge ALPM now.

>> Due to the generosity of the ATA committee, we have, by default, at
>> least two ways to achieve link PS - HIPS and DIPS.  I dunno why but
>> someone thought we needed two.  And then, ahci people thought automatic
> 
> They thought we needed two because sometimes the device knows when it
> will be idle faster than the host can. this is why ALPM can determine
> idleness faster than any software algorithm on the host cpu can.  You
> can use ALPM without having HIPM.  You can also use it without having 
> DIPM.

I see.  I get that one way is better than another in some way.  I'm just
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tejun Heo | 1 Aug 2007 05:24
Picon

Re: [patch 2/4] Expose Power Management Policy option to users

Kristen Carlson Accardi wrote:
>> I don't think the interface you're suggesting is a good one.  Do you?
> 
> I think if it's applicable to SCSI at all it is fine.  If it is not, then
> I think we need to make do with the interface we are given.  I do not think
> we should hold up a feature for libata sysfs integration.

Well, I guess we'll have to agree to disagree here and leave the
decision to James and Jeff.

>>> I can assert that I think ALPM is a good idea,
>>> because I've never had a report of it causing problems.  Windows has 
>>> been using this feature for a very long time - and you have to admit that
>>> they have a pretty large market share.  Nobody is complaining about ALPM
>>> increasing device malfunction, so unless you have proof it seems insane
>>> to nak due to this. 
>> Is ALPM enabled by default?  How do they deal with the performance
>> degradation?
> 
> I believe so, but I'm obviously not privvy to their implementation details.

It would be *really* great if we can find more about how they do it.
How and when it's enabled and on which systems.  Is it possible to find
this out?

--

-- 
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tejun Heo | 1 Aug 2007 05:38
Picon

Re: [PATCH libata-dev#upstream 2/2] libata: move EH repeat reporting into ata_eh_report()

Mikael Pettersson wrote:
> This is with both 1/2 and 2/2 applied, with only 2/2 applied the
> "EH pending ..." is gone and the new "exception ... frozen" don't appear.

Thanks.  Right, I'll drop the first patch.

--

-- 
tejun
-
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
Tejun Heo | 1 Aug 2007 05:46
Picon

Re: errors on shutdown with PMP

Hello,

Marc Bejarano wrote:
>>Counters don't look too friendly.  Do you happen to have another drive
>>of the same model?
> 
> about 100 or so of them ;)

Cool.

>>If so, can you post smartctl -a of the drive?
> 
> here are the other two drives in the unhappy lv:
[--snip--]
>   5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always
>      -       15
> 198 Offline_Uncorrectable   0x0010   100   100   000    Old_age  
> Offline      -       0
[--snip--]
>   5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always
>      -       0
> 198 Offline_Uncorrectable   0x0010   100   100   000    Old_age  
> Offline      -       0

Offline uncorrectable is zero on both drives.  I think it's likely that
the not-responding drive is faulty.  Note that write command usually
complete right after it fills the buffer, so write errors often show up
on cache flush.  Also, write failure usually means that even
reallocation failed and the drive is in pretty bad shape.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tejun Heo | 1 Aug 2007 05:50
Picon

Re: IRQ Delivery Problem for MCP65

[cc'ing linux-pci and quoting whole body.]

Any ideas?

Craig Block wrote:
> --- Bartlomiej Zolnierkiewicz <bzolnier <at> gmail.com> wrote:
> 
>>> --- Craig Block <chblock3 <at> yahoo.com> wrote:
> 
>>> I'm having trouble getting Linux to see any hard drives on an ASUS M2N-X
>>> motherboard with an MCP65 (nForce 520) chipset.  When the kernel probes the
>>> AHCI controllers, it hangs for a minute or so on each one and returns the
>>> following;
>>>
>>> ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
>> I googled for some more info about similar issues and found very similar
>> problem being discussed on Gentoo forum:
>>
>> The important part is here:
>>
>> "when I disabled Message Signaled Interrupts (MSI and MSI-X) under "Bus
>> Options" in the kernel, the problem magically went away (disabling MSI)"
>>
>> which indicates IRQ routing problems (as suspected from dmesg output and also
>> stated by Tejun).  Have you already tried disabling MSI IRQs with "pci=nomsi"
>> (not "nomsi") or even completely disabling CONFIG_PCI_MSI support?
> 
> Thanks a ton, building the kernel with PCI_MSI not set did the trick. 
> Attempting to disable MSI using pci=nomsi at the boot prompt did not eliminate
> the problem.  I had to build the kernel without MSI support.  There's a few
(Continue reading)

Permalink | Reply | 751 comments |
headers
Al Boldi | 1 Aug 2007 06:22

[PATCH] libata Kconfig: Allow libata to be selected from within the SCSI submenu


Move libata Kconfig sourcing from the drivers Kconfig into the SCSI Kconfig.

This allows the user to quickly select additional disk/tape/cdrom support 
from within the same menu.

Signed-off-by: Al Boldi <a1426z <at> gawab.com>
Cc: Alan Cox <alan <at> lxorguk.ukuu.org.uk>
---
--- a/drivers/Kconfig	2007-05-02 17:25:30.000000000 +0300
+++ b/drivers/Kconfig	2007-08-01 06:33:13.000000000 +0300
 <at>  <at>  -22,8 +22,6  <at>  <at>  source "drivers/ide/Kconfig"

 source "drivers/scsi/Kconfig"

-source "drivers/ata/Kconfig"
-
 source "drivers/cdrom/Kconfig"

 source "drivers/md/Kconfig"
--- a/drivers/scsi/Kconfig	2007-07-09 06:38:37.000000000 +0300
+++ b/drivers/scsi/Kconfig	2007-08-01 06:46:42.000000000 +0300
 <at>  <at>  -7,6 +7,8  <at>  <at>  config RAID_ATTRS
 	---help---
 	  Provides RAID

+source "drivers/ata/Kconfig"
+
 config SCSI
 	tristate "SCSI device support"
(Continue reading)

Permalink | Reply | 0 comments |

Gmane