Albert Lee wrote:
Alan Cox wrote:
We have two possible solutions here:
a. Patch Ubuntu, such that the incorrect INQUIRY is fixed.
b. Patch kernel, such that the AOpen drives are blacklisted.
Each INQUIRY is inspected for the blacklisted drives.
If the INQUIRY looks wrong, the INQUIRY is
In LBA48 mode we have to help the controller to get anything to work. The
chip provides a register giving word counts meant for ATAPI use which we
can use. However we need to load the count in words not bytes..
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive
Further HPT37x changes
- No 66MHz 370/370A
- Remove dead special case check now we use the DPLL (as per the IDE driver)
Pointed out by Sergei
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
Yes its no longer 3x2n but 3xxn, I can rename it if you want Jeff
- Don't reset both ports each time (Sergei)
- If we can't get a DPLL then abort entirely
- Use ioport access for clock (from drivers/ide)
- Add HPT371N support (from drivers/ide)
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u
Signed-off-by: Alan Cox [EMAIL PROTECTED]
- Fix theoretical pdc2027x crash if the BIOS didn't assign BAR4 for DMA. (Needs
a default modefilter)
- Use cable methods
- Replace post_set_mode() use with wrapped set_mode() [Removes last use of
post_set_mode]
- Mode filter Maxtor UDMA133 rule
diff
Hi,
On Monday 19 March 2007, Sergei Shtylyov wrote:
Hello.
Bartlomiej Zolnierkiewicz wrote:
It seems that the drive works just fine in PIO mode with pdc202xx_new
IDE driver (it doesn't support ATAPI DMA at the moment)
There used to be Albert's patch enabling ATAPIT DMA in this
For reference this is what I am currently using with 2.6.21-rc4-mm1 and
it is working for all my test cases so far: Its basically Kyle's patch
with a libata switch to turn it on/off and some minor fixups from
the original patch as posted
diff -u --new-file --recursive --exclude-from
Hi,
On Friday 23 March 2007, Olaf Hering wrote:
On Thu, Mar 22, Christoph Hellwig wrote:
On Thu, Mar 22, 2007 at 10:52:34PM +0100, Olaf Hering wrote:
How can this compile error be fixed properly?
request_queue_t is inside CONFIG_BLOCK,
ide_drive_s (and likely others) use it
This email lists some known regressions in Linus' tree compared to 2.6.20.
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 considering you in any other way
possibly
+static int ata_ignore_hpa = 0;
Don't init to 0. Not needed, bloats binary files.
It'll be one for the final release 8)
+module_param_named(ignore_hpa, ata_ignore_hpa, int, 0644);
+MODULE_PARM_DESC(ignore_hpa, Ignore HPA (0=off 1=on));
So 1 = on = ignore, right?
Yes.
+
On Fri, Mar 23, Bartlomiej Zolnierkiewicz wrote:
Because it is needed in a few places.
Is there really any PPC64 specific code which needs linux/ide.h
(ppc_ide_md is used only by PPC32)?
This is about CONFIG_BLOCK=n, not about arch/... Is all non-driver
code which has to poke into ide code
From: Alan Cox [EMAIL PROTECTED]
Date: Fri, 23 Mar 2007 20:08:19 +
u64 is always unsigned long long (and its debug anyway)
It's plain unsigned long on sparc64 and some other 64-bit platforms.
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to
On Fri, 23 Mar 2007 20:08:19 + Alan Cox wrote:
+static int ata_ignore_hpa = 0;
Don't init to 0. Not needed, bloats binary files.
It'll be one for the final release 8)
+module_param_named(ignore_hpa, ata_ignore_hpa, int, 0644);
+MODULE_PARM_DESC(ignore_hpa, Ignore HPA
On Friday 23 March 2007, Olaf Hering wrote:
On Fri, Mar 23, Bartlomiej Zolnierkiewicz wrote:
Because it is needed in a few places.
Is there really any PPC64 specific code which needs linux/ide.h
(ppc_ide_md is used only by PPC32)?
I suspect that the answer to my question is not
What is 0x40? can it be #defined (or enum-ed) instead of a magic
value? please? (more of same below)
It's 0x40. Its a command dependant bit - no useful name.
dependent. OK, thanks.
IDE is a bit like that. I'm amazed some of the command flags arent in
latin.
Already corrected
On Fri, 23 Mar 2007 12:22:32 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Alan Cox [EMAIL PROTECTED]
Date: Fri, 23 Mar 2007 20:08:19 +
u64 is always unsigned long long (and its debug anyway)
It's plain unsigned long on sparc64 and some other 64-bit platforms.
I stand
On Fri, Mar 23, 2007 at 07:13:21PM +, Alan Cox wrote:
+static int ata_ignore_hpa = 0;
+module_param_named(ignore_hpa, ata_ignore_hpa, int, 0644);
+MODULE_PARM_DESC(ignore_hpa, Ignore HPA (0=off 1=on));
I'm not sure I like the language here. Ignore HPA appears to mean
Explicitly disable
This email lists some known regressions in Linus' tree compared to 2.6.20.
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 considering you in any other way
possibly
This email lists some known regressions in Linus' tree compared to 2.6.20.
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 considering you in any other way
possibly
On Friday 23 March 2007 20:50:22 Adrian Bunk wrote:
Subject: suspend to disk hangs
References : http://lkml.org/lkml/2007/3/16/126
Submitter : Maxim Levitsky [EMAIL PROTECTED]
Caused-By : Rafael J. Wysocki [EMAIL PROTECTED]
commit e3c7db621bed4afb8e231cb005057f2feb5db557
Alan Cox wrote:
What is 0x40? can it be #defined (or enum-ed) instead of a magic
value? please? (more of same below)
It's 0x40. Its a command dependant bit - no useful name.
dependent. OK, thanks.
IDE is a bit like that. I'm amazed some of the command flags arent in
latin.
Hmm,
Hi,
On Thursday 08 March 2007, Suleiman Souhlal wrote:
On Mar 7, 2007, at 1:16 PM, Bartlomiej Zolnierkiewicz wrote:
Please respin the patch so I could merge it.
Ok.
Since I think that it's worth to have it in 2.6.21-final and respin didn't
happen I did the required changes myself (it
--- Bob Stewart [EMAIL PROTECTED] wrote:
--- Tejun Heo [EMAIL PROTECTED] wrote:
It would be great if you can test the sunix driver on 2.4 kernel for
both LBA28 and 48 cases. I know it's a hassle and would really
appreciate it.
Will do. I'll be using Debian Sarge 2.4. It'll be 2 or 3
As an additional data point, here's a libata problem I'm having trying to
rebuild the array.
I have six identical 400 GB drives (ST3400832AS), and one is giving
me hassles. I've run SMART short and long diagnostics, badblocks, and
Seagate's seatools diagnostic software, and none of these find
24 matches
Mail list logo
