a disk timeout and a disk state
Jeff Hello We have in our machines several sata (mostly maxtor-segate) disks in an array. These disks generate too many ata-io errors at clients sites. From raid1 code I have learned that a re-write sometimes fixes a disk. Question: Why ? Question: Does it always work ? Question: Does rewriting a slow sector also reduces a disk error rate, does it make any sense ? thank you -- Raz - 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: [Bugme-new] [Bug 8976] New: Regression (ata_piix): Kernel panic during driver initialization
Andrew Morton writes: On Mon, 3 Sep 2007 13:40:10 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8976 This one is apparantly a post-2.6.22 regression. The ata_piix oops at init bug in 2.6.23-rc5 has already been fixed. There's a link to the patch at the bugzilla entry quoted above. - 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: port is slow to respond, reset failed
Peter Favrholdt writes: Hi, Below some more info on my two systems: Mikael Pettersson wrote: I assume the PE1800 has some Intel chipset? Which one? ... :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2) :00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (rev 02) ICH5. Should be decent enough. And the machine that does have problems, what chipset does it have? ... 00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3) nForce2. Hmm.. cat /proc/interrupts CPU0 0: 79XT-PIC-XTtimer 1: 2XT-PIC-XTi8042 2: 0XT-PIC-XTcascade 5: 141710XT-PIC-XTsk98lin 6: 5XT-PIC-XTfloppy 7: 35XT-PIC-XTparport0 8: 1XT-PIC-XTrtc 9: 6XT-PIC-XTacpi, ehci_hcd:usb1, ohci1394 10: 0XT-PIC-XTMPU401 UART 11: 27474XT-PIC-XTlibata, libata, ohci_hcd:usb3, NVidia nForce2 12: 15057XT-PIC-XTohci_hcd:usb2 14: 23211XT-PIC-XTide0 15: 32805XT-PIC-XTide1 NMI: 3911 LOC: 917176 ERR: 0 The promise card is sharing IRQ11 with usb, the other libata device, and nForce2 (wonder what that is?) That mystery device makes me strongly suspect that you've loaded the binary-only nvidia drivers. If that's true, then the machine's problems may just as well be caused by that driver, not sata_promise. (We've seen that happen before.) I'm actually beginning to think there's some PCI compatibility breakage somewhere, as I too see sata_promise working fine in some machines but not in others. Alas, my knowledge of PCI tweakables is close to nil. I second that (although I'm really clueless about PCI). Could it be that at 3.0Gbps with 4 ports running at full speed contention on the pci bus cause this behavior? This would explain why a PCI-X port helps (or limiting to 1.5Gbps). Or maybe it is an NFORCE2 issue... Or too many IRQ-handlers on the same IRQ... I wish I could do something more to help. Unfortunately it is almost impossible for me to do tests on the Intel system (as it is a production system) - though I might be able to try some things late at night in the weekends ;-) Guess at this point it would be nice to be able to reproduce the behavior on an Intel system... I can reproduce it on an Intel 440BX chipset machine with a PIII. However, that chipset, while very good in its day, is rather old now. I'll run some more tests this weekend on less ancient hardware. /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
pata_pdc202xx_old bug? (ATA bus error)
anyone come up with a patch/fix for this? i also tried this drive on the system ide ports and it worked fine (also uses libata drivers, nforce2), it seems to be something wrong in the pata_pdc202xx_old code. what can i do to get this fixed? the drive is a seagate. i dont know what res 51/84:00:3f:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error) means this is a really strange and hard to reproduce bug since all my other drives work (all maxtors , and one wd) just the seagate gets this error (and only on the PDC20267 card) thanks. ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 ata3.00: (BMDMA stat 0x4) ata3.00: cmd ca/00:01:3f:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 512 out res 51/84:00:3f:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error) ata3: soft resetting port ata3.00: configured for UDMA/100 ata3: EH complete ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 ata3.00: (BMDMA stat 0x4) ata3.00: cmd ca/00:01:3f:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 512 out res 51/84:00:3f:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error) ata3: soft resetting port ata3.00: configured for UDMA/100 ata3: EH complete sd 2:0:0:0: [sde] 234441648 512-byte hardware sectors (120034 MB) ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 ata3.00: (BMDMA stat 0x4) ata3.00: cmd ca/00:01:3f:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 512 out res 51/84:00:3f:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error) ata3: soft resetting port ata3.00: configured for UDMA/100 ata3: EH complete sd 2:0:0:0: [sde] Write Protect is off sd 2:0:0:0: [sde] Mode Sense: 00 3a 00 00 ata3.00: limiting speed to UDMA/66:PIO4 ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 ata3.00: (BMDMA stat 0x4) ata3.00: cmd ca/00:01:3f:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 512 out res 51/84:00:3f:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error) ata3: soft resetting port ata3.00: configured for UDMA/66 ata3: EH complete ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 ata3.00: (BMDMA stat 0x4) ata3.00: cmd ca/00:01:3f:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 512 out res 51/84:00:3f:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error) ata3: soft resetting port ata3.00: configured for UDMA/66 ata3: EH complete sd 2:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 ata3.00: (BMDMA stat 0x4) ata3.00: cmd ca/00:01:3f:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 512 out res 51/84:00:3f:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error) ata3: soft resetting port ata3.00: configured for UDMA/66 sd 2:0:0:0: [sde] Result: hostbyte=0x00 driverbyte=0x08 sd 2:0:0:0: [sde] Sense Key : 0xb [current] [descriptor] Descriptor sense data with sense descriptors (in hex): 72 0b 47 00 00 00 00 0c 00 0a 80 00 00 00 00 00 00 00 00 3f sd 2:0:0:0: [sde] ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sde, sector 63 ata3: EH complete sd 2:0:0:0: [sde] 234441648 512-byte hardware sectors (120034 MB) Filesystem sde1: Disabling barriers, trial barrier write failed sd 2:0:0:0: [sde] Write Protect is off sd 2:0:0:0: [sde] Mode Sense: 00 3a 00 00 XFS mounting filesystem sde1 sd 2:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 2:0:0:0: [sde] 234441648 512-byte hardware sectors (120034 MB) sd 2:0:0:0: [sde] Write Protect is off sd 2:0:0:0: [sde] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 ata3.00: (BMDMA stat 0x4) ata3.00: cmd ca/00:00:17:b6:fc/00:00:00:00:00/e6 tag 0 cdb 0x0 data 131072 out res 51/84:00:17:b6:fc/00:00:00:00:00/e6 Emask 0x10 (ATA bus error) ata3: soft resetting port ata3.00: configured for UDMA/66 ata3: EH complete ata3.00: limiting speed to UDMA/33:PIO4 ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 ata3.00: (BMDMA stat 0x4) ata3.00: cmd ca/00:00:17:b6:fc/00:00:00:00:00/e6 tag 0 cdb 0x0 data 131072 out res 51/84:00:17:b6:fc/00:00:00:00:00/e6 Emask 0x10 (ATA bus error) ata3: soft resetting port ata3.00: configured for UDMA/33 ata3: EH complete ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 ata3.00: (BMDMA stat 0x4) ata3.00: cmd ca/00:00:17:b6:fc/00:00:00:00:00/e6 tag 0 cdb 0x0 data 131072 out res 51/84:00:17:b6:fc/00:00:00:00:00/e6 Emask 0x10 (ATA bus error) ata3: soft resetting port ata3.00: configured for UDMA/33 ata3: EH complete ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 ata3.00: (BMDMA stat 0x4) ata3.00: cmd ca/00:00:17:b6:fc/00:00:00:00:00/e6 tag 0 cdb 0x0 data 131072 out res 51/84:00:17:b6:fc/00:00:00:00:00/e6 Emask 0x10 (ATA bus error) ata3: soft resetting port ata3.00: configured for UDMA/33 ata3: EH complete ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 ata3.00: (BMDMA stat 0x4) ata3.00: cmd
ICH Intel PATA short cable override...
We see that in ata_piix.c, there is a whitelist for (laptop) Intel ICH controllers with short cables, tied to specific vendor subsystem IDs. Since my mini-ITX Ibase MI910F has the subsystem IDs specified as Intel [1], this is unusable. I can't find another existing mechanism to add short cable information, to allow UDMA/66 for my on-board CF socket. Do you suggest I cook a patch to pass a kernel argument eg 'ich=short' or 'pata=short', or can you think of a better mechanism? Thanks, Daniel --- [1] # lspci -vs 00:1f.2 00:1f.2 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA IDE Controller (rev 03) (prog-if 80 [Master]) Subsystem: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA IDE Controller # lspci -vns 00:1f.2 00:1f.2 0101: 8086:2828 (rev 03) (prog-if 80 [Master]) Subsystem: 8086:2828 -- Daniel J Blueman - 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: port is slow to respond, reset failed
Mikael Pettersson wrote: nForce2. Hmm.. Peter Favrholdt wrote: 11: 27474XT-PIC-XTlibata, libata, ohci_hcd:usb3, NVidia nForce2 That mystery device makes me strongly suspect that you've loaded the binary-only nvidia drivers. If that's true, then the machine's problems may just as well be caused by that driver, not sata_promise. (We've seen that happen before.) I didn't load any special NVidia driver - vanilla kernel only. The graphics card is Matrox G550. The nForce2 could be the nForce2 SMBus or the nForce2 IDE. Here is the result of dmesg | grep -i nforce [ 26.379422] NFORCE2: IDE controller at PCI slot :00:09.0 [ 26.379481] NFORCE2: chipset revision 162 [ 26.379525] NFORCE2: not 100% native mode: will probe irqs later [ 26.379575] NFORCE2: BIOS didn't set cable bits correctly. Enabling workaround. [ 26.379634] NFORCE2: :00:09.0 (rev a2) UDMA133 controller [ 31.861284] i2c_adapter i2c-0: nForce2 SMBus adapter at 0x5000 [ 31.861391] i2c_adapter i2c-1: nForce2 SMBus adapter at 0x5500 I can reproduce it on an Intel 440BX chipset machine with a PIII. However, that chipset, while very good in its day, is rather old now. I believe the problem here only shows if all four sata ports are stressed simultaneously (I should test this thoroughly). The dependence on Barracuda 7200.10 could be because these disks are faster than the others tested, this needed in order for the PCI contention to arise? (I'm still wild-guessing here). Best regards, Peter - 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: CF as IDE on ICH6M using libata
On 03/09/07, Tejun Heo [EMAIL PROTECTED] wrote: Eddie Hung wrote: I am pursuing another possibility: the CF card is not a genuine Sandisk one at all, especially as it was off eBay! I compared my hdparm -I with the one in the thread above (which as I've found out is a Sandisk Extreme II 4GB) and there are big differences, namely the model number, serial number and firmware version. This might explain everything! We still need to fix your device. :-) -- tejun Uhm.. it seems like I spoke too soon! I have now acquired a Sandisk Extreme III 8GB CF card, from a reputable source, but it doesn't support UDMA as the Extreme IV card was supposed to... and this means I'm getting MWDMA again - and the same timeout problems! I had previously blamed the timeout problems on it being a completely naff card which wasn't standards compliant, but now I know this can't be the case. Here is the hdparm: /dev/sda: CompactFlash ATA device, with removable media Model Number: SanDisk SDCFX3-8192 Serial Number: 019324G2207I5851 Firmware Revision: HDX 4.03 Standards: Supported: 4 Likely used: 4 Configuration: Logical max current cylinders 15880 15880 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16007040 LBAuser addressable sectors: 16007040 device size with M = 1024*1024:7815 MBytes device size with M = 1000*1000:8195 MBytes (8 GB) Capabilities: LBA, IORDY(may be)(cannot be disabled) Standby timer values: spec'd by Vendor R/W multiple sector transfer: Max = 4 Current = 0 DMA: mdma0 mdma1 *mdma2 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: Write cache *CFA feature set *CFA advanced modes: pio5 *pio6 Note that it does identify PIO5 and PIO6 (answering my previous question), with PIO6 even starred. I got about 9MB/s under hdparm, too. However, the timeouts remain, I triggered it again by doing a mkfs.ext3. Any ideas? Thanks, Eddie - 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: port is slow to respond, reset failed
Peter Favrholdt writes: Mikael Pettersson wrote: nForce2. Hmm.. Peter Favrholdt wrote: 11: 27474XT-PIC-XTlibata, libata, ohci_hcd:usb3, NVidia nForce2 That mystery device makes me strongly suspect that you've loaded the binary-only nvidia drivers. If that's true, then the machine's problems may just as well be caused by that driver, not sata_promise. (We've seen that happen before.) I didn't load any special NVidia driver - vanilla kernel only. The graphics card is Matrox G550. The nForce2 could be the nForce2 SMBus or the nForce2 IDE. Here is the result of dmesg | grep -i nforce [ 26.379422] NFORCE2: IDE controller at PCI slot :00:09.0 [ 26.379481] NFORCE2: chipset revision 162 [ 26.379525] NFORCE2: not 100% native mode: will probe irqs later [ 26.379575] NFORCE2: BIOS didn't set cable bits correctly. Enabling workaround. [ 26.379634] NFORCE2: :00:09.0 (rev a2) UDMA133 controller [ 31.861284] i2c_adapter i2c-0: nForce2 SMBus adapter at 0x5000 [ 31.861391] i2c_adapter i2c-1: nForce2 SMBus adapter at 0x5500 OK, sorry about that. The 'NVidia nForce2' string does occur in two sound drivers, so that may be where it's coming from. I can reproduce it on an Intel 440BX chipset machine with a PIII. However, that chipset, while very good in its day, is rather old now. I believe the problem here only shows if all four sata ports are stressed simultaneously (I should test this thoroughly). The dependence on Barracuda 7200.10 could be because these disks are faster than the others tested, this needed in order for the PCI contention to arise? (I'm still wild-guessing here). On my old 440BX reading a single Barracuda (7200.10 or .9 I don't remember) or Spinpoint disk was enough to trigger the errors. /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: [PATCH 6/7] blk_end_request: remove/unexport end_that_request_*
Boaz raised my attention to this patchset today...
We suspect we'll still need the extern entry points for handling the bidi
request in the scsi_io_completion() path as we only want to call
end_that_request_chunk on req-next_rq and never
end_that_request_last.
(see
http://www.bhalevy.com/open-osd/download/linux-2.6.23-rc2_and_iscsi-iscsi-2007_08_09/0005-SCSI-bidi-support.patch)
If this is ok with you I'd leave these entry points in place rather than
taking them out and putting them back in later.
Benny
From: [EMAIL PROTECTED] on behalf of Kiyoshi Ueda
Sent: Sat 2007-09-01 01:43
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux-ide@vger.kernel.org; [EMAIL
PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [PATCH 6/7] blk_end_request: remove/unexport end_that_request_*
This patch removes the following functions:
o end_that_request_first()
o end_that_request_chunk()
and stops exporting the functions below:
o end_that_request_last()
Signed-off-by: Kiyoshi Ueda [EMAIL PROTECTED]
Signed-off-by: Jun'ichi Nomura [EMAIL PROTECTED]
---
block/ll_rw_blk.c | 61
- include/linux/blkdev.h | 15
2 files changed, 21 insertions(+), 55 deletions(-)
diff -rupN 05-ide-cd-change/block/ll_rw_blk.c
06-remove-old-interface/block/ll_rw_blk.c
--- 05-ide-cd-change/block/ll_rw_blk.c 2007-08-24 12:11:02.0 -0400
+++ 06-remove-old-interface/block/ll_rw_blk.c 2007-08-24 12:19:02.0
-0400
@@ -3388,6 +3388,20 @@ static void blk_recalc_rq_sectors(struct
}
}
+/**
+ * __end_that_request_first - end I/O on a request
+ * @req: the request being processed
+ * @uptodate: 1 for success, 0 for I/O error, 0 for specific error
+ * @nr_bytes: number of bytes to complete
+ *
+ * Description:
+ * Ends I/O on a number of bytes attached to @req, and sets it up
+ * for the next range of segments (if any) in the cluster.
+ *
+ * Return:
+ * 0 - we are done with this request, call end_that_request_last()
+ * 1 - still buffers pending for this request
+ **/
static int __end_that_request_first(struct request *req, int uptodate,
int nr_bytes)
{
@@ -3498,49 +3512,6 @@ static int __end_that_request_first(stru
return 1;
}
-/**
- * end_that_request_first - end I/O on a request
- * @req: the request being processed
- * @uptodate: 1 for success, 0 for I/O error, 0 for specific error
- * @nr_sectors: number of sectors to end I/O on
- *
- * Description:
- * Ends I/O on a number of sectors attached to @req, and sets it up
- * for the next range of segments (if any) in the cluster.
- *
- * Return:
- * 0 - we are done with this request, call end_that_request_last()
- * 1 - still buffers pending for this request
- **/
-int end_that_request_first(struct request *req, int uptodate, int nr_sectors)
-{
- return __end_that_request_first(req, uptodate, nr_sectors 9);
-}
-
-EXPORT_SYMBOL(end_that_request_first);
-
-/**
- * end_that_request_chunk - end I/O on a request
- * @req: the request being processed
- * @uptodate: 1 for success, 0 for I/O error, 0 for specific error
- * @nr_bytes: number of bytes to complete
- *
- * Description:
- * Ends I/O on a number of bytes attached to @req, and sets it up
- * for the next range of segments (if any). Like end_that_request_first(),
- * but deals with bytes instead of sectors.
- *
- * Return:
- * 0 - we are done with this request, call end_that_request_last()
- * 1 - still buffers pending for this request
- **/
-int end_that_request_chunk(struct request *req, int uptodate, int nr_bytes)
-{
- return __end_that_request_first(req, uptodate, nr_bytes);
-}
-
-EXPORT_SYMBOL(end_that_request_chunk);
-
/*
* splice the completion data to a local structure and hand off to
* process_completion_queue() to complete the requests
@@ -3620,7 +3591,7 @@ EXPORT_SYMBOL(blk_complete_request);
/*
* queue lock must be held
*/
-void end_that_request_last(struct request *req, int uptodate)
+static void end_that_request_last(struct request *req, int uptodate)
{
struct gendisk *disk = req-rq_disk;
int error;
@@ -3655,8 +3626,6 @@ void end_that_request_last(struct reques
__blk_put_request(req-q, req);
}
-EXPORT_SYMBOL(end_that_request_last);
-
void end_request(struct request *req, int uptodate)
{
__blk_end_request(req, uptodate, sect2byte(req-hard_cur_sectors));
diff -rupN 05-ide-cd-change/include/linux/blkdev.h
06-remove-old-interface/include/linux/blkdev.h
--- 05-ide-cd-change/include/linux/blkdev.h 2007-08-24 12:21:45.0
-0400
+++ 06-remove-old-interface/include/linux/blkdev.h 2007-08-24
12:21:15.0 -0400
@@ -720,19 +720,16 @@ static inline void blk_run_address_space
}
/*
- * end_request() and friends. Must be called with the
Re: [PATCH 6/7] blk_end_request: remove/unexport end_that_request_*
On Tue, Sep 04 2007, Halevy, Benny wrote: Boaz raised my attention to this patchset today... We suspect we'll still need the extern entry points for handling the bidi request in the scsi_io_completion() path as we only want to call end_that_request_chunk on req-next_rq and never end_that_request_last. (see http://www.bhalevy.com/open-osd/download/linux-2.6.23-rc2_and_iscsi-iscsi-2007_08_09/0005-SCSI-bidi-support.patch) If this is ok with you I'd leave these entry points in place rather than taking them out and putting them back in later. There's no point in leaving them in when nothing current needs it, I'd much rather add it back in should the need arise. That's the proper way to handle things like this. -- Jens Axboe - 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 1/7] blk_end_request: add new request completion interface
Hi Jens,
Thank you for the comments.
On Mon, 3 Sep 2007 09:45:45 +0200, Jens Axboe [EMAIL PROTECTED] wrote:
+extern int blk_end_request(struct request *rq, int uptodate, int nr_bytes);
+extern int __blk_end_request(struct request *rq, int uptodate, int
nr_bytes);
extern int end_that_request_first(struct request *, int, int);
extern int end_that_request_chunk(struct request *, int, int);
extern void end_that_request_last(struct request *, int);
We get in to way too many levels of underscores here. Please changes
this to be blk_end_request() and blk_end_request_locked(), where the
former grabs the queue lock but the latter assumes it's held. Then have
the static __blk_end_request() where the lock MUST be held - do this in
the caller, don't pass it as an argument!
It makes perfect sense but I have a reason I couldn't do it.
The goal of our patch set is to change the role of rq-end_io()
so that the request submitter can set its own procedure of
request completion (please see the patch 7/7).
So if the caller must hold the lock, we have to hold the lock
during the whole rq-end_io(), that includes end_that_request_first().
It would cause performance regression by making the lock held longer.
OTOH, the 'needlock' argument allows the completion handler to hold
the lock during the minimum piece of the code.
If you have any idea to fix the situation, I would appreciate it.
Below is the detailed explanation of the above.
I took your comment as below.
-
static void __blk_end_request(rq, uptodate) {
blk_queue_end_tag();
blkdev_dequeue_request();
end_that_request_last(rq, uptodate);
}
int blk_end_request_locked(rq, uptodate, nr_bytes) {
if (end_that_request_first(rq, uptodate, nr_bytes))
return 1;
add_disk_randomness();
__blk_end_request(rq, uptodate);
return 0;
}
EXPORT_SYMBOL_GPL(blk_end_request_locked);
int blk_end_request(rq, uptodate, nr_bytes) {
if (end_that_request_first(rq, uptodate, nr_bytes))
return 1;
add_disk_randomness();
spin_lock_irqsave();
__blk_end_request(rq, uptodate);
spin_unlock_irqrestore();
return 0;
}
EXPORT_SYMBOL_GPL(blk_end_request);
-
It's quite reasonable on the patch 1/7.
But the goal of this patch-set is to allow to hook the whole request
completion procedures by a single rq-end_io() hook.
(Please see the patch 7/7 for details)
So the callee (funciton_to_be_set_in_rq_end_io() below) needs to know
whether it has the lock or not.
To prepare for the change of the patch 7/7 and avoid code duplication,
I chose passing the lock information as an argument.
-
static int function_to_be_set_in_rq_end_io(rq, uptodate, nr_bytes, needlock) {
if (end_that_request_first(rq, uptodate, nr_bytes))
return 1;
add_disk_randomness();
if (needlock)
spin_lock_irqsave();
__blk_end_request(rq, uptodate);
if (needlock)
spin_unlock_irqrestore();
return 0;
}
int blk_end_request_locked(rq, uptodate, nr_bytes) {
if (rq-end_io)
return rq-end_io(rq, uptodate, nr_bytes, 0);
if (end_that_request_first(rq, uptodate, nr_bytes))
}
int blk_end_request(rq, uptodate, nr_bytes) {
if (rq-end_io)
return rq-end_io(rq, uptodate, nr_bytes, 1);
if (end_that_request_first(rq, uptodate, nr_bytes))
}
-
Thanks,
Kiyoshi Ueda
-
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: MDADM restart at system boot time
Paul wrote: Hi, I hope someone can help. I have manually installed mdadm and now have a working array. I installed mdadm from the tarball, then did 'make install' My problem is after system reboot the array will not start as the daemon is not running, I guess. In order to access my files I have to re-create the array, which it complains about and then re-mount the disks, via the usual 'mount /dev/md0 /data', I know this 'mount' can be done via fstab, but I need the first part to work first. I have the following info in my mdadm.conf file: DEVICE /dev/hdb1 /dev/hdc1 ARRAY /dev/md0 level=raid1 num-devices=2 UUID=0f0e3d1f:52580ad4:2ef6a2e7:f760e130 devices=/dev/hdb1,/dev/hdc1 Apologies, I was slightly incorrect on the last part. Replace the DEVICE entry with: DEVICE partitions and add auto=part in place of the devices=/dev/hdb1,/dev/hdc1 section at the end of your ARRAY entry. Regards, Richard - 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 6/7] blk_end_request: remove/unexport end_that_request_*
Hi, On Tue, 4 Sep 2007 17:25:14 -0400, Halevy, Benny [EMAIL PROTECTED] wrote: We suspect we'll still need the extern entry points for handling the bidi request in the scsi_io_completion() path as we only want to call end_that_request_chunk on req-next_rq and never end_that_request_last. (see http://www.bhalevy.com/open-osd/download/linux-2.6.23-rc2_and_iscsi-iscsi-2007_08_09/0005-SCSI-bidi-support.patch) If this patch-set is merged, there may be other way to do that. For tricky drivers, special interface, blk_end_request_callback(), is added in the patch 5/7. (http://marc.info/?l=linux-kernelm=118860027714753w=2) Currently, only user of the interface is ide-cd (cdrom_newpc_intr()). It needs to call only end_that_request_first() too. With the patch 7/7, you can set your own handler in rq-end_io() to complete the request by your own way. Thanks, Kiyoshi Ueda - 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: pata_via cd/dvd timeout problems
Hi, I have both a dvd RW drive a cd rom drive connected the second ide interface on my motherboard with a via chipset, using pata_via I see timeout messages in the log after some time both drives lockup and are unable to mount any disks. I would suggest trying the following things: 1) Add both drives (_NEC DVD_RW ND-3520 and TSSTcorpDVD-ROM TS-H352A) to ata_device_blacklist in drivers/ata/libata-core.c using the ATA_HORKAGE_NODMA and ATA_HORKAGE_MAX_SEC_128 keywords and then recompile the kernel. 2) Move the CD and DVD RW drives to a computer with another chipset to determine whether they or the chipset are to blame. Vlad Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ - 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: pata_via cd/dvd timeout problems
Hi, - 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: pata_via cd/dvd timeout problems
(take 2) Hi, Quoting Vlad [EMAIL PROTECTED]: I have both a dvd RW drive a cd rom drive connected the second ide interface on my motherboard with a via chipset, using pata_via I see timeout messages in the log after some time both drives lockup and are unable to mount any disks. Just a me too. On 2.6.22 without via_pata I get the following and the DVD drive always seems to work: Aug 31 12:53:13 nelson kernel: hdd: LITE-ON DVD SOHD-167T, ATAPI CD/DVD-ROM drive Aug 31 12:53:13 nelson kernel: hdd: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33) Aug 31 15:05:22 nelson kernel: hdd: lost interrupt Aug 31 15:06:22 nelson kernel: hdd: lost interrupt With via_pata, I get the following, more info available if required: Sep 4 11:56:41 nelson kernel: scsi2 : pata_via Sep 4 11:56:41 nelson kernel: scsi3 : pata_via Sep 4 11:56:41 nelson kernel: ata3: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001dc00 irq 14 Sep 4 11:56:41 nelson kernel: ata4: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001dc08 irq 15 Sep 4 11:56:41 nelson kernel: ata4.01: ATAPI: LITE-ON DVD SOHD-167T, 9S1B, max UDMA/33 Sep 4 11:56:41 nelson kernel: ata4.01: configured for UDMA/33 Sep 4 11:56:41 nelson kernel: scsi 3:0:1:0: CD-ROMLITE-ON DVD SOHD-167T9S1B PQ: 0 ANSI: 5 Sep 4 12:50:47 nelson kernel: ata4.01: qc timeout (cmd 0xa0) Sep 4 12:50:47 nelson kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Sep 4 12:50:47 nelson kernel: ata4.01: cmd a0/00:00:00:00:20/00:00:00:00:00/b0 tag 0 cdb 0x0 data 0 Sep 4 12:50:47 nelson kernel: res 51/20:03:00:00:20/00:00:00:00:00/b0 Emask 0x5 (timeout) Sep 4 12:50:47 nelson kernel: ata4: soft resetting port Sep 4 12:50:47 nelson kernel: ata4.01: configured for UDMA/33 Sep 4 12:50:47 nelson kernel: ata4: EH complete Sep 4 12:51:17 nelson kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Sep 4 12:51:17 nelson kernel: ata4.01: cmd a0/00:00:00:00:20/00:00:00:00:00/b0 tag 0 cdb 0x0 data 0 Sep 4 12:51:17 nelson kernel: res 40/00:03:00:00:20/00:00:00:00:00/b0 Emask 0x4 (timeout) Sep 4 12:51:17 nelson kernel: ata4: soft resetting port Sep 4 12:51:18 nelson kernel: ata4.01: configured for UDMA/33 Sep 4 12:51:18 nelson kernel: ata4: EH complete Sep 4 12:51:48 nelson kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Sep 4 12:51:48 nelson kernel: ata4.01: cmd a0/00:00:00:00:20/00:00:00:00:00/b0 tag 0 cdb 0x0 data 0 Sep 4 12:51:48 nelson kernel: res 40/00:03:00:00:20/00:00:00:00:00/b0 Emask 0x4 (timeout) Sep 4 12:51:48 nelson kernel: ata4: soft resetting port Sep 4 12:51:49 nelson kernel: ata4.01: configured for UDMA/33 Sep 4 12:51:49 nelson kernel: ata4: EH complete Sep 4 12:52:19 nelson kernel: ata4.01: limiting speed to UDMA/25:PIO4 Sep 4 12:52:19 nelson kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Sep 4 12:52:19 nelson kernel: ata4.01: cmd a0/00:00:00:00:20/00:00:00:00:00/b0 tag 0 cdb 0x0 data 0 Sep 4 12:52:19 nelson kernel: res 40/00:03:00:00:20/00:00:00:00:00/b0 Emask 0x4 (timeout) Sep 4 12:52:19 nelson kernel: ata4: soft resetting port Sep 4 12:52:19 nelson kernel: ata4.01: configured for UDMA/25 Sep 4 12:52:19 nelson kernel: ata4: EH complete Sep 4 12:52:49 nelson kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Sep 4 12:52:49 nelson kernel: ata4.01: cmd a0/00:00:00:00:20/00:00:00:00:00/b0 tag 0 cdb 0x0 data 0 Sep 4 12:52:49 nelson kernel: res 40/00:03:00:00:20/00:00:00:00:00/b0 Emask 0x4 (timeout) Sep 4 12:52:49 nelson kernel: ata4: soft resetting port Sep 4 12:52:50 nelson kernel: ata4.01: configured for UDMA/25 Sep 4 12:52:50 nelson kernel: ata4: EH complete Sep 4 12:53:20 nelson kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Sep 4 12:53:20 nelson kernel: ata4.01: cmd a0/00:00:00:00:20/00:00:00:00:00/b0 tag 0 cdb 0x0 data 0 Sep 4 12:53:20 nelson kernel: res 40/00:03:00:00:20/00:00:00:00:00/b0 Emask 0x4 (timeout) Sep 4 12:53:20 nelson kernel: ata4: soft resetting port Sep 4 12:53:20 nelson kernel: ata4.01: configured for UDMA/25 Sep 4 12:53:20 nelson kernel: ata4: EH complete Sep 4 12:53:50 nelson kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Sep 4 12:53:50 nelson kernel: ata4.01: cmd a0/00:00:00:00:20/00:00:00:00:00/b0 tag 0 cdb 0x0 data 0 Sep 4 12:53:50 nelson kernel: res 40/00:03:00:00:20/00:00:00:00:00/b0 Emask 0x4 (timeout) Sep 4 12:53:50 nelson kernel: ata4: soft resetting port Sep 4 12:53:51 nelson kernel: ata4.01: configured for UDMA/25 Sep 4 12:53:51 nelson kernel: ata4: EH complete Sep 4 12:54:21 nelson kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Sep 4 12:54:21 nelson kernel: ata4.01: cmd a0/00:00:00:00:20/00:00:00:00:00/b0 tag 0
