Re: Fwd: [LIBATA] drives not detected
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, regarding the loading pata_pdc207x and all. md3 : active raid1 sdc1[2] sdb1[0] 117218176 blocks [2/1] [U_] [==..] recovery = 31.8% (37313792/117218176) finish=2503.2min speed=531K/sec A while a go I had a southbridge that wasnt too happy about the fact that the fan wasnt running for some weeks allready, I guess I am feeling the pain for it now. Lot's of Port is slow, please be patient warnings. Good thing is: the disk stays in UDMA100 now, instead of dropping to PIO mode 1. As soon as i can replace the disk, I will do the tests for you. So as the dmesg says: be patient :P Thanks again for all your help, Patrick - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: nonzero mismatch_cnt with no earlier error
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 action 0x2 [937567.354094] ata3.00: cmd b0/d5:01:09:4f:c2/00:00:00:00:00/00 tag 0 cdb 0x0 data 512 in [937567.354096] res 51/04:83:45:00:00/00:00:00:00:00/a0 Emask 0x10 (ATA bus error) [937568.120783] ata3: soft resetting port [937568.282450] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [937568.306693] ata3.00: configured for UDMA/100 [937568.319733] ata3: EH complete [937568.361223] SCSI device sdc: 625142448 512-byte hdwr sectors (320073 MB) [937568.397207] sdc: Write Protect is off [937568.408620] sdc: Mode Sense: 00 3a 00 00 [937568.453522] SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA Neil Brown wrote: On Saturday February 24, [EMAIL PROTECTED] wrote: But is this not a good opportunity to repair the bad stripe for a very low cost (no complete resync required)? In this case, 'md' knew nothing about an error. The SCSI layer detected something and thought it had fixed it itself. Nothing for md to do. I expected this. So either the scsi layer incorrectly held back the error report of the mismatch_cnt is due to something unrelated to the disk i/o failure. At time of error we actually know which disk failed and can re-write it, something we do not know at resync time, so I assume we always write to the parity disk. Again, as I expected, resync cannot correct a problem, effectively blaming the parity block. To know which block to correct one needs a higher level parity code (can raid6 correct single bit/disk read errors?). md only knows of a 'problem' if the lower level driver reports one. If it reports a problem for a write request, md will fail the device. If it reports a problem for a read request, md will try to over-write correct data on the failed block. But if the driver doesn't report the failure, there is nothing md can do. When performing a check/repair md looks for consistencies and fixes the 'arbitrarily'. For raid5/6, it just 'corrects' the parity. For raid1/10, it chooses one block and over-writes the other(s) with it. Mapping these corrections back to blocks in files in the filesystem is extremely non-trivial. NeilBrown -- Eyal Lebedinsky ([EMAIL PROTECTED]) http://samba.org/eyal/ attach .zip as .dat - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] pata_jmicron: drop unnecessary device programming in [re]init
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 +---
1 file changed, 1 insertion(+), 31 deletions(-)
Index: work/drivers/ata/pata_jmicron.c
===
--- work.orig/drivers/ata/pata_jmicron.c
+++ work/drivers/ata/pata_jmicron.c
@@ -202,43 +202,13 @@ static int jmicron_init_one (struct pci_
};
struct ata_port_info *port_info[2] = { info, info };
- u32 reg;
-
/* PATA controller is fn 1, AHCI is fn 0 */
if (id-driver_data != 368 PCI_FUNC(pdev-devfn) != 1)
return -ENODEV;
- /* The 365/66 have two PATA channels, redirect the second */
- if (id-driver_data == 365 || id-driver_data == 366) {
- pci_read_config_dword(pdev, 0x80, reg);
- reg |= (1 24); /* IDE1 to PATA IDE secondary */
- pci_write_config_dword(pdev, 0x80, reg);
- }
-
return ata_pci_init_one(pdev, port_info, 2);
}
-static int jmicron_reinit_one(struct pci_dev *pdev)
-{
- u32 reg;
-
- switch(pdev-device) {
- case PCI_DEVICE_ID_JMICRON_JMB368:
- break;
- case PCI_DEVICE_ID_JMICRON_JMB365:
- case PCI_DEVICE_ID_JMICRON_JMB366:
- /* Restore mapping or disks swap and boy does it get
ugly */
- pci_read_config_dword(pdev, 0x80, reg);
- reg |= (1 24); /* IDE1 to PATA IDE secondary */
- pci_write_config_dword(pdev, 0x80, reg);
- /* Fall through */
- default:
- /* Make sure AHCI is turned back on */
- pci_write_config_byte(pdev, 0x41, 0xa1);
- }
- return ata_pci_device_resume(pdev);
-}
-
static const struct pci_device_id jmicron_pci_tbl[] = {
{ PCI_VDEVICE(JMICRON, PCI_DEVICE_ID_JMICRON_JMB361), 361},
{ PCI_VDEVICE(JMICRON, PCI_DEVICE_ID_JMICRON_JMB363), 363},
@@ -255,7 +225,7 @@ static struct pci_driver jmicron_pci_dri
.probe = jmicron_init_one,
.remove = ata_pci_remove_one,
.suspend= ata_pci_device_suspend,
- .resume = jmicron_reinit_one,
+ .resume = ata_pci_device_resume,
};
static int __init jmicron_init(void)
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] jmicron ATA: reimplement jmicron ATA quirk
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, 363 and 368.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/pci/quirks.c | 80 +++
1 file changed, 50 insertions(+), 30 deletions(-)
Index: work/drivers/pci/quirks.c
===
--- work.orig/drivers/pci/quirks.c
+++ work/drivers/pci/quirks.c
@@ -1218,45 +1218,65 @@ DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_V
* do this early on to make the additional device appear during
* the PCI scanning.
*/
-
-static void quirk_jmicron_dualfn(struct pci_dev *pdev)
+static void quirk_jmicron_ata(struct pci_dev *pdev)
{
- u32 conf;
+ u32 conf1, conf5;
u8 hdr;
/* Only poke fn 0 */
if (PCI_FUNC(pdev-devfn))
return;
- switch(pdev-device) {
- case PCI_DEVICE_ID_JMICRON_JMB365:
- case PCI_DEVICE_ID_JMICRON_JMB366:
- /* Redirect IDE second PATA port to the right spot */
- pci_read_config_dword(pdev, 0x80, conf);
- conf |= (1 24);
- /* Fall through */
- pci_write_config_dword(pdev, 0x80, conf);
- case PCI_DEVICE_ID_JMICRON_JMB361:
- case PCI_DEVICE_ID_JMICRON_JMB363:
- pci_read_config_dword(pdev, 0x40, conf);
- /* Enable dual function mode, AHCI on fn 0, IDE fn1 */
- /* Set the class codes correctly and then direct IDE 0
*/
- conf = ~0x000FF200; /* Clear bit 9 and 12-19 */
- conf |= 0x00C2A102; /* Set 1, 8, 13, 15, 17, 22, 23 */
- pci_write_config_dword(pdev, 0x40, conf);
-
- /* Reconfigure so that the PCI scanner discovers the
- device is now multifunction */
-
- pci_read_config_byte(pdev, PCI_HEADER_TYPE, hdr);
- pdev-hdr_type = hdr 0x7f;
- pdev-multifunction = !!(hdr 0x80);
+ pci_read_config_dword(pdev, 0x40, conf1);
+ pci_read_config_dword(pdev, 0x80, conf5);
+
+ conf1 = ~0x00CFF302; /* Clear bit 1, 8, 9, 12-19, 22, 23 */
+ conf5 = ~(1 24); /* Clear bit 24 */
+
+ switch (pdev-device) {
+ case PCI_DEVICE_ID_JMICRON_JMB360:
+ /* The controller should be in single function ahci mode */
+ conf1 |= 0x0002A100; /* Set 8, 13, 15, 17 */
+ break;
- break;
+ case PCI_DEVICE_ID_JMICRON_JMB365:
+ case PCI_DEVICE_ID_JMICRON_JMB366:
+ /* Redirect IDE second PATA port to the right spot */
+ conf5 |= (1 24);
+ /* Fall through */
+ case PCI_DEVICE_ID_JMICRON_JMB361:
+ case PCI_DEVICE_ID_JMICRON_JMB363:
+ /* Enable dual function mode, AHCI on fn 0, IDE fn1 */
+ /* Set the class codes correctly and then direct IDE 0 */
+ conf1 |= 0x00C2A102; /* Set 1, 8, 13, 15, 17, 22, 23 */
+ break;
+
+ case PCI_DEVICE_ID_JMICRON_JMB368:
+ /* The controller should be in single function IDE mode */
+ conf1 |= 0x00C0; /* Set 22, 23 */
+ break;
}
-}
-DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_JMICRON, PCI_ANY_ID,
quirk_jmicron_dualfn);
-DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_JMICRON, PCI_ANY_ID,
quirk_jmicron_dualfn);
+
+ pci_write_config_dword(pdev, 0x40, conf1);
+ pci_write_config_dword(pdev, 0x80, conf5);
+
+ /* Update pdev accordingly */
+ pci_read_config_byte(pdev, PCI_HEADER_TYPE, hdr);
+ pdev-hdr_type = hdr 0x7f;
+ pdev-multifunction = !!(hdr 0x80);
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB360,
quirk_jmicron_ata);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB361,
quirk_jmicron_ata);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB363,
quirk_jmicron_ata);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB365,
quirk_jmicron_ata);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB366,
quirk_jmicron_ata);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB368,
quirk_jmicron_ata);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB360,
quirk_jmicron_ata);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB361,
quirk_jmicron_ata);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB363,
quirk_jmicron_ata);
[PATCH 3/3] ahci/pata_jmicron: match class not function number
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 as well defined as AHCI class.
This makes jmicron device matching more conventional and script
friendly.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/ahci.c | 16 +++-
drivers/ata/pata_jmicron.c | 19 ++-
drivers/pci/quirks.c |5 -
3 files changed, 17 insertions(+), 23 deletions(-)
Index: work/drivers/pci/quirks.c
===
--- work.orig/drivers/pci/quirks.c
+++ work/drivers/pci/quirks.c
@@ -1220,7 +1220,7 @@ DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_V
*/
static void quirk_jmicron_ata(struct pci_dev *pdev)
{
- u32 conf1, conf5;
+ u32 conf1, conf5, class;
u8 hdr;
/* Only poke fn 0 */
@@ -1264,6 +1264,9 @@ static void quirk_jmicron_ata(struct pci
pci_read_config_byte(pdev, PCI_HEADER_TYPE, hdr);
pdev-hdr_type = hdr 0x7f;
pdev-multifunction = !!(hdr 0x80);
+
+ pci_read_config_dword(pdev, PCI_CLASS_REVISION, class);
+ pdev-class = class 8;
}
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB360,
quirk_jmicron_ata);
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB361,
quirk_jmicron_ata);
Index: work/drivers/ata/ahci.c
===
--- work.orig/drivers/ata/ahci.c
+++ work/drivers/ata/ahci.c
@@ -385,12 +385,9 @@ static const struct pci_device_id ahci_p
{ PCI_VDEVICE(INTEL, 0x294d), board_ahci_pi }, /* ICH9 */
{ PCI_VDEVICE(INTEL, 0x294e), board_ahci_pi }, /* ICH9M */
- /* JMicron */
- { PCI_VDEVICE(JMICRON, 0x2360), board_ahci_ign_iferr }, /* JMB360 */
- { PCI_VDEVICE(JMICRON, 0x2361), board_ahci_ign_iferr }, /* JMB361 */
- { PCI_VDEVICE(JMICRON, 0x2363), board_ahci_ign_iferr }, /* JMB363 */
- { PCI_VDEVICE(JMICRON, 0x2365), board_ahci_ign_iferr }, /* JMB365 */
- { PCI_VDEVICE(JMICRON, 0x2366), board_ahci_ign_iferr }, /* JMB366 */
+ /* JMicron 360/1/3/5/6, match class to avoid IDE function */
+ { PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
+ PCI_CLASS_STORAGE_SATA_AHCI, 0xff, board_ahci_ign_iferr },
/* ATI */
{ PCI_VDEVICE(ATI, 0x4380), board_ahci }, /* ATI SB600 non-raid */
@@ -1665,13 +1662,6 @@ static int ahci_init_one(struct pci_dev
if (!printed_version++)
dev_printk(KERN_DEBUG, pdev-dev, version DRV_VERSION \n);
- if (pdev-vendor == PCI_VENDOR_ID_JMICRON) {
- /* Function 1 is the PATA controller except on the 368, where
- we are not AHCI anyway */
- if (PCI_FUNC(pdev-devfn))
- return -ENODEV;
- }
-
rc = pcim_enable_device(pdev);
if (rc)
return rc;
Index: work/drivers/ata/pata_jmicron.c
===
--- work.orig/drivers/ata/pata_jmicron.c
+++ work/drivers/ata/pata_jmicron.c
@@ -202,19 +202,20 @@ static int jmicron_init_one (struct pci_
};
struct ata_port_info *port_info[2] = { info, info };
- /* PATA controller is fn 1, AHCI is fn 0 */
- if (id-driver_data != 368 PCI_FUNC(pdev-devfn) != 1)
- return -ENODEV;
-
return ata_pci_init_one(pdev, port_info, 2);
}
static const struct pci_device_id jmicron_pci_tbl[] = {
- { PCI_VDEVICE(JMICRON, PCI_DEVICE_ID_JMICRON_JMB361), 361},
- { PCI_VDEVICE(JMICRON, PCI_DEVICE_ID_JMICRON_JMB363), 363},
- { PCI_VDEVICE(JMICRON, PCI_DEVICE_ID_JMICRON_JMB365), 365},
- { PCI_VDEVICE(JMICRON, PCI_DEVICE_ID_JMICRON_JMB366), 366},
- { PCI_VDEVICE(JMICRON, PCI_DEVICE_ID_JMICRON_JMB368), 368},
+ { PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB361,
+ PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_STORAGE_IDE 8, 0x00, 361 },
+ { PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB363,
+ PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_STORAGE_IDE 8, 0x00, 363 },
+ { PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB365,
+ PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_STORAGE_IDE 8, 0x00, 365 },
+ { PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB366,
+ PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_STORAGE_IDE 8, 0x00, 366 },
+ { PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB368,
+ PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_STORAGE_IDE 8, 0x00, 368 },
{ } /* terminate list */
};
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: end to end error recovery musings
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 a whole drive if there is a single write error. Can someone with knowledge of current disk drive behavior confirm that for all drives that support bad block sparing, if an attempt to write to a particular spot on disk results in an error due to bad media at that spot, the disk drive will automatically rewrite the sector to a sector in its spare pool, and automatically redirect that sector to 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. (Or that someone was in the middle of reconfiguring a FC network and they're running a kernel that doesn't understand why short-duration FC timeouts should be retried. :-) Or is that completely un-necessary as all modern devices do bad-block relocation for us? Is there any need for a bad-block-relocating layer in md or dm? That's the question. It wouldn't be that hard for filesystems to be able to remap a data block, but (a) it would be much more difficult for fundamental metadata (for example, the inode table), and (b) it's unnecessary complexity if the lower levels in the storage stack should always be doing this for us in the case of media errors anyway. What about corrected-error counts? Drives provide them with SMART. The SCSI layer could provide some as well. Md can do a similar thing to some extent. Where these are actually useful predictors of pending failure is unclear, but there could be some value. e.g. after a certain number of recovered errors raid5 could trigger a background consistency check, or a filesystem could trigger a background fsck should it support that. Somewhat off-topic, but my one big regret with how the dm vs. evms competition settled out was that evms had the ability to perform block device snapshots using a non-LVM volume as the base --- and that EVMS allowed a single drive to be partially managed by the LVM layer, and partially managed by evms. What this allowed is the ability to do device snapshots and therefore background fsck's without needing to convert the entire laptop disk to using a LVM solution (since to this day I still don't trust initrd's to always do the right thing when I am constantly replacing the kernel for kernel development). I know, I'm weird, distro users have initrd that seem to mostly work, and it's only wierd developers that try to use bleeding edge kernels with a RHEL4 userspace that suffer, but it's one of the reasons why I've avoided initrd's like the plague --- I've wasted entire days trying to debug problems with the userspace-provided initrd being too old to support newer 2.6 development kernels. 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. - Ted - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: end to end error recovery musings
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 be able to be worked around with retries. To Ted's point, in general, a write to a bad spot on the media will cause a remapping which should be transparent (if a bit slow) to us. If you write a block aligned size the same size as the physical media block size maybe this is true. If you write a sector on a device with physical sector size larger than logical block size (as allowed by say ATA7) then it's less clear what happens. I don't know if the drive firmware implements multiple tails in this case. On a read error it is worth trying the other parts of the I/O. 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... ric - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH libata-dev#upstream-fixes] pata_amd: fix an obvious bug in cable detection
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 out soon. I've updated my tree to add the -cable_detect() method, along with finishing off the (ap, adev) cleanup by passing only adev to set_pio_mode and friends, also killing the un-needed -post_set_mode() now that set_mode can be wrapped. Having a separate -cable_detect() method cleans stuff up a ton btw. Will post my tree soon for discussion. Alan - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] more IDE updates
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 cleanups/improvements (me). There are still some bugfix patches in my tree which should go into 2.6.21 but since they are quite fresh and there have already been a lot of IDE changes since the merge window was opened I will wait for -rc1 to push them upstream. [ Andrew, IDE quilt tree has already been updated wrt to this update ] Which quilt tree do you mean? I've noticed that in http://kernel.org/pub/linux/kernel/people/bart/pata-2.6/ the series file itself hasn't been updated, so this tree appears broken currently. Begging your pardon, it's all browser caching. :- Now it's *actually* borken since rtying to read delkin_cb-pci_module_init-to-pci_register_driver.patch gets you 403 Forbidden... WBR, Sergei - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] more IDE updates
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 at toshiba.co.jp) and a bunch of rather obvious cleanups/improvements (me). There are still some bugfix patches in my tree which should go into 2.6.21 but since they are quite fresh and there have already been a lot of IDE changes since the merge window was opened I will wait for -rc1 to push them upstream. [ Andrew, IDE quilt tree has already been updated wrt to this update ] Which quilt tree do you mean? I've noticed that in http://kernel.org/pub/linux/kernel/people/bart/pata-2.6/ the series file itself hasn't been updated, so this tree appears broken currently. Begging your pardon, it's all browser caching. :- Now it's *actually* borken since rtying to read delkin_cb-pci_module_init-to-pci_register_driver.patch gets you 403 Forbidden... Doh, wrong permission (600 instead of 644) - I've fixed this once already but only in the public tree and not in my private mirror so during last re-sync it got broken again. I corrected this in both trees this time :) but it will take some time for the change to propagate to kernel.org mirrors. [ Thankfully this patch is the last one in the series. ] Thanks, Bart - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Current PATA working tree
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 -set_pio_mode() that were deferred due to the number of things they touched. The current -ac1 tree I would class as unstable, its a work in progress having done all the merging and updating but not yet enough testing to shake all the bugs out Alan - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: end to end error recovery musings
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 result in a system that is non responsive until the tape restore completes two days later Which brings us back to a recent discussion at the file system workshop on being more repair oriented in file system design so we can survive situations like this a bit more reliably ;-) ric - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: end to end error recovery musings
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 push integrated klibc to have all that stuff as a unified kernel deliverable. Unfortunately, as you know, Linus apparently rejected the concept at least for now at LKS last year. With klibc this stuff could still be in one single wrapper without funny dependencies, but wouldn't have to be ported to kernel space. -hpa - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
really bad performance with ICH7 SATA controller
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 when simply copying data from dvd to hd. I think it might be the IDE/SATA controller. I tried several configurations of my kernel (tried 2.6.19 to 2.6.20.1 now) but I was not able to improve the performance. I have a notebook with this SATA controller: 00:1f.2 IDE interface [0101]: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE [8086:27c4] (rev 02) So this device seems not to be AHCI conform. I found in the web the mostly this controllers are named Serial ATA Storage Controller AHCI. Further I do have this optical drive: # hdparm -I /dev/hdd /dev/hdd: ATAPI CD-ROM, with removable media Model Number: TSSTcorpCD/DVDW SN-S082D Serial Number: Firmware Revision: SS02 Standards: Likely used CD-ROM ATAPI-1 Configuration: DRQ response: 50us. Packet size: 12 bytes Capabilities: LBA, IORDY(can be disabled) DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=227ns IORDY flow control=120ns Commands/features: Enabled Supported: HW reset results: CBLID- below Vih Device num = 0 Does someone know what is the best way to use this hardware - the best kernel config. Maybe some options do interfere. My IDE/SATA config on my 2.6.20.1 kernel looks like this: # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_IDE_TASK_IOCTL is not set # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_IDEPNP is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_ATIIXP is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_JMICRON is not set # CONFIG_BLK_DEV_SC1200 is not set CONFIG_BLK_DEV_PIIX=y # CONFIG_BLK_DEV_IT821X is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_IDE_ARM is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y # CONFIG_SCSI_TGT is not set CONFIG_SCSI_NETLINK=y # CONFIG_SCSI_PROC_FS is not set # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=y # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=y # CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set CONFIG_SCSI_CONSTANTS=y # CONFIG_SCSI_LOGGING is not set # CONFIG_SCSI_SCAN_ASYNC is not set # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=y CONFIG_SCSI_FC_ATTRS=y # CONFIG_SCSI_ISCSI_ATTRS is not set CONFIG_SCSI_SAS_ATTRS=y # CONFIG_SCSI_SAS_LIBSAS is not set # # SCSI low-level drivers # # CONFIG_ISCSI_TCP is not set # CONFIG_BLK_DEV_3W__RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_AIC94XX is not set # CONFIG_SCSI_ARCMSR is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set # CONFIG_MEGARAID_SAS is not set # CONFIG_SCSI_HPTIOP is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_FUTURE_DOMAIN is not
2.6.21-rc1: known regressions (v2) (part 1)
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 considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: resume: slab error in verify_redzone_free(): cache `size-512': memory outside object was overwritten References : http://lkml.org/lkml/2007/2/24/41 Submitter : Pavel Machek [EMAIL PROTECTED] Handled-By : Marcel Holtmann [EMAIL PROTECTED] Status : unknown Subject: ThinkPad T60: no screen after suspend to RAM References : http://lkml.org/lkml/2007/2/22/391 Submitter : Michael S. Tsirkin [EMAIL PROTECTED] Handled-By : Ingo Molnar [EMAIL PROTECTED] Status : unknown Subject: HP nx6325 notebook: usb mouse stops working after suspend to ram References : http://lkml.org/lkml/2007/2/21/413 Submitter : Arkadiusz Miskiewicz [EMAIL PROTECTED] Caused-By : Konstantin Karasyov [EMAIL PROTECTED] commit 0a6139027f3986162233adc17285151e78b39cac Status : unknown Subject: ACPI update breaks kpowersave References : http://lkml.org/lkml/2007/2/10/7 Submitter : Ismail Dönmez [EMAIL PROTECTED] Fabio Comolli [EMAIL PROTECTED] Status : unknown Subject: MacBook: AE_NOT_FOUND ACPI messages References : http://bugzilla.kernel.org/show_bug.cgi?id=8066 Submitter : Thomas Meyer [EMAIL PROTECTED] Status : unknown Subject: Asus A8N-VM motherboard: framebuffer/console boot failure boot failure (ACPI related) References : http://lkml.org/lkml/2007/2/23/132 Submitter : Andrew Nelless [EMAIL PROTECTED] Handled-By : Antonino A. Daplas [EMAIL PROTECTED] Status : problem is being debugged Subject: Asus M6Ne notebook: ACPI: First battery is not detected References : http://bugzilla.kernel.org/show_bug.cgi?id=8080 Submitter : Janosch Machowinski [EMAIL PROTECTED] Status : unknown Subject: Asus M6Ne/M6A notebooks: SATA_ACPI errors during kernel boot References : http://bugzilla.kernel.org/show_bug.cgi?id=8080 http://bugzilla.kernel.org/show_bug.cgi?id=8046 Submitter : Janosch Machowinski [EMAIL PROTECTED] Lukas Hejtmanek [EMAIL PROTECTED] Status : unknown Subject: ata-piix ACPI errors (40/80 pin cable mix) References : http://lkml.org/lkml/2007/2/22/159 Submitter : Meelis Roos [EMAIL PROTECTED] Status : unknown Subject: libata: PATA UDMA/100 configured as UDMA/33 References : http://lkml.org/lkml/2007/2/20/294 http://www.mail-archive.com/linux-ide@vger.kernel.org/msg04115.html Submitter : Fabio Comolli [EMAIL PROTECTED] Handled-By : Tejun Heo [EMAIL PROTECTED] Status : problem is being discussed Subject: sata_via failure References : http://bugzilla.kernel.org/show_bug.cgi?id=8025 Submitter : Jean-Luc Coulon [EMAIL PROTECTED] Markus Trippelsdorf [EMAIL PROTECTED] Handled-By : Tejun Heo [EMAIL PROTECTED] Patch : http://www.mail-archive.com/linux-ide@vger.kernel.org/msg03945.html Status : patch available Subject: BUG: at drivers/pci/pci.c:817 pcim_enable_device() (libata) References : http://lkml.org/lkml/2007/2/14/275 http://lkml.org/lkml/2007/2/22/367 Submitter : Rafael J. Wysocki [EMAIL PROTECTED] Lukas Hejtmanek [EMAIL PROTECTED] Handled-By : Tejun Heo [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/2/25/102 Status : patch available - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
