Recent mmio change broke compilation if PM is turned on. Fix it.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
pata_sil680.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/pata_sil680.c
On Thu, 2007-05-17 at 16:43 +0200, Tejun Heo wrote:
I'll attach the updated version of http://linux-ata.org/shutdown.html
as a reply to this mail.
It says:
When a disk is powered off, it needs to flush its write cache and then
unload its heads so that they don't crash onto the recording
Jeff Garzik schrieb:
Below is a refresh of my on-going effort to convert sata_mv to the new
exception handling framework. sata_mv is one of the last hold-outs, and
its old-EH implementation blocks new features like hotplug and NCQ.
It works for me on the one 50xx and one 60xx card I tested it
Can someone (Greg K-H?) tell me the status of the below patch? Is it
planned for 2.6.22? It looks like a useful generic let's disable msi
on board x that I might want to use for the atl1 network driver.
Thanks,
Jay
On Wed, 09 May 2007 14:23:02 +0200
Tejun Heo [EMAIL PROTECTED] wrote:
MSI
On Sat, 19 May 2007, Tejun Heo wrote:
To fix this issue, halt(8) started issueing WIN_STANDBYNOW1 (0xE0) and
WIN_STANDBYNOW2 (0x94) ioctls before halt and poweroff, as that was more
reliable than flush cache and the effect was the same.
One culprit there is that, according to the spec,
On Sat, May 19, 2007 07:35, Jeff Garzik wrote:
Since Alan expressed a desire to see Large Block Transfer (LBT) support
in pata_sil680, I though I would re-post my patch for adding LBT support
to sata_sil.
Silicon Image's Large Block Transfer (LBT) support is a vendor-specific
DMA
Hello,
Disabling sd_resume() gives me a quick resume again (few seconds),
though it doesn't get rid of the COMRESET errors:
[2.476417] ata1: device not ready (errno=-19), forcing hardreset
[2.476440] ata2: SATA link down (SStatus 0 SControl 310)
[2.824896] usb_endpoint
On Wed, May 16, 2007 18:44, Tejun Heo wrote:
On certain device/controller combination, 0xff status is asserted
after reset and doesn't get cleared during 150ms post-reset wait. As
0xff status is interpreted as no device (for good reasons), this can
lead to misdetection on such cases.
This
Henrique de Moraes Holschuh wrote:
Well, the reason I raised the ruckus in the first place was just the
emergency unload, yes. I didn't know about any missing cache flushes (and
AFAIK we never had any reported to us). We will have to fix that in halt(8)
IMHO, just in case. And probably
Jeff Garzik wrote:
Since Alan expressed a desire to see Large Block Transfer (LBT) support
in pata_sil680, I though I would re-post my patch for adding LBT support
to sata_sil.
Silicon Image's Large Block Transfer (LBT) support is a vendor-specific
DMA scatter/gather engine, which enables
Indan Zupancic wrote:
Using sata_sil (SiI 3512) with a ST3120827AS disk here.
For me the COMRESET happens after resume (s2ram):
[2.174342] sd 0:0:0:0: [sda] Starting disk
[2.476407] ata1: device not ready (errno=-19), forcing hardreset
[2.476429] ata2: SATA link down (SStatus
Indan Zupancic wrote:
Doesn't the controller generate an interrupt when it detects a harddisk?
Is it really needed to do polling?
It depends on the controller but the closest thing is usually PHY status
changed interrupt and PHY readiness doesn't imply device readiness. On
some controllers,
Tejun Heo wrote:
Yeah, if SCR registers are accessible, 0xff doesn't indicate the device
isn't there, so the whole skip-0xff logic probably shouldn't apply in
such cases, but we can also achieve pretty good result by just making
the first reset tries a bit more aggressive.
So, here's the
On Sat, 2007-05-19 at 12:29 +0200, Tejun Heo wrote:
Recent mmio change broke compilation if PM is turned on. Fix it.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Oops.. sorry about that.
Cheers,
Ben.
---
pata_sil680.c |4 +++-
1 file
Robert Hancock wrote:
Jeff Garzik wrote:
Since Alan expressed a desire to see Large Block Transfer (LBT) support
in pata_sil680, I though I would re-post my patch for adding LBT support
to sata_sil.
Silicon Image's Large Block Transfer (LBT) support is a vendor-specific
DMA scatter/gather
Jeff Garzik wrote:
rotfl. Boy am I dumb. I -thought- my patch, written months ago,
included that bit. But obviously it does not. Let's add that...
Or not. It just gets rid of the 64k boundary -and- allows for larger
scatter/gather entries. LBT does not add 64-bit DMA support.
That
Indan Zupancic wrote:
This patch seems to work with my SiI 3512, though I don't notice any
difference, neither a speedup, nor a slowdown. Hdparm gives the same
speeds (-tT), and cp -a'ing kernel sources is abysmal slow in both cases,
(need to look into that one) so I didn't really test it that
On Sat, May 19, 2007 21:04, Tejun Heo wrote:
Tejun Heo wrote:
Yeah, if SCR registers are accessible, 0xff doesn't indicate the device
isn't there, so the whole skip-0xff logic probably shouldn't apply in
such cases, but we can also achieve pretty good result by just making
the first reset
On Sat, May 19, 2007 20:23, Tejun Heo wrote:
Indan Zupancic wrote:
Resume takes now ten seconds or more, while it used to take only a few
seconds,
what changed? A few kernel versions ago (2.6.21-rc or so?) it retried in 5
seconds
instead of 10, but even that is too long.
There are two
On Sun, May 20, 2007 00:03, Jeff Garzik wrote:
Indan Zupancic wrote:
This patch seems to work with my SiI 3512, though I don't notice any
difference, neither a speedup, nor a slowdown. Hdparm gives the same
speeds (-tT), and cp -a'ing kernel sources is abysmal slow in both cases,
(need to
20 matches
Mail list logo
