Currently when system which have HPA require HPA to be detected and
disabled upon resume from RAM or disk. The current IDE drivers do not do
this nor does libata(obviously it since it doesn't support HPA yet). I
have implemented this into the current IDE drivers and it has been
tested by many
Jeff Garzik wrote:
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
..
Andrew Morton (1):
git-libata-all: sata_via build fix
..
diff --git a/drivers/ata/sata_via.c b/drivers/ata/sata_via.c
index
Glue code to hook up the pata_platform on the PA Semi Electra eval board.
CFE sets up device tree entries for the IDE interface, with device type
'ide' and compatible field 'electra-ide'.
We unfortunately need to modify the resources before calling the generic
platform driver, since the device
On Thu, 10 May 2007 21:41:32 +0200, Peter Favrholdt wrote:
I would like to help by testing the most recent version of the
sata_promise driver on my
Promise Technology, Inc. PDC40718 (SATA 300 TX4) (rev 02)
with 4 Seagate 500GB ES drives:
Model Number: ST3500630NS
This is current mainline plus a few patches which I've just sent to Linus:
loop_probe-fix-return-value.patch
fault-injection-disable-stacktrace-filter-for-x86-64.patch
ntfs-use-zero_user_page.patch
tty-flush-flip-buffer-on-ldisc-input-queue-flush.patch
missing-include-file-in-tpm_atmelh.patch
Replying to my own post:
Wanted to add that the ata1 port just died even without doing any
smartctl's - and not recovering.
BR Peter
Peter Favrholdt wrote:
Hi,
I've tested with 2.6.21.1 with the following patches (which applied
cleanly):
Fred Moyer wrote:
I just joined the list today so apologies if this email breaks any email
client post threading.
I have been seeing similar errors on two different systems. I applied
Robert's sata_nv patch posted to the list on May 5th, and approved today
by Jeff Garzik. I've taken
Robert Hancock wrote:
Fred Moyer wrote:
I just joined the list today so apologies if this email breaks any
email client post threading.
I have been seeing similar errors on two different systems. I applied
Robert's sata_nv patch posted to the list on May 5th, and approved
today by Jeff
On Sat, 2007-05-12 at 11:25 -0700, Andrew Morton wrote:
[ 715.196000] sd 2:0:0:0: [sda] Synchronizing SCSI cache
[ 715.196000] sd 2:0:0:0: [sda] Stopping disk
[ 715.196000] ata3.00: DISK MIGHT NOT BE SPUN DOWN PROPERLY. UPDATE SHUTDOWN
UTILITY
[ 715.196000] ata3.00: For more info, visit
I have now tested with 2.6.21-git16 with the same result: sda and sdd
froze after copying 1.7GB and 2.7GB respectively.
Here is dmesg output:
[ 59.070670] sata_promise :01:08.0: version 2.07
stuff deleted
[ 402.136295] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x138
action 0x2
On Saturday 12 May 2007, Olof Johansson wrote:
We unfortunately need to modify the resources before calling the generic
platform driver, since the device tree only has one register window in
it and the driver expects two. Adding this as an of_platform driver
instead doesn't give us any
Why not provide a proper pata_of.c driver based on ata_generic? That
will help the next person that has a builtin ata controller and wants
to get it running as an of_device.
Easier to use pata_platform I would think ? Just create the OF device and
bind it to pata_platform.
Alan
-
To
On Sunday 13 May 2007, Alan Cox wrote:
Why not provide a proper pata_of.c driver based on ata_generic? That
will help the next person that has a builtin ata controller and wants
to get it running as an of_device.
Easier to use pata_platform I would think ? Just create the OF device and
Fred Moyer wrote:
This appears to be a different problem. Something is issuing
SMART-related commands (smartd or smartctl perhaps) which the drive
seems to be reacting strangely to. It apparently completed the command
but never raised DRQ to request any data being transferred even though
we
Robert Hancock wrote:
Fred Moyer wrote:
This appears to be a different problem. Something is issuing
SMART-related commands (smartd or smartctl perhaps) which the drive
seems to be reacting strangely to. It apparently completed the
command but never raised DRQ to request any data being
--- Tejun Heo [EMAIL PROTECTED] wrote:
Srihari Vijayaraghavan wrote:
Oh well, that's the price you have to pay when you 1. have a device
which can't access memory above 4G but 2. don't have IOMMU to do it for
the device. If performance becomes problem, you can always get a
16 matches
Mail list logo
