On 2/25/07, Patrick Ale [EMAIL PROTECTED] wrote:
On 2/25/07, Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:
Dobri dan (I think, I am learning croatian and got told by a friend
this is the polish way of saying it).
Anyway,
I guess it will take a bit before I can do this test for you,
I CC'ed linux-ide to see if they think the reported error was really innocent:
Question: does this error report suggest that a disk could be corrupted?
This SATA disk is part of an md raid and no error was reported by md.
[937567.332751] ata3.00: exception Emask 0x10 SAct 0x0 SErr 0x4190002
Channel redirect and AHCI mode enable programmings are done via PCI
quirk for both probe and resume paths. Drop duplicate and possibly
unsafe device programming from pata_jmicron().
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/pata_jmicron.c | 32 +---
Reimplement jmicron ATA quirk.
* renamed to quirk_jmicron_ata()
* quirk is invoked only for the affected controllers
* programming is stricter. e.g. conf5 bit24 is cleared if
unnecessary.
* code factored for readability
* JMB360 and JMB368 are programmed into proper mode
Verified on JMB360,
Make jmiron_ata quirk update pdev-class after programming the device
and update ahci and pata_jmicron such that they match class code
instead of checking function number manually. For ahci, it matches
for vendor and class. For pata_jmicron, it matches vendor, device and
class as IDE class isn't
On Mon, Feb 26, 2007 at 04:33:37PM +1100, Neil Brown wrote:
Do we want a path in the other direction to handle write errors? The
file system could say Don't worry to much if this block cannot be
written, just return an error and I will write it somewhere else?
This might allow md not to fail
Alan wrote:
the new location. I believe this should be always true, so presumably
with all modern disk drives a write error should mean something very
serious has happend.
Not quite that simple.
I think that write errors are normally quite serious, but there are exceptions
which might
On Mon, 26 Feb 2007 02:41:22 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Bartlomiej Zolnierkiewicz wrote:
Why can't libata do the right thing and just send IDENTIFY command
to the slave device first?
That's my plan B. I'm just not sure whether it would do any good, would it?
Should find
Hello, I wrote:
Contains: IRQ-ack fix for ICH chipsets (Albert Lee), ide-floppy
unformatted
media fix (Alan Cox), more fixes for IDE PCI drivers (Sergei Shtylyov),
new driver for Toshiba Cell Reference Board (Kou Ishizaki kou.ishizaki
at toshiba.co.jp) and a bunch of rather obvious
On Monday 26 February 2007, Sergei Shtylyov wrote:
Hello, I wrote:
Contains: IRQ-ack fix for ICH chipsets (Albert Lee), ide-floppy
unformatted
media fix (Alan Cox), more fixes for IDE PCI drivers (Sergei Shtylyov),
new driver for Toshiba Cell Reference Board (Kou Ishizaki kou.ishizaki
While Andrew and -mm are taking a bit of a break...
I've uploaded a patch file of the libata PATA working tree versus
2.6.20-mm2 to
http://zeniv.linux.org.uk/~alan/IDE
2.6.20-mm2-ac1 has the cable detect method, the identify slave first
change, and assorted core cleanups to methods like
Alan wrote:
I think that this is mostly true, but we also need to balance this against the
need for higher levels to get a timely response. In a really large IO, a naive
retry of a very large write could lead to a non-responsive system for a very
large time...
And losing the I/O could
Theodore Tso wrote:
In any case, the reason why I bring this up is that it would be really
nice if there was a way with a single laptop drive to be able to do
snapshots and background fsck's without having to use initrd's with
device mapper.
This is a major part of why I've been trying to
Hi,
on my laptop (noname; MSI hardware) system it seems that the SATA controller
causes many trouble, at least it is running stable but the performance is
bad. When copying data from a dvd to hard disk the system reacts really slow
so it is almost not usable. I got up to 80% iowaits on top
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm
15 matches
Mail list logo
