Re: sata_promise ata exceptions (2.6.20.6)
Given that the last one was a hardware issue, I bought a new controller. Despite my bad luck, given my price-range promise still seemed to be the one with the most good reports, so I went with that. I was going to go with a sil, but I couldn't find one.. Anyway, things are MUCH better now... but about once a week, I get: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: (port_status 0x1000) ata2.00: cmd c8/00:80:9a:71:d0/00:00:00:00:00/ea tag 0 cdb 0x0 data 65536 in res 40/00:00:06:4f:c2/00:00:00:00:00/00 Emask 0x24 (host bus error) ata2: soft resetting port ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: configured for UDMA/133 ata2: EH complete SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA It's the same port_status and Emask/SAct/SErr/action each time... only the cmd/res and data change (obviously those would change)... Can anyone tell me what that means? -- Phil Dibowitz [EMAIL PROTECTED] Open Source software and tech docsInsanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ Never write it in C if you can do it in 'awk'; Never do it in 'awk' if 'sed' can handle it; Never use 'sed' when 'tr' can do the job; Never invoke 'tr' when 'cat' is sufficient; Avoid using 'cat' whenever possible -- Taylor's Laws of Programming signature.asc Description: OpenPGP digital signature
Re: sata_promise ata exceptions (2.6.20.6)
Hi, Given that the last one was a hardware issue, I bought a new controller. Despite my bad luck, given my price-range promise still seemed to be the one with the most good reports, so I went with that. I was going to go with a sil, but I couldn't find one.. Unfortunately, I don't have a solution/fix for you, but out of curiosity, what hard-disks you have problems with ? Also what is the exact model of your SATA-controller ? Anyway, things are MUCH better now... but about once a week, I get: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: (port_status 0x1000) ata2.00: cmd c8/00:80:9a:71:d0/00:00:00:00:00/ea tag 0 cdb 0x0 data 65536 in res 40/00:00:06:4f:c2/00:00:00:00:00/00 Emask 0x24 (host bus error) ata2: soft resetting port ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: configured for UDMA/133 ata2: EH complete SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA Regards, Tomi Orava - 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: sata_promise ata exceptions (2.6.20.6)
On Sun, 15 Apr 2007 23:55:31 -0700, Phil Dibowitz wrote: Given that the last one was a hardware issue, I bought a new controller. Despite my bad luck, given my price-range promise still seemed to be the = one with the most good reports, so I went with that. I was going to go with a= sil, but I couldn't find one.. Anyway, things are MUCH better now... but about once a week, I get: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: (port_status 0x1000) ata2.00: cmd c8/00:80:9a:71:d0/00:00:00:00:00/ea tag 0 cdb 0x0 data 65536= in res 40/00:00:06:4f:c2/00:00:00:00:00/00 Emask 0x24 (host bus err= or) ata2: soft resetting port ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: configured for UDMA/133 ata2: EH complete SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't suppo= rt DPO or FUA It's the same port_status and Emask/SAct/SErr/action each time... only th= e cmd/res and data change (obviously those would change)... Can anyone tell me what that means? port_status 0x1000 is host bus timeout, which the manual defines as the host bus being busy for more than 256 clock cycles during an ATA I/O transfer. I have no idea what would cause this error, and I've never seen it myself. As long as libata recovers and doesn't downgrade your transfer speed it shouldn't pose too much of a problem. /Mikael - 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: sata_promise ata exceptions (2.6.20.6)
Tomi Orava wrote: Hi, Given that the last one was a hardware issue, I bought a new controller. Despite my bad luck, given my price-range promise still seemed to be the one with the most good reports, so I went with that. I was going to go with a sil, but I couldn't find one.. Unfortunately, I don't have a solution/fix for you, but out of curiosity, what hard-disks you have problems with ? Also what is the exact model of your SATA-controller ? Whoops, forgot that bit. Sorry! 02:0c.0 Mass storage controller: Promise Technology, Inc. PDC40718 (SATA 300 TX4) (rev 02) Subsystem: Promise Technology, Inc. PDC40718 (SATA 300 TX4) Flags: bus master, 66MHz, medium devsel, latency 72, IRQ 17 I/O ports at d480 [size=128] I/O ports at d000 [size=256] Memory at feafd000 (32-bit, non-prefetchable) [size=4K] Memory at fea8 (32-bit, non-prefetchable) [size=128K] Expansion ROM at 5002 [disabled] [size=32K] Capabilities: [60] Power Management version 2 My disks are WD WD1600JS 160GB drives (2 of them in linux software RAID 1). -- Phil Dibowitz [EMAIL PROTECTED] Open Source software and tech docsInsanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ Never write it in C if you can do it in 'awk'; Never do it in 'awk' if 'sed' can handle it; Never use 'sed' when 'tr' can do the job; Never invoke 'tr' when 'cat' is sufficient; Avoid using 'cat' whenever possible -- Taylor's Laws of Programming signature.asc Description: OpenPGP digital signature
Re: [BUG] 2.6.21-rc7 hpt366 driver broken
[ Cc's added, full bug report was in http://lkml.org/lkml/2007/4/16/18 ] On Mon, Apr 16, 2007 at 04:38:22AM -0700, Mike Mattie wrote: On Sun, 15 Apr 2007 22:48:46 -0700 Mike Mattie [EMAIL PROTECTED] wrote: Hello, I am testing the 2.6.21-rc7 kernel release. The IDE hpt366 driver is crashing hanging the boot. I have basically the same config as 2.6.20.7 which works fine (except for netconsole mentioned in a previous mail). here is the hand-copied info: * unable to handle paging request , null deref * EIP @ init_chipset_hpt366 I am running a git-bisect to see if I can resolve it to a commit. This was identified as the first broken commit: commit 7b73ee05d0acb926923d43d78b61add776ea4bb1 Author: Sergei Shtylyov [EMAIL PROTECTED] Date: Wed Feb 7 18:18:16 2007 +0100 hpt366: init code rewrite Reverting is conflicted so it will be a bit longer before I pin-point any other build-breaks. Thanks for your report. Can you use a digital camera for taking a photograph of the crash? cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen on SATA hd
On 4/15/07, Rodrigo Severo [EMAIL PROTECTED] wrote: I have this cheap SATA addon card with an ULI chipset. A have a linear raid over 3 disks one PATA, hda and two SATAs, sda and sdb. When copying data to the raid device I get log messages like the following: Apr 15 10:54:20 [kernel] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Apr 15 10:54:20 [kernel] ata1.00: cmd 35/00:00:df:90:0e/00:04:0b:00:00/e0 tag 0 cdb 0x0 data 524288 out Apr 15 10:54:20 [kernel] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Apr 15 10:54:27 [kernel] ata1: port is slow to respond, please be patient (Status 0xd0) Apr 15 10:54:48 [kernel] ata1: port failed to respond (30 secs, Status 0xd0) Apr 15 10:54:48 [kernel] ata1: soft resetting port Apr 15 10:54:48 [kernel] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Apr 15 10:54:48 [kernel] ATA: abnormal status 0xD0 on port 0x9007 - Last output repeated 6 times - Apr 15 10:54:48 [kernel] ata1.00: configured for UDMA/133 Apr 15 10:54:48 [kernel] ata1: EH complete Apr 15 10:54:48 [kernel] SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) Apr 15 10:54:48 [kernel] sda: Write Protect is off Apr 15 10:54:48 [kernel] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA All references I found to this kind of message where related to some driver issue and not hardware problems. Can this be the case? In search for a solution for this issue I bought a new HD to replace the one presenting the problem above. Now I have a SAMSUNG HD400LJ in place of the previous ST3250820AS. The problem remains the same. When I put a Maxtor 6L300S0 to perform the same hole as the Samsung or the Seagate, I couldn't trigger the exception. I bet this happened because Maxtor is immune to this issue and the Samsung (which seems to be affected) was barely used. I'm really out of ideas where to look for an explanation or fix. I don't think I'm dealing with a hardware issue. What should be my next step? Regards, Rodrigo Severo - 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: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen on SATA hd
On 4/16/07, Rodrigo Severo [EMAIL PROTECTED] wrote: On 4/15/07, Rodrigo Severo [EMAIL PROTECTED] wrote: I have this cheap SATA addon card with an ULI chipset. A have a linear raid over 3 disks one PATA, hda and two SATAs, sda and sdb. When copying data to the raid device I get log messages like the following: Apr 15 10:54:20 [kernel] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Apr 15 10:54:20 [kernel] ata1.00: cmd 35/00:00:df:90:0e/00:04:0b:00:00/e0 tag 0 cdb 0x0 data 524288 out Apr 15 10:54:20 [kernel] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Apr 15 10:54:27 [kernel] ata1: port is slow to respond, please be patient (Status 0xd0) Apr 15 10:54:48 [kernel] ata1: port failed to respond (30 secs, Status 0xd0) Apr 15 10:54:48 [kernel] ata1: soft resetting port Apr 15 10:54:48 [kernel] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Apr 15 10:54:48 [kernel] ATA: abnormal status 0xD0 on port 0x9007 - Last output repeated 6 times - Apr 15 10:54:48 [kernel] ata1.00: configured for UDMA/133 Apr 15 10:54:48 [kernel] ata1: EH complete Apr 15 10:54:48 [kernel] SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) Apr 15 10:54:48 [kernel] sda: Write Protect is off Apr 15 10:54:48 [kernel] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA All references I found to this kind of message where related to some driver issue and not hardware problems. Can this be the case? In search for a solution for this issue I bought a new HD to replace the one presenting the problem above. Now I have a SAMSUNG HD400LJ in place of the previous ST3250820AS. The problem remains the same. When I put a Maxtor 6L300S0 to perform the same hole as the Samsung or the Seagate, I couldn't trigger the exception. I bet this happened because Maxtor is immune to this issue and the Samsung (which seems to be affected) was barely used. Now with kernel 2.6.21-rc6, addon board reattached and cables changed I still get messages like the following every 10 minutes or so under high load: Apr 16 13:03:27 [kernel] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Apr 16 13:03:27 [kernel] ata1.00: cmd 35/00:00:91:fd:06/00:04:0b:00:00/e0 tag 0 cdb 0x0 data 524288 out Apr 16 13:03:27 [kernel] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Apr 16 13:03:35 [kernel] ata1: port is slow to respond, please be patient (Status 0xd0) Apr 16 13:03:58 [kernel] ata1: port failed to respond (30 secs, Status 0xd0) Apr 16 13:03:58 [kernel] ata1: soft resetting port Apr 16 13:03:58 [kernel] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Apr 16 13:03:58 [kernel] ata1.00: configured for UDMA/133 Apr 16 13:03:58 [kernel] ata1: EH complete Apr 16 13:03:58 [kernel] SCSI device sda: 781422768 512-byte hdwr sectors (400088 MB) Apr 16 13:03:58 [kernel] sda: Write Protect is off Apr 16 13:03:58 [kernel] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA Is this expected behavior? Rodrigo Severo - 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
[RFC/PATCH -mm] add pci_try_set_mwi
On Thu, 5 Apr 2007 14:20:01 -0700 Andrew Morton wrote:
hm. Well, what to do?
How about we prevail upon Randy to:
- rename pci_set_mwi() to pci_try_set_mwi()
- make it return 0 on success, 1 if the try failed
- make it return -EFOO on error (presently unimplemented)
- review callers
- remove __must_check
?
From: Randy Dunlap [EMAIL PROTECTED]
As suggested by Andrew, add pci_try_set_mwi(), which does not require
return-value checking.
- add pci_try_set_mwi() without __must_check
- make it return 0 on success, errno if the try failed or error
- review callers
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
Documentation/pci.txt |5 +++-
drivers/ata/pata_cs5530.c |2 -
drivers/ide/pci/cs5530.c |2 -
drivers/net/cassini.c |4 +--
drivers/net/starfire.c |2 -
drivers/net/tulip/tulip_core.c |2 -
drivers/net/wireless/mac80211/p54/prism54pci.c |2 -
drivers/net/wireless/prism54/islpci_hotplug.c |3 --
drivers/pci/pci.c | 28 +
drivers/scsi/lpfc/lpfc_init.c |5
drivers/usb/gadget/net2280.c |2 -
include/linux/pci.h|1
12 files changed, 39 insertions(+), 19 deletions(-)
--- linux-2.6.21-rc6-mm1.orig/include/linux/pci.h
+++ linux-2.6.21-rc6-mm1/include/linux/pci.h
@@ -547,6 +547,7 @@ void pci_set_master(struct pci_dev *dev)
int pci_set_pcie_reset_state(struct pci_dev *dev, enum pcie_reset_state state);
#define HAVE_PCI_SET_MWI
int __must_check pci_set_mwi(struct pci_dev *dev);
+int pci_try_set_mwi(struct pci_dev *dev);
void pci_clear_mwi(struct pci_dev *dev);
void pci_intx(struct pci_dev *dev, int enable);
void pci_msi_off(struct pci_dev *dev);
--- linux-2.6.21-rc6-mm1.orig/drivers/pci/pci.c
+++ linux-2.6.21-rc6-mm1/drivers/pci/pci.c
@@ -1162,6 +1162,11 @@ int pci_set_mwi(struct pci_dev *dev)
return 0;
}
+int pci_try_set_mwi(struct pci_dev *dev)
+{
+ return 0;
+}
+
void pci_clear_mwi(struct pci_dev *dev)
{
}
@@ -1218,9 +1223,7 @@ pci_set_cacheline_size(struct pci_dev *d
* pci_set_mwi - enables memory-write-invalidate PCI transaction
* @dev: the PCI device for which MWI is enabled
*
- * Enables the Memory-Write-Invalidate transaction in %PCI_COMMAND,
- * and then calls @pcibios_set_mwi to do the needed arch specific
- * operations or a generic mwi-prep function.
+ * Enables the Memory-Write-Invalidate transaction in %PCI_COMMAND.
*
* RETURNS: An appropriate -ERRNO error value on error, or zero for success.
*/
@@ -1236,7 +1239,8 @@ pci_set_mwi(struct pci_dev *dev)
pci_read_config_word(dev, PCI_COMMAND, cmd);
if (! (cmd PCI_COMMAND_INVALIDATE)) {
- pr_debug(PCI: Enabling Mem-Wr-Inval for device %s\n,
pci_name(dev));
+ pr_debug(PCI: Enabling Mem-Wr-Inval for device %s\n,
+ pci_name(dev));
cmd |= PCI_COMMAND_INVALIDATE;
pci_write_config_word(dev, PCI_COMMAND, cmd);
}
@@ -1245,6 +1249,21 @@ pci_set_mwi(struct pci_dev *dev)
}
/**
+ * pci_try_set_mwi - enables memory-write-invalidate PCI transaction
+ * @dev: the PCI device for which MWI is enabled
+ *
+ * Enables the Memory-Write-Invalidate transaction in %PCI_COMMAND.
+ * Callers are not required to check the return value.
+ *
+ * RETURNS: An appropriate -ERRNO error value on error, or zero for success.
+ */
+int pci_try_set_mwi(struct pci_dev *dev)
+{
+ int rc = pci_set_mwi(dev);
+ return rc;
+}
+
+/**
* pci_clear_mwi - disables Memory-Write-Invalidate for device dev
* @dev: the PCI device to disable
*
@@ -1418,6 +1437,7 @@ EXPORT_SYMBOL(pci_release_selected_regio
EXPORT_SYMBOL(pci_request_selected_regions);
EXPORT_SYMBOL(pci_set_master);
EXPORT_SYMBOL(pci_set_mwi);
+EXPORT_SYMBOL(pci_try_set_mwi);
EXPORT_SYMBOL(pci_clear_mwi);
EXPORT_SYMBOL_GPL(pci_intx);
EXPORT_SYMBOL(pci_set_dma_mask);
--- linux-2.6.21-rc6-mm1.orig/drivers/ata/pata_cs5530.c
+++ linux-2.6.21-rc6-mm1/drivers/ata/pata_cs5530.c
@@ -270,7 +270,7 @@ static int cs5530_init_chip(void)
}
pci_set_master(cs5530_0);
- pci_set_mwi(cs5530_0);
+ pci_try_set_mwi(cs5530_0);
/*
* Set PCI CacheLineSize to 16-bytes:
--- linux-2.6.21-rc6-mm1.orig/drivers/ide/pci/cs5530.c
+++ linux-2.6.21-rc6-mm1/drivers/ide/pci/cs5530.c
@@ -236,7 +236,7 @@ static unsigned int __devinit init_chips
*/
pci_set_master(cs5530_0);
- pci_set_mwi(cs5530_0);
+ pci_try_set_mwi(cs5530_0);
/*
* Set PCI CacheLineSize to 16-bytes:
--- linux-2.6.21-rc6-mm1.orig/drivers/usb/gadget/net2280.c
+++ linux-2.6.21-rc6-mm1/drivers/usb/gadget/net2280.c
@@ -2964,7 +2964,7 @@ static int net2280_probe (struct pci_dev
, dev-pci-pcimstctl);
Re: [PATCH 0/4] bidi support: block layer bidirectional io.
Boaz Harrosh wrote:
Following are 4 (large) patches for support of bidirectional
block I/O in kernel. (not including SCSI-ml or iSCSI)
The submitted work is against linux-2.6-block tree as of
2007/04/15, and will only cleanly apply in succession.
The patches are based on the RFC I sent 3 months ago. They only
cover the block layer at this point. I suggest they get included
in Morton's tree until they reach the kernel so they can get
compiled on all architectures/platforms. There is still a chance
that architectures I did not compile were not fully converted.
(FWIW, my search for use of struct request members failed to find
them). If you find such a case, please send me the file
name and I will fix it ASAP.
Patches summary:
1. [PATCH 1/4] bidi support: request dma_data_direction
- Convert REQ_RW bit flag to a dma_data_direction member like in
SCSI-ml use.
- removed rq_data_dir() and added other APIs for querying request's
direction.
- fix usage of rq_data_dir() and peeking at req-cmd_flags REQ_RW to
using
new api.
- clean-up bad usage of DMA_BIDIRECTIONAL and bzero of none-queue
requests,
to use the new blk_rq_init_unqueued_req()
2. [PATCH 2/4] bidi support: fix req-cmd == INT cases
- Digging into all these old drivers, I have found traces of past life
where request-cmd was the command type. This patch fixes some of
these
places. All drivers touched by this patch are clear indication of
drivers
that were not used for a while. Should we removed them from Kernel?
These Are:
drivers/acorn/block/fd1772.c, drivers/acorn/block/mfmhd.c,
drivers/block/nbd.c, drivers/cdrom/aztcd.c,
drivers/cdrom/cm206.c
drivers/cdrom/gscd.c, drivers/cdrom/mcdx.c,
drivers/cdrom/optcd.c
drivers/cdrom/sjcd.c, drivers/ide/legacy/hd.c,
drivers/block/amiflop.c
2. [PATCH 3/4] bidi support: request_io_part
- extract io related fields in struct request into struct
request_io_part
in preparation to full bidi support.
- new rq_uni() API to access the sub-structure. (Please read below
comment
on why an API and not open code the access)
- Convert All users to new API.
3. [PATCH 4/4] bidi support: bidirectional block layer
- add one more request_io_part member for bidi support in struct
request.
- add block layer API functions for mapping and accessing bidi data
buffers
and for ending a block request as a whole (end_that_request_block())
Developer comments:
patch 1/4: Borrow from struct scsi_cmnd use of enum dma_data_direction.
Further work (in
progress) is the removal of the corresponding member from struct scsi_cmnd
and converting
all users to directly access rq_dma_dir(sc-req).
patch 3/4: The reasons for introducing the rq_uni(req) API rather than
directly accessing
req-uni are:
* WARN(!bidi_dir(req)) is life saving when developing bidi enabled paths.
Once we, bidi
users, start to push bidi requests down the kernel paths, we immediately
get warned of
paths we did not anticipate. Otherwise, they will be very hard to find, and
will hurt
kernel stability.
* A cleaner and saner future implementation could be in/out members rather
than
uni/bidi_read. This way the dma_direction member can deprecated and the
uni sub-
structure can be maintained using a pointer in struct req.
With this API we are free to change the implementation in the future without
touching any users of the API. We can also experiment with what's best.
Also, with the
API it is much easier to convert uni-directional drivers for bidi (look in
ll_rw_block.c in patch 4/4).
* Note, that internal uses inside the block layer access req-uni directly,
as they will
need to be changed if the implementation of req-{uni, bidi_read} changes.
Boaz,
Recently I have been looking at things from the perspective
of a SAS target and thinking about bidi commands. Taking
XDWRITEREAD(10) in sbc3r09.pdf (section 5.44) as an example,
with DISABLE_WRITE=0, the device server in the target should
do the following:
a) decode the cdb **
b) read from storage [lba, transfer_length]
c) fetch data_out from initiator [transfer_length] ***
d) XOR data from (b) and (c) and place result in (z)
e) write the data from (c) to storage [lba, transfer_length]
f) send (z) in data_in to initiator [transfer_length]
g) send SCSI completion status to initiator
Logically a) must occur first and g) last. The b) to f)
sequence could be repeated (perhaps) by the device server
subdividing the transfer_length (i.e. it may not be
reasonable for the OS to assume that the data_out transfer
will be complete before there is any data_in transfer).
With this command (and with most other bidi commands
Driver update for CentOS 4.4 2.6.9.-42.0.10
PS Sorry forgot to send a subject with my last email A little more info: For the default CentOS4.4 kernel (2.6.9.-42.0.10) kept up2date using yum from dmesg: libata version is 1.20 for latest kernel.org libata version is 2.00 so to reword questions: 1) How would I use the latest CentOS 4.4 (2.6.9.x kernel) but also add the ;atest fixes in libata version 2.0 2) Any chance CentOS will include the latest libata 2.0 in normal kernel updates so I could just run yum update kernel* instead of compiling a custom kernel Thanks again for your time, Al Smith -- Original message -- From: [EMAIL PROTECTED] Dear Mr Garzik, Thanks so much for all the time(unpaid?) you've put in developing drivers My problems specifically concerns a Promise ESATA 300 TX2plus which is bundled with the Seagate 300GB eSATA drive -easily available via CompUSA and major reatailers. (If Seagate doesn't hire you - they are crazy!) I'm running CentOS4.4 with latest kernel updates currently 2.6.9-42.0.10EL I've seen other people with same timeout problems but after compiling the latest kernel 2.6.20.7, I get no more errors, so I know you've been busy fixing it -but also get other errors (not concerning the drive or you're fixes) Problem is how to I apply whatever fixes you've made to the latest CentOS4.4 2.6.9-42.0.10 kernel since I can't run my custom 2.6.20.7 kernel yet 1) Will CentOS(RedHat - equiv) be upgrading their kernel to include you're fixes in the current 2.6.9-x kernel? 2)Can you give me a link or howto on using the latest CentOS 4.4 kernel but also adding whatever fixes you've made Thanks, Al Smith - 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: Loud pop coming from hard drive on reboot
Jan Engelhardt wrote: On Apr 15 2007 12:53, Henrique de Moraes Holschuh wrote: On Sat, 14 Apr 2007, Pavel Machek wrote: How common are notebooks that cut power to disks during reboot? Assuming it also does this when running Windows, I'd report it as a grave bug to the vendor and demand it to be fixed, or the machine to be exchanged with another model that doesn't have this defect. Given that it does not happen on Windows (IIRC Chuck's post), then just what is Windows [not] doing that Linux does? It looks like there are two problems here: (1) Some notebooks power off and back on when restarting. Both Linux and other OS handle that badly because they assume power is not interrupted on reboot. The noise emitted is relatively loud. (2) Linux (alone) gives a very muted pop on shutdown. This could be from bad interaction with the shutdown command, or some other reason (drive not given enough time to shut down?) The noise is not very loud, maybe the head did not have to move very far? - 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: [1/2] 2.6.21-rc7: known regressions
Adrian Bunk wrote: Subject: laptops with e1000: lockups References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 Submitter : Dave Jones [EMAIL PROTECTED] Handled-By : Jesse Brandeburg [EMAIL PROTECTED] Status : problem is being debugged this is being actively debugged, here is what we have so far: o v2.6.20: crashes during boot, unless noacpi and nousb bootparams used o v2.6.21-rc6: some userspace issue, crashes just after root mount without init=/bin/bash o v2.6.2X: serial console in docking station spews goo at all speeds with console=ttyS0,n8 . work continues on this, as we don't know if there are kernel panic messages during the hard lock. o fedora 7 test kernel 2948: boots okay, have been using this as only truly working kernel on this machine. one reproduction of the problem was had with scp -l 5000 file remote when linked at 100Mb/Full. Tried probably 20 other times same test with no repro, ugh. Otherwise, slogging through continues. We are actively working on this in case it *is* an e1000 issue. Right now the repro is so unlikely we could hardly tell if we fixed it. Jesse PS .config available on request - 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: [1/2] 2.6.21-rc7: known regressions
On Mon, Apr 16, 2007 at 05:14:40PM -0700, Brandeburg, Jesse wrote: Adrian Bunk wrote: Subject: laptops with e1000: lockups References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 Submitter : Dave Jones [EMAIL PROTECTED] Handled-By : Jesse Brandeburg [EMAIL PROTECTED] Status : problem is being debugged this is being actively debugged, here is what we have so far: o v2.6.20: crashes during boot, unless noacpi and nousb bootparams used o v2.6.21-rc6: some userspace issue, crashes just after root mount without init=/bin/bash o v2.6.2X: serial console in docking station spews goo at all speeds with console=ttyS0,n8 . work continues on this, as we don't know if there are kernel panic messages during the hard lock. o fedora 7 test kernel 2948: boots okay, have been using this as only truly working kernel on this machine. one reproduction of the problem was had with scp -l 5000 file remote when linked at 100Mb/Full. Tried probably 20 other times same test with no repro, ugh. Otherwise, slogging through continues. We are actively working on this in case it *is* an e1000 issue. Right now the repro is so unlikely we could hardly tell if we fixed it. FWIW, I can reproduce this pretty much ondemand, on 100M through the ethernet port on a netgear wireless AP. A number of our Fedora7 testers are also able to easily reproduce this. To isolate e1000, for tomorrows test build I've reverted e1000 to the same code that was in 2.6.20. If that works out without causing hangs, I'll try and narrow down further which of the dozen csets is responsible. Dave -- http://www.codemonkey.org.uk - 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: [1/2] 2.6.21-rc7: known regressions
Dave Jones wrote: On Mon, Apr 16, 2007 at 05:14:40PM -0700, Brandeburg, Jesse wrote: Adrian Bunk wrote: Subject: laptops with e1000: lockups References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 Submitter : Dave Jones [EMAIL PROTECTED] Handled-By : Jesse Brandeburg [EMAIL PROTECTED] Status : problem is being debugged this is being actively debugged, here is what we have so far: o v2.6.20: crashes during boot, unless noacpi and nousb bootparams used o v2.6.21-rc6: some userspace issue, crashes just after root mount without init=/bin/bash o v2.6.2X: serial console in docking station spews goo at all speeds with console=ttyS0,n8 . work continues on this, as we don't know if there are kernel panic messages during the hard lock. o fedora 7 test kernel 2948: boots okay, have been using this as only truly working kernel on this machine. one reproduction of the problem was had with scp -l 5000 file remote when linked at 100Mb/Full. Tried probably 20 other times same test with no repro, ugh. Otherwise, slogging through continues. We are actively working on this in case it *is* an e1000 issue. Right now the repro is so unlikely we could hardly tell if we fixed it. FWIW, I can reproduce this pretty much ondemand, on 100M through the ethernet port on a netgear wireless AP. A number of our Fedora7 testers are also able to easily reproduce this. To isolate e1000, for tomorrows test build I've reverted e1000 to the same code that was in 2.6.20. If that works out without causing hangs, I'll try and narrow down further which of the dozen csets is responsible. Also, there are e1000 fixes in -mm. At the time (rc2? rc3?) I felt it was best to get that into -mm for testing, rather than fast-tracking it to 2.6.21. But hey, see if they help. It's the netdev-2.6.git#e1000-fixes branch, if you are git-ified. I was going to push them first thing 2.6.22. Jeff - 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
2.6.21-rc6-mm1 ATA HPT37x regression
Hi Jeff and crew, I was just testing out 2.6.21-rc6-mm1 to test some Cyclades patches and I noticed that my HPT302 (rev1) controller with a pair of 120gb WD disks are not longer detected and I get the following in the dmesg logs: [ 148.121490] hpt37x: DPLL did not stabilize. Where before, under 2.6.21-rc6 I got the following: [ 173.749349] pata_hpt37x: BIOS has not set timing clocks. [ 173.752949] hpt37x: HPT302: Bus clock 33MHz. [ 173.754409] ACPI: PCI Interrupt :03:06.0[A] - GSI 18 (level, low) - IRQ 18 [ 173.758403] ata5: PATA max UDMA/133 cmd 0x0001ecf8 ctl 0x0001ecf2 bmdma 0x000 1e800 irq 18 [ 173.761396] ata6: PATA max UDMA/133 cmd 0x0001ece0 ctl 0x0001ecda bmdma 0x000 1e808 irq 18 [ 173.764319] scsi6 : pata_hpt37x [ 173.928997] ATA: abnormal status 0x78 on port 0x0001ecff [ 173.930511] scsi7 : pata_hpt37x [ 174.094906] ATA: abnormal status 0x8 on port 0x0001ece7 Here's my lspci infomation on the board, it's an addon. My apologies for the crappy word wrapping, xterms inside screen, etc. 03:06.0 RAID bus controller: Triones Technologies, Inc. HPT302/302N (rev 01) Subsystem: Triones Technologies, Inc. Unknown device 0001 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort - MAbort- SERR- PERR- Latency: 120 (2000ns min, 2000ns max) Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at ecf8 [size=8] Region 1: I/O ports at ecf0 [size=4] Region 2: I/O ports at ece0 [size=8] Region 3: I/O ports at ecd8 [size=4] Region 4: I/O ports at e800 [size=256] Expansion ROM at f900 [disabled] [size=128K] Capabilities: [60] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot -,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 03:0a.0 SCSI storage controller: Adaptec AHA-2940U2/U2W / 7890/7891 Subsystem: Dell Unknown device 0087 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Step ping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort - MAbort- SERR- PERR- Latency: 64 (9750ns min, 6250ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 BIST result: 00 Region 0: I/O ports at e400 [disabled] [size=256] Region 1: Memory at f8fff000 (64-bit, non-prefetchable) [size=4K] Expansion ROM at f100 [disabled] [size=128K] Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot -,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- I'm moving to 2.6.21-rc7 now, but I'm willing to test out patches as needed. I suspect it's the move from the 0.6.0 driver to the 0.6.5 version, and the changes in the hpt_clock hpt37x_timings_* arrays, but god knows which ones are affecting me. Thanks, John - 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
