Henrique de Moraes Holschuh wrote:
On Tue, 07 Aug 2007, Tejun Heo wrote:
Michael Sedkowski wrote:
Hmmm... If the problem only shows up on nx6325, it might be that ACPI is
pulling unnecessary stunt. Please apply the attached patch and report
when the disk spins down and up.
Disk spins down
Michael Sedkowski wrote:
Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a):
Does emergency unload count increase
after each power down?
I think I got it.
Using smartctl I've done a test and shut down, then repeted the test.
The only values that where diffrent are
On Tue, Aug 07, 2007 at 02:43:27AM +0900, Tejun Heo wrote:
Fix map entry 10b for ich8. It's [P0 P2 IDE IDE] like ich6 / ich6m.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Kristen Carlson Accardi [EMAIL PROTECTED]
---
Many users can be hit by this. Please consider for -stable. Thanks.
Greg KH wrote:
On Tue, Aug 07, 2007 at 02:43:27AM +0900, Tejun Heo wrote:
Fix map entry 10b for ich8. It's [P0 P2 IDE IDE] like ich6 / ich6m.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Kristen Carlson Accardi [EMAIL PROTECTED]
---
Many users can be hit by this. Please consider for
On Tue, Aug 07, 2007 at 05:09:08PM +0900, Tejun Heo wrote:
Greg KH wrote:
On Tue, Aug 07, 2007 at 02:43:27AM +0900, Tejun Heo wrote:
Fix map entry 10b for ich8. It's [P0 P2 IDE IDE] like ich6 / ich6m.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Kristen Carlson Accardi [EMAIL
On Mon, 2007-08-06 at 21:18 +0400, Sergei Shtylyov wrote:
Hm, well, this is indeed tough case but at least it prodded me to fix
some
issues. Maybe it's worth for you to file a bug at bugzilla.kernel.org...
I've raised bug 8851:
http://bugzilla.kernel.org/show_bug.cgi?id=8851
Bob
-
Dnia 07-08-2007, Wt o godzinie 15:56 +0900, Tejun Heo napisał(a):
192 Power-Off_Retract_Count 0x0032 100 100 000Old_age
Always - 388
I think this is the one. You can test it by forcefully powering off
the
machine (press power button for several secs or disconnect AC
Hi everybody,
My PATA driver for AVR32 is now working in all PIO modes. I have
tested the driver for two weeks and it seems pretty stable, there
are no file corruption or fatal errors.
This is a typical result by running Bonnie in PIO4 (file size 104857600):
---Sequential Output
This patch adds support for PATA devices on the AVR32 using the CompactFlash
controller in 'True IDE mode'. DMA is currently not supported due to lack of
DMACK pins on the current AP7000 series.
Tested on AP7000 / STK1000.
Signed-off-by: Kristoffer Nyborg Gregertsen [EMAIL PROTECTED]
---
diff
Dnia 07-08-2007, Wt o godzinie 15:56 +0900, Tejun Heo napisał(a):
You can test it by forcefully powering off the
machine (press power button for several secs or disconnect AC and
battery) and see whether the count increases.
Forgot to mention that double spin down does not happen when the
Michael Sedkowski wrote:
Dnia 07-08-2007, Wt o godzinie 15:56 +0900, Tejun Heo napisał(a):
192 Power-Off_Retract_Count 0x0032 100 100 000Old_age
Always - 388
I think this is the one. You can test it by forcefully powering off
the
machine (press power button for
On Monday 06 August 2007, Sergei Shtylyov wrote:
Bartlomiej Zolnierkiewicz wrote:
Index: b/drivers/ide/arm/icside.c
===
--- a/drivers/ide/arm/icside.c
+++ b/drivers/ide/arm/icside.c
@@ -309,14 +309,6 @@ static int
Tejun Heo wrote:
Michael Sedkowski wrote:
Dnia 07-08-2007, Wt o godzinie 15:56 +0900, Tejun Heo napisał(a):
192 Power-Off_Retract_Count 0x0032 100 100 000Old_age
Always - 388
[snip]
On power off, the r/w heads in a disk should be unloaded (parked). This
is usually
On Tue, 07 Aug 2007, Tejun Heo wrote:
Henrique de Moraes Holschuh wrote:
On Tue, 07 Aug 2007, Tejun Heo wrote:
Michael Sedkowski wrote:
Hmmm... If the problem only shows up on nx6325, it might be that ACPI is
pulling unnecessary stunt. Please apply the attached patch and report
when
On Tue, 07 Aug 2007, Tejun Heo wrote:
emergency unload. Emergency unload does shorten the lifespan of the
disk but you don't have to worry too much about it. Disks are designed
to withstand certain number of emergency unloads.
You *do* have to worry about it in any box you turn off daily.
On Tue, 2007-08-07 at 09:51 -0300, Henrique de Moraes Holschuh wrote:
On Tue, 07 Aug 2007, Tejun Heo wrote:
Henrique de Moraes Holschuh wrote:
On Tue, 07 Aug 2007, Tejun Heo wrote:
Michael Sedkowski wrote:
---snip---
Any chances of changing things
so that we inspect/snoop all tasks
Hello, Henrique.
Henrique de Moraes Holschuh wrote:
approximately translates into if you have too many boatmen on a ship,
it goes to mountain. We also have a bunch of Toshiba laptops which
Yeah, that's a problem. But we can avoid it if we start snooping what ACPI
is asking us to deliver
On Tue, 07 Aug 2007, Tejun Heo wrote:
Henrique de Moraes Holschuh wrote:
approximately translates into if you have too many boatmen on a ship,
it goes to mountain. We also have a bunch of Toshiba laptops which
Yeah, that's a problem. But we can avoid it if we start snooping what ACPI
Henrique de Moraes Holschuh wrote:
On Tue, 07 Aug 2007, Tejun Heo wrote:
Henrique de Moraes Holschuh wrote:
approximately translates into if you have too many boatmen on a ship,
it goes to mountain. We also have a bunch of Toshiba laptops which
Yeah, that's a problem. But we can avoid it if
Thomas Renninger wrote:
Any chances of changing things
so that we inspect/snoop all tasks sent to the device, and filter them
out, or react to them accordingly?
No, we can't unless we snoop ACPI method execution and detect accesses
to IO ports or iomem regions. It's not going through any
On Tue, 2007-08-07 at 22:32 +0900, Tejun Heo wrote:
Henrique de Moraes Holschuh wrote:
On Tue, 07 Aug 2007, Tejun Heo wrote:
Henrique de Moraes Holschuh wrote:
approximately translates into if you have too many boatmen on a ship,
it goes to mountain. We also have a bunch of Toshiba
Thomas Renninger wrote:
I'd also suggest adding a FAIL to the Linux firmware toolkit to any DSDT
doing this. Who should we prod to add that check?
Dunno how the firmware toolkit works but this one can be pretty
difficult to test (if it were easy, we could test it in libata) as it
involves
Tejun Heo wrote:
Robert Hancock wrote:
Tejun Heo wrote:
Michael Sedkowski wrote:
Hmmm... If the problem only shows up on nx6325, it might be that
ACPI is
pulling unnecessary stunt. Please apply the attached patch and report
when the disk spins down and up.
Disk spins down on Pre-shutdown
Robert Hancock wrote:
Tejun Heo wrote:
Yeah, that seems to be what's going on. I don't think we have any other
choice than blacklisting those notebooks. This is a mess. How does the
other OS cope with this?
Quite possible that it gets a double spindown with these laptop/drive
On Tue, 2007-08-07 at 15:41 +0900, Tejun Heo wrote:
Robert Hancock wrote:
Tejun Heo wrote:
Michael Sedkowski wrote:
Hmmm... If the problem only shows up on nx6325, it might be that
ACPI is
pulling unnecessary stunt. Please apply the attached patch and report
when the disk spins down
Em Tue, 7 Aug 2007 14:42:50 +0900
Tejun Heo [EMAIL PROTECTED] escreveu:
| HDS724040KLSA80 reports that it supports HPA LBA48 but craps itself
| on READ_NATIVE_MAX_EXT. Implement BROKEN_HPA horkage and apply it to
| the drive. If the horkage is set, all HPA operations are skipped.
|
| While at
Luiz Fernando N. Capitulino wrote:
Em Tue, 7 Aug 2007 14:42:50 +0900
Tejun Heo [EMAIL PROTECTED] escreveu:
| HDS724040KLSA80 reports that it supports HPA LBA48 but craps itself
| on READ_NATIVE_MAX_EXT. Implement BROKEN_HPA horkage and apply it to
| the drive. If the horkage is set, all
Em Wed, 08 Aug 2007 00:00:28 +0900
Tejun Heo [EMAIL PROTECTED] escreveu:
| Luiz Fernando N. Capitulino wrote:
| Em Tue, 7 Aug 2007 14:42:50 +0900
| Tejun Heo [EMAIL PROTECTED] escreveu:
|
| | HDS724040KLSA80 reports that it supports HPA LBA48 but craps itself
| | on READ_NATIVE_MAX_EXT.
On Tue, 7 Aug 2007 14:42:50 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
HDS724040KLSA80 reports that it supports HPA LBA48 but craps itself
on READ_NATIVE_MAX_EXT. Implement BROKEN_HPA horkage and apply it to
the drive. If the horkage is set, all HPA operations are skipped.
I'd rather know
Alan Cox wrote:
On Tue, 7 Aug 2007 14:42:50 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
HDS724040KLSA80 reports that it supports HPA LBA48 but craps itself
on READ_NATIVE_MAX_EXT. Implement BROKEN_HPA horkage and apply it to
the drive. If the horkage is set, all HPA operations are skipped.
Could someone more knowledgeable than me please reassure me ...
Referring to code in linux-2.6.22.1: libata-core.c (kernel.org),
in ata_fill_sg():
if sg_dma_address(sg) is 64k-aligned and sg_dma_len(sg) is 64k (0x1),
then in the while loop, the if ((offset... test is false, since
it tests
People should check out Ben C's HPA fixes and cleanups, too. (attached)
I was hoping one of the original libata HPA authors would review that in
depth and integrate. (it no longer applies cleanly)
Jeff
From: Ben Collins [EMAIL PROTECTED]
The original HPA patch that Kyle worked
+static int pata_at32_get_pio_mask(void)
+{
+ switch (max_pio) {
+ case 0:
+ return 0x01;
+ case 1:
+ return 0x03;
+ case 2:
+ return 0x07;
+ case 3:
+ return 0x0f;
+ case 4:
+ return 0x1f;
+
1) In PIO1 and PIO2 there are rare freezes:
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd 20/00:00:d3:7e:5d/00:00:00:00:00/e1 tag 0 cdb 0x0 data 131072 in
res 58/00:01:d2:7f:5d/00:00:01:00:00/e1 Emask 0x2 (HSM violation)
The freezes happen close to
From: Mark Lord [EMAIL PROTECTED]
Add support for issuing ATA_16 passthru commands to ATAPI devices
managed by libata. It requires the previous CDB length fix patch.
A boot/module parameter, atapi_scmd85=1 can be used to globally
disable this feature, if ever desired.
tj: renamed
I'd rather know what is going on here. A drive can legitimately
support LBA48 and HPA and refuse READ_NATIVE_MAX_EXT.
READ_NATIVE_MAX_EXT is mandatory if HPA LBA48, no?
No - and we hit this specific case in old IDE with some Maxtor drives.
Haven't tried that but the problem is that the
On Tue, 07 Aug 2007 11:47:38 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
People should check out Ben C's HPA fixes and cleanups, too. (attached)
I was hoping one of the original libata HPA authors would review that in
depth and integrate. (it no longer applies cleanly)
Looks basically
I'd rather know what is going on here. A drive can legitimately
support LBA48 and HPA and refuse READ_NATIVE_MAX_EXT.
READ_NATIVE_MAX_EXT is mandatory if HPA LBA48, no
Ok the report in that thread is different. The offending Maxtor simply
aborts the read_native_max_ext
-
To unsubscribe
Alan Cox wrote:
On Tue, 07 Aug 2007 11:47:38 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
People should check out Ben C's HPA fixes and cleanups, too. (attached)
I was hoping one of the original libata HPA authors would review that in
depth and integrate. (it no longer applies cleanly)
Alan Cox wrote:
I'd rather know what is going on here. A drive can legitimately
support LBA48 and HPA and refuse READ_NATIVE_MAX_EXT.
READ_NATIVE_MAX_EXT is mandatory if HPA LBA48, no?
No - and we hit this specific case in old IDE with some Maxtor drives.
Hmmm... Looking up the spec...
So then ap-prd[idx].flags_len gets set to (0x1 0x) = 0 !
So this sg element ends up with a zero length, even though the
transfer size should be 64k.
Is this correct behaviour, if not, should it be corrected ?
The specification says that 0x means 64K. A couple of controllers do
On Tuesday 07 August 2007 17:54:09 Alan Cox wrote:
+static int pata_at32_get_pio_mask(void)
+{
+ switch (max_pio) {
+ case 0:
+ return 0x01;
+ case 1:
+ return 0x03;
+ case 2:
+ return 0x07;
+ case 3:
+ return 0x0f;
+
Kristoffer Nyborg Gregertsen wrote:
On Tuesday 07 August 2007 17:54:09 Alan Cox wrote:
+static int pata_at32_get_pio_mask(void)
+{
+ switch (max_pio) {
+ case 0:
+ return 0x01;
+ case 1:
+ return 0x03;
+ case 2:
+ return 0x07;
On Tuesday 07 August 2007 17:58:12 Alan Cox wrote:
1) In PIO1 and PIO2 there are rare freezes:
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd 20/00:00:d3:7e:5d/00:00:00:00:00/e1 tag 0 cdb 0x0 data
131072 in res 58/00:01:d2:7f:5d/00:00:01:00:00/e1 Emask 0x2
On Tuesday 07 August 2007 20:14:27 Jeff Garzik wrote:
Well, a higher level issue, you should not have a max_pio module
parameter at all. Other drivers do not have such a thing.
OK, I'll remove it then. It was very convenient during automated testing of
all PIO modes, but I guess that's not
I have a PATA tape drive here somewhere.
-EBUSY
Does anyone out there want it, with the understanding that it be
used to test/improve libata tape support?
I'm happy to help someone else doing the work who needs info on libata
etc but I've no time to work on whats a very obscure corner case.
On 08/07/2007 11:36 AM, Tejun Heo wrote:
Alan Cox wrote:
On Tue, 7 Aug 2007 14:42:50 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
HDS724040KLSA80 reports that it supports HPA LBA48 but craps itself
on READ_NATIVE_MAX_EXT. Implement BROKEN_HPA horkage and apply it to
the drive. If the horkage
I did some additional checking today...
On kernels prior to 2.6.22 line, the bug exists and manifests itself
exactly the same way. However, when I removed the -h flag
from /etc/init.d/halt, the drive spins down only once on Power down
message and there is no sign of the bug and the emergency
There's also this Fedora bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251047#c2
...where after an error on the slave device the master starts throwing
HPA errors after the port is reset. Don't know if it's related or
not...
Looks unrelated. You get a timeout
ata2.01:
2007/8/7, Michael Sedkowski [EMAIL PROTECTED]:
I did some additional checking today...
On kernels prior to 2.6.22 line, the bug exists and manifests itself
exactly the same way. However, when I removed the -h flag
from /etc/init.d/halt, the drive spins down only once on Power down
message and
On Tuesday, 7 August 2007 22:09, Maciej Rutecki wrote:
2007/8/7, Michael Sedkowski [EMAIL PROTECTED]:
I did some additional checking today...
On kernels prior to 2.6.22 line, the bug exists and manifests itself
exactly the same way. However, when I removed the -h flag
from
From: Tejun Heo [EMAIL PROTECTED]
Please warmly welcome the first member from FUJITSU to the prestigious
NCQ spurious completion club.
This is reported by Serge Van Thillo in bugzilla bug 8730.
http://bugzilla.kernel.org/show_bug.cgi?id=8730
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc:
Well, on my box (nx6325) with the appended (experimental) patch applied
on top of 2.6.23-rc1 with the patchset from
s/2.6.23-rc1/2.6.23-rc2/
HP nx 6310, _old_ shutdown 2.6.23-rc2+above patches:
1. Before:
rutek:/home/maciek# /usr/sbin/smartctl --all -d ata /dev/sda | grep
Well, it's what the ide driver does. BTW, according to the spec, we
need to test bit 14 and 15 of word 87 before trusting any value the
device reports in words 85-87 and 120, which libata currently doesn't
do. Are we leaving this out intentionally (for broken devices) or just
did we just
On Tuesday, 7. August 2007, Greg KH wrote:
From: Christian Lamparter [EMAIL PROTECTED]
This is commit c1e6f28cc5de37dcd113b9668a185c0b9334ba8a which is
merged during 23-rc1 window. Considering the popularity of these
chips, I think including it in -stable release would be good idea.
Henrique de Moraes Holschuh wrote:
On Tue, 07 Aug 2007, Tejun Heo wrote:
emergency unload. Emergency unload does shorten the lifespan of the
disk but you don't have to worry too much about it. Disks are designed
to withstand certain number of emergency unloads.
You *do* have to worry about
Henrique de Moraes Holschuh wrote:
On Tue, 07 Aug 2007, Tejun Heo wrote:
Henrique de Moraes Holschuh wrote:
On Tue, 07 Aug 2007, Tejun Heo wrote:
Michael Sedkowski wrote:
Hmmm... If the problem only shows up on nx6325, it might be that ACPI is
pulling unnecessary stunt. Please apply the
Alan Cox wrote:
/* Compute DPLL */
- dpll = 2;
- if (port-udma_mask 0xE0)
- dpll = 3;
+ dpll = (port-udma_mask 0xC0) ? 3 : 2;
Gak, I'd much rather people kept to the nice easy to read if() but fine
Tejun Heo wrote:
Fix map entry 10b for ich8. It's [P0 P2 IDE IDE] like ich6 / ich6m.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Kristen Carlson Accardi [EMAIL PROTECTED]
---
Many users can be hit by this. Please consider for -stable. Thanks.
drivers/ata/ata_piix.c |2 +-
1 file
Hi,
I just compiled 2.6.23-rc1-mm2 with libata for the first time. I chose
CONFIG_ATA, CONFIG_ATA_ACPI and CONFIG_PATA_ALI. CONFIG_BLK_DEV_SD and
CONFIG_BLK_DEV_SR are enabled, too.
My hardware is:
00:04.0 IDE interface: ALi Corporation M5229 IDE (rev c4) (prog-if fa)
Subsystem: ALi
The only non-fix are two sata_mv PCI ID additions.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ata_piix.c|2 +-
drivers/ata/pata_isapnp.c |2 ++
On Tue, 07 Aug 2007 20:49:34 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
Alan Cox wrote:
/* Compute DPLL */
- dpll = 2;
- if (port-udma_mask 0xE0)
- dpll = 3;
+ dpll = (port-udma_mask 0xC0) ? 3 : 2;
Gak, I'd much rather
The boot process takes several minutes when trying to configure the Combo
drive with UDMA/33 and finally settles with UDMA/25:
Known problem. Still under investigation and not yet understood fully.
Is this a problem with my drive? It works fine with alim15x3, so.
Did I forget to enable
Alan Cox wrote:
On Tue, 07 Aug 2007 20:49:34 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
Alan Cox wrote:
/* Compute DPLL */
- dpll = 2;
- if (port-udma_mask 0xE0)
- dpll = 3;
+ dpll = (port-udma_mask 0xC0) ? 3 :
Please send me an lspci -vvxxx after booting both the libata and non
libata kernel.
There you go.
With libata:
00:00.0 Host bridge: ATI Technologies Inc AGP Bridge [IGP 320M] (rev 13)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Its a real fix for a real bug. The 374 needs a bit more stuff which is
sitting in my tree and I'll push for Sergei to comment tomorrow
OK, thanks. Do you also ACK
[PATCH 2/2] pata_hpt{37x|3x2n}: fix clock reporting
Yep
-
To unsubscribe from this list: send the line unsubscribe
Alan Cox wrote:
I'd rather know what is going on here. A drive can legitimately
support LBA48 and HPA and refuse READ_NATIVE_MAX_EXT.
READ_NATIVE_MAX_EXT is mandatory if HPA LBA48, no
Ok the report in that thread is different. The offending Maxtor simply
aborts the read_native_max_ext
Michael Sedkowski wrote:
I did some additional checking today...
On kernels prior to 2.6.22 line, the bug exists and manifests itself
exactly the same way. However, when I removed the -h flag
from /etc/init.d/halt, the drive spins down only once on Power down
message and there is no sign of
On Tue, 07 Aug 2007, Robert Hancock wrote:
You *do* have to worry about it in any box you turn off daily. Desktop
HDs will croak fast in that scenario, laptop HDs less so, but still too
fast. A very good laptop HD can last about 20k emergency unloads (this
is a unit that can do about 600k
Henrique de Moraes Holschuh wrote:
On Tue, 07 Aug 2007, Robert Hancock wrote:
You *do* have to worry about it in any box you turn off daily. Desktop
HDs will croak fast in that scenario, laptop HDs less so, but still too
fast. A very good laptop HD can last about 20k emergency unloads (this
Certain device which reports diagnostic failure also reports invalid
device signature. Assume ATA_DEV_ATA on diagnostic failure if reset
indicates device presence.
This is fix for bugzilla bug 8784.
http://bugzilla.kernel.org/show_bug.cgi?id=8784
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Make ata_dev_try_classify() take a pointer to ata_device instead of
ata_port/port_number combination for consistency and add @present
argument. @present indicates whether the device seems present during
reset. It's the result of TF access during softreset and link
onlineness during hardreset.
72 matches
Mail list logo
