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
[PATCH] pci-quirks: disable MSI on RS400-200 and RS480
MSI doesn't work on RS400-200 and RS480 requiring pci=nomsi kernel boot parameter for ahci to work. This patch disables MSI on those chips. http://thread.gmane.org/gmane.linux.ide/17820 http://thread.gmane.org/gmane.linux.ide/17516 https://bugzilla.novell.com/show_bug.cgi?id=263893 Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 65d6f23..3300ff1 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1761,6 +1761,8 @@ static void __devinit quirk_disable_msi(struct pci_dev *dev) } } DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8131_BRIDGE, quirk_disable_msi); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS400_200, quirk_disable_msi); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS480, quirk_disable_msi); /* Go through the list of Hypertransport capabilities and * return 1 if a HT MSI capability is found and enabled */ - 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: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert
Adrian Bunk wrote: [ Cc's added, additional information is in http://lkml.org/lkml/2007/4/15/32 ] On Sun, Apr 15, 2007 at 02:49:29PM +0400, Brad Campbell wrote: Brad Campbell wrote: G'day all, All I have is a digital photo of this oops. (It's 3.5mb). I have serial console configured, but Murphy is watching me carefully and I just can't seem to reproduce it while logging the console output. And as usual, after trying to capture one for 4 days, I get one 10 mins after I've sent the E-mail :) I think I've just found a way to make this easier to reproduce as /dev/sdd was not even mounted this time. I just cold booted and started an md5sum -c run on a directory of about 180GB. Is this also present with kernel 2.6.20 or is it a regression? Yes, I reproduced it with 2.6.20 but appear to be unable to do so with 2.6.19. -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams - 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 02:37:14AM +0200, Adrian Bunk wrote: > > Subject: kernels fail to boot with drives on ATIIXP controller > (ACPI/IRQ related) > References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 c http://lkml.org/lkml/2007/3/4/257 > Submitter : Michal Jaegermann <[EMAIL PROTECTED]> > Status : unknown Sigh! Again! AFAICT the current "rc" kernels should boot using 'pata_atiixp' driver _provided_ I will use 'acpi=off'. At least on the hardware in question. More details at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621#c10 OTOH I mentioned few times that another machine, which want to use 'pata_via' fails to read _anything_ from a disk. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234650 Mentioned there 2.6.20-1.3054.fc7 really corresponds to 2.6.21-rc6-git1 (AFAICT). Michal - 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
[1/2] 2.6.21-rc7: known regressions
This email lists some known regressions in Linus' tree compared to 2.6.20. 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: snd_hda_intel doesn't work with ASUS M2V mainboard References : http://bugzilla.kernel.org/show_bug.cgi?id=8273 Submitter : Hans-Georg Rist <[EMAIL PROTECTED]> Status : unknown Subject: snd_intel8x0: divide error: References : http://lkml.org/lkml/2007/3/5/252 Submitter : Michal Piotrowski <[EMAIL PROTECTED]> Status : unknown Subject: ali_pata: boot from CD fails References : http://lkml.org/lkml/2007/3/31/160 Submitter : Stephen Clark <[EMAIL PROTECTED]> Status : unknown Subject: kernels fail to boot with drives on ATIIXP controller (ACPI/IRQ related) References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 http://lkml.org/lkml/2007/3/4/257 Submitter : Michal Jaegermann <[EMAIL PROTECTED]> Status : unknown Subject: boot failure: rtl8139: exception in interrupt routine References : http://lkml.org/lkml/2007/3/31/160 Submitter : Stephen Clark <[EMAIL PROTECTED]> Status : unknown 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 Subject: forcedeth: interface hangs under load References : http://lkml.org/lkml/2007/4/3/39 http://www.spinics.net/lists/netdev/msg28981.html Submitter : Ingo Molnar <[EMAIL PROTECTED]> Handled-By : Ingo Molnar <[EMAIL PROTECTED]> Ayaz Abdulla <[EMAIL PROTECTED]> David Miller <[EMAIL PROTECTED]> Status : problem is being debugged Subject: hal daemon crashes after pulling a USB serial device References : http://www.opensubscriber.com/message/[EMAIL PROTECTED]/6369800.html Submitter : Andi Kleen <[EMAIL PROTECTED]> Handled-By : Oliver Neukum <[EMAIL PROTECTED]> Status : problem is being debugged Subject: Oops when changing USB DVB-T adapter References : http://lkml.org/lkml/2007/3/9/212 http://lkml.org/lkml/2007/4/5/154 Submitter : CIJOML <[EMAIL PROTECTED]> Handled-By : Markus Rechberger <[EMAIL PROTECTED]> Status : patches 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
Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert
[ Cc's added, additional information is in http://lkml.org/lkml/2007/4/15/32 ] On Sun, Apr 15, 2007 at 02:49:29PM +0400, Brad Campbell wrote: > Brad Campbell wrote: > >G'day all, > > > >All I have is a digital photo of this oops. (It's 3.5mb). I have serial > >console configured, but Murphy is watching me carefully and I just can't > >seem to reproduce it while logging the console output. > > > > And as usual, after trying to capture one for 4 days, I get one 10 mins > after I've sent the E-mail :) > > I think I've just found a way to make this easier to reproduce as /dev/sdd > was not even mounted this > time. I just cold booted and started an md5sum -c run on a directory of > about 180GB. Is this also present with kernel 2.6.20 or is it a regression? > [ 2566.192665] BUG: unable to handle kernel NULL pointer dereference at > virtual address 005c > [ 2566.218242] printing eip: > [ 2566.226362] c0203169 > [ 2566.232906] *pde = > [ 2566.241274] Oops: [#1] > [ 2566.249637] Modules linked in: > [ 2566.258832] CPU:0 > [ 2566.258833] EIP:0060:[]Not tainted VLI > [ 2566.258834] EFLAGS: 00010082 (2.6.21-rc6-git5 #1) > [ 2566.296146] EIP is at cfq_dispatch_insert+0x19/0x70 > [ 2566.310761] eax: f7a0eae0 ebx: f7a0cb28 ecx: e2f869e8 edx: > [ 2566.331076] esi: f79fea7c edi: f7d04ac0 ebp: esp: f6945de0 > [ 2566.351388] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > [ 2566.368843] Process md5sum (pid: 2875, ti=f6944000 task=f68f4ad0 > task.ti=f6944000) > [ 2566.390975] Stack: f79fea7c f7d04ac0 c02032d9 f6ae5ef0 > c0133411 1000 > [ 2566.416414]0008 0004 0b582fd4 f79fea7c f7d04ac0 > f79fea7c > [ 2566.441870]c0203519 f7a0cb28 f7a0cb28 f79e 0282 c01fb7a9 > c016ea4d > [ 2566.467326] Call Trace: > [ 2566.475236] [] __cfq_dispatch_requests+0x79/0x170 > [ 2566.492224] [] do_generic_mapping_read+0x281/0x470 > [ 2566.509473] [] cfq_dispatch_requests+0x69/0x90 > [ 2566.525681] [] elv_next_request+0x39/0x130 > [ 2566.540850] [] bio_endio+0x5d/0x90 > [ 2566.553942] [] scsi_request_fn+0x45/0x280 > [ 2566.568851] [] blk_run_queue+0x32/0x70 > [ 2566.582982] [] scsi_next_command+0x30/0x50 > [ 2566.598154] [] scsi_end_request+0x9b/0xc0 > [ 2566.613063] [] scsi_io_completion+0x81/0x330 > [ 2566.628751] [] scsi_delete_timer+0xb/0x20 > [ 2566.643661] [] ata_scsi_qc_complete+0x65/0xd0 > [ 2566.659613] [] sd_rw_intr+0x8b/0x220 > [ 2566.673222] [] ata_altstatus+0x1c/0x20 > [ 2566.687352] [] ata_hsm_move+0x14d/0x3f0 > [ 2566.701744] [] scsi_finish_command+0x40/0x60 > [ 2566.717434] [] scsi_softirq_done+0x6f/0xe0 > [ 2566.732604] [] sil_interrupt+0x81/0x90 > [ 2566.746733] [] blk_done_softirq+0x58/0x70 > [ 2566.761644] [] __do_softirq+0x6f/0x80 > [ 2566.775516] [] do_softirq+0x27/0x30 > [ 2566.788866] [] do_IRQ+0x3e/0x80 > [ 2566.801177] [] common_interrupt+0x23/0x28 > [ 2566.816090] === > [ 2566.826793] Code: 3e 05 f0 ff e9 47 ff ff ff 89 f6 8d bc 27 00 00 00 00 > 83 ec 10 89 1c 24 89 6c > 24 0c 89 74 24 04 89 7c 24 08 89 c3 89 d5 8b 40 0c <8b> 72 5c 8b 78 04 89 > d0 e8 4a fa ff ff 8b 45 14 > 89 ea 25 01 80 > [ 2566.886586] EIP: [] cfq_dispatch_insert+0x19/0x70 SS:ESP > 0068:f6945de0 > [ 2566.909179] Kernel panic - not syncing: Fatal exception in interrupt 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
Sata-MV, Intergated Sata Device Support
Hello,
I am curious as to whether there are plans to add support for integrated
sata devices. I personally want to add support for a 60x1C0 based
device (pci:id = 0x5182). I think adding support should be relatively
simple, except for a few issues outlined below.
In the original mvSata.c (ver3.4) that has 0x5182 support, the config
space is as such:
case MV_SATA_DEVICE_ID_5182:
pAdapter->numberOfChannels = MV_SATA_5182_PORT_NUM;
pAdapter->numberOfUnits = 1;
pAdapter->portsPerUnit = 2;
pAdapter->sataAdapterGeneration = MV_SATA_GEN_IIE;
/*The integrated sata core chip based on 60x1 C0*/
pAdapter->chipIs60X1C0 = MV_TRUE;
pAdapter->hostInterface = MV_HOST_IF_INTEGRATED;
pAdapter->mainMaskOffset = 0x20024; /*the iobaseaddress is
0x6*/
pAdapter->mainCauseOffset = 0x20020;
break;
I have not yet figured out how all these values are defined in sata-mv.c
(ver 0.8). Specifically, where do I define "numberOfChannels" which
should equal 2, and "numberOfUnits" which obviously equals 1?
I have a current config space (not completed) for sata-mv.c which is:
{ /* chip_5182 */
.sht= &mv_sht,
.flags = (MV_COMMON_FLAGS | MV_6XXX_FLAGS |
MV_FLAG_DUAL_HC),
.pio_mask = 0x1f, /* pio0-4 */
.udma_mask = 0x7f, /* udma0-6 */
.port_ops = &mv6_ops,
},
I believe according to the new structure in sata-mv.c,
HC_MAIN_IRQ_CAUSE_OFS should equal 0x20020 and HC_MAIN_IRQ_MASK_OFS
should equal 0x20024 for the 0x5182 device.
My final question is how to implement the MV_HOST_IF_INTEGRATED flag?
Is this already implemented and renamed in sata-mv.c? Or do I need to
also add the routines?
Thanks in advance.
Regards,
--
Jon Li <[EMAIL PROTECTED]>
Next Generation NAS Development Group
-
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
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? Jan -- - 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 0/4] bidi support: block layer bidirectional io.
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.
-
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 4/4] bidi support: bidirectional request
- Instantiate another request_io_part in struct request for bidi_read.
- Define & Implement new API for accessing bidi parts.
- API to Build bidi requests and map to sglists.
- Define new end_that_request_block() function to end a complete request.
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
Signed-off-by: Benny Halevy <[EMAIL PROTECTED]>
---
block/elevator.c|7 +--
block/ll_rw_blk.c | 120 ---
drivers/scsi/scsi_lib.c |2 +-
include/linux/blkdev.h | 56 +-
4 files changed, 160 insertions(+), 25 deletions(-)
diff --git a/block/elevator.c b/block/elevator.c
index 237f15c..e39ef57 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -757,14 +757,9 @@ struct request *elv_next_request(request_queue_t *q)
rq = NULL;
break;
} else if (ret == BLKPREP_KILL) {
-int nr_bytes = rq_uni(rq)->hard_nr_sectors << 9;
-
-if (!nr_bytes)
-nr_bytes = rq_uni(rq)->data_len;
-
blkdev_dequeue_request(rq);
rq->cmd_flags |= REQ_QUIET;
-end_that_request_chunk(rq, 0, nr_bytes);
+end_that_request_block(rq, 0);
end_that_request_last(rq, 0);
} else {
printk(KERN_ERR "%s: bad return=%d\n", __FUNCTION__,
diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index c8ed8a9..21fdbc2 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -261,6 +261,7 @@ static void rq_init(request_queue_t *q, struct request *rq)
rq->end_io_data = NULL;
rq->completion_data = NULL;
rq_init_io_part(&rq->uni);
+rq_init_io_part(&rq->bidi_read);
}
/**
@@ -1312,14 +1313,16 @@ static int blk_hw_contig_segment(request_queue_t *q,
struct bio *bio,
}
/*
- * map a request to scatterlist, return number of sg entries setup. Caller
- * must make sure sg can hold rq->nr_phys_segments entries
+ * map a request_io_part to scatterlist, return number of sg entries setup.
+ * Caller must make sure sg can hold rq_io(rq, dir)->nr_phys_segments entries
*/
-int blk_rq_map_sg(request_queue_t *q, struct request *rq, struct scatterlist
*sg)
+int blk_rq_map_sg_bidi(request_queue_t *q, struct request *rq,
+struct scatterlist *sg, enum dma_data_direction dir)
{
struct bio_vec *bvec, *bvprv;
struct bio *bio;
int nsegs, i, cluster;
+struct request_io_part* req_io = rq_io(rq, dir);
nsegs = 0;
cluster = q->queue_flags & (1 << QUEUE_FLAG_CLUSTER);
@@ -1328,7 +1331,7 @@ int blk_rq_map_sg(request_queue_t *q, struct request *rq,
struct scatterlist *sg
* for each bio in rq
*/
bvprv = NULL;
-rq_for_each_bio(bio, rq) {
+for (bio = req_io->bio; bio; bio = bio->bi_next) {
/*
* for each segment in bio
*/
@@ -1360,7 +1363,17 @@ new_segment:
return nsegs;
}
+EXPORT_SYMBOL(blk_rq_map_sg_bidi);
+/*
+ * map a request to scatterlist, return number of sg entries setup. Caller
+ * must make sure sg can hold rq->nr_phys_segments entries
+ */
+int blk_rq_map_sg(request_queue_t *q, struct request *rq,
+ struct scatterlist *sg)
+{
+return blk_rq_map_sg_bidi(q, rq, sg, rq->data_dir);
+}
EXPORT_SYMBOL(blk_rq_map_sg);
/*
@@ -1415,11 +1428,12 @@ static inline int ll_new_hw_segment(request_queue_t *q,
return 1;
}
-int ll_back_merge_fn(request_queue_t *q, struct request *req, struct bio *bio)
+int ll_back_merge_fn(request_queue_t *q, struct request *req, struct bio *bio,
+enum dma_data_direction dir)
{
unsigned short max_sectors;
int len;
-struct request_io_part* req_io = rq_uni(req);
+struct request_io_part* req_io = rq_io(req, dir);
if (unlikely(blk_pc_request(req)))
max_sectors = q->max_hw_sectors;
@@ -2404,7 +2418,7 @@ static int __blk_rq_map_user(request_queue_t *q, struct
request *rq,
req_io = rq_uni(rq);
if (!req_io->bio)
blk_rq_bio_prep(q, rq, bio);
-else if (!ll_back_merge_fn(q, rq, bio)) {
+else if (!ll_back_merge_fn(q, rq, bio, rq->data_dir)) {
ret = -EINVAL;
goto unmap_bio;
} else {
@@ -2574,15 +2588,18 @@ int blk_rq_unmap_user(struct bio *bio)
EXPORT_SYMBOL(blk_rq_unmap_user);
/**
- * blk_rq_map_kern - map kernel data to a request, for REQ_BLOCK_PC usage
+ * blk_rq_map_kern_bidi - maps kernel data to a request_io_part, for BIDI usage
* @q:request queue where request should be inserted
* @rq:request to fill
* @kbuf:the kernel buffer
* @len:length of user data
* @gfp_mask:memory allocation flags
+ * @dir:if it is a BIDIRECTIONAL request than DMA_TO_DEVICE to prepare
+ * the bidi_write side or DMA_FROM_DEVICE to prepare the bidi_read
+ * side, else it should be same as req->data_dir
*/
-int blk_rq_map_kern(request_queue_t *q, struct request *rq, void *kbuf,
-unsigned int len, gfp_t gfp_mask)
+int blk_rq_map_kern_bidi(request_qu
[PATCH 3/4] bidi support: request_io_part
- Extract all I/O members of struct request into a request_io_part member. - Define API to access the I/O part - Adjust block layer accordingly. - Change all users to new API. Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]> Signed-off-by: Benny Halevy <[EMAIL PROTECTED]> --- Patch is attached compressed because of size 0003-bidi-support-request_io_part.patch.bz2 Description: BZip2 compressed data
[PATCH 2/4] bidi support: fix req->cmd == INT cases
- we have unearthed very old bugs in stale drivers that still
used request->cmd as a READ|WRITE int
- these drivers should probably go away...
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
Signed-off-by: Benny Halevy <[EMAIL PROTECTED]>
---
drivers/acorn/block/fd1772.c |2 +-
drivers/acorn/block/mfmhd.c |8
drivers/block/amiflop.c |2 +-
drivers/block/nbd.c |2 +-
drivers/cdrom/aztcd.c|2 +-
drivers/cdrom/cm206.c|2 +-
drivers/cdrom/gscd.c |2 +-
drivers/cdrom/mcdx.c |2 +-
drivers/cdrom/optcd.c|2 +-
drivers/cdrom/sjcd.c |2 +-
drivers/ide/legacy/hd.c |4 ++--
11 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/acorn/block/fd1772.c b/drivers/acorn/block/fd1772.c
index 674bf81..1717679 100644
--- a/drivers/acorn/block/fd1772.c
+++ b/drivers/acorn/block/fd1772.c
@@ -1246,7 +1246,7 @@ repeat:
del_timer(&motor_off_timer);
ReqCnt = 0;
-ReqCmd = CURRENT->cmd;
+ReqCmd = rq_uni_rw_dir(CURRENT);
ReqBlock = CURRENT->sector;
ReqBuffer = CURRENT->buffer;
setup_req_params(drive);
diff --git a/drivers/acorn/block/mfmhd.c b/drivers/acorn/block/mfmhd.c
index 689a4c3..50001eb 100644
--- a/drivers/acorn/block/mfmhd.c
+++ b/drivers/acorn/block/mfmhd.c
@@ -439,7 +439,7 @@ static void mfm_rw_intr(void)
a choice of command end or some data which is ready to be collected */
/* I think we have to transfer data while the interrupt line is on and its
not any other type of interrupt */
-if (CURRENT->cmd == WRITE) {
+if (rq_uni_rw_dir(CURRENT) == WRITE) {
extern void hdc63463_writedma(void);
if ((hdc63463_dataleft <= 0) && (!(mfm_status & STAT_CED))) {
printk("mfm_rw_intr: Apparent DMA write request when no more to
DMA\n");
@@ -799,7 +799,7 @@ static void issue_request(unsigned int block, unsigned int
nsect,
raw_cmd.head = start_head;
raw_cmd.cylinder = track / p->heads;
raw_cmd.cmdtype = CURRENT->cmd;
-raw_cmd.cmdcode = CURRENT->cmd == WRITE ? CMD_WD : CMD_RD;
+raw_cmd.cmdcode = rq_uni_rw_dir(CURRENT) == WRITE ? CMD_WD : CMD_RD;
raw_cmd.cmddata[0] = dev + 1;/* DAG: +1 to get US */
raw_cmd.cmddata[1] = raw_cmd.head;
raw_cmd.cmddata[2] = raw_cmd.cylinder >> 8;
@@ -830,7 +830,7 @@ static void issue_request(unsigned int block, unsigned int
nsect,
hdc63463_dataleft = nsect * 256;/* Better way? */
DBG("mfm%c: %sing: CHS=%d/%d/%d, sectors=%d, buffer=0x%08lx (%p)\n",
- raw_cmd.dev + 'a', (CURRENT->cmd == READ) ? "read" : "writ",
+ raw_cmd.dev + 'a', dma_dir_to_string(rq_dma_dir(CURRENT)),
raw_cmd.cylinder,
raw_cmd.head,
raw_cmd.sector, nsect, (unsigned long) Copy_buffer, CURRENT);
@@ -917,7 +917,7 @@ static void mfm_request(void)
DBG("mfm_request: block after offset=%d\n", block);
-if (CURRENT->cmd != READ && CURRENT->cmd != WRITE) {
+if (!dma_uni_dir(rq_dma_dir(CURRENT))) {
printk("unknown mfm-command %d\n", CURRENT->cmd);
end_request(CURRENT, 0);
Busy = 0;
diff --git a/drivers/block/amiflop.c b/drivers/block/amiflop.c
index 54f2fb3..fa0da1f 100644
--- a/drivers/block/amiflop.c
+++ b/drivers/block/amiflop.c
@@ -1363,7 +1363,7 @@ static void redo_fd_request(void)
#ifdef DEBUG
printk("fd: sector %ld + %d requested for %s\n",
CURRENT->sector,cnt,
- (CURRENT->cmd==READ)?"read":"write");
+ (rq_uni_rw_dir(CURRENT) == READ) ? "read" : "write");
#endif
block = CURRENT->sector + cnt;
if ((int)block > floppy->blocks) {
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 411e138..fc5e1b2 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -411,7 +411,7 @@ static void nbd_clear_que(struct nbd_device *lo)
/*
* We always wait for result of write, for now. It would be nice to make it
optional
* in future
- * if ((req->cmd == WRITE) && (lo->flags & NBD_WRITE_NOCHK))
+ * if ((rq_uni_rw_dir(req) == WRITE) && (lo->flags & NBD_WRITE_NOCHK))
* { printk( "Warning: Ignoring result!\n"); nbd_end_request( req ); }
*/
diff --git a/drivers/cdrom/aztcd.c b/drivers/cdrom/aztcd.c
index 1f9fb7a..8ccae77 100644
--- a/drivers/cdrom/aztcd.c
+++ b/drivers/cdrom/aztcd.c
@@ -229,7 +229,7 @@ static struct request_queue *azt_queue;
static int current_valid(void)
{
return CURRENT &&
-CURRENT->cmd == READ &&
+rq_rw_dir(CURRENT) == READ &&
CURRENT->sector != -1;
}
diff --git a/drivers/cdrom/cm206.c b/drivers/cdrom/cm206.c
index 2301311..1bdf0b7 100644
--- a/drivers/cdrom/cm206.c
+++ b/drivers/cdrom/cm206.c
@@ -851,7 +851,7 @@ static void do_cm206_request(request_queue_t * q)
if (!req)
return;
-if (req->cmd != READ) {
+if (rq_rw_dir(req) != READ) {
debug(("Non-read comma
Re: Loud "pop" coming from hard drive on reboot
I can confirm this, I have a Seagate Momentus 5400.3 sata disk, and it spins off, respin up and again off when I halt my notebook. I had before this disk an IBM/Hitachi one, and it doesn't have this behaviour. Take a look at this bug report: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/67810 There are some references and some patches against 2.6.20 kernel. This bug is confirmed there. Bye 2007/4/11, Chuck Ebbert <[EMAIL PROTECTED]>: Jan Engelhardt wrote: > On Apr 11 2007 17:07, Chuck Ebbert wrote: >> When I reboot my notebook, it powers off and powers back on. >> On poweroff a loud snapping noise seems to be coming from the >> hard drive. Today I noticed there is no "shutdown: hda" on >> the console when I reboot. Whne I do a normal poweroff the >> message is displayed and there is no noise. Should the IDE >> code be changed so it always shuts down the drive? > > What sort of notebook? What sort of harddisk? Compaq Presario V2000 series, with a new Seagate ST9120821A 120GB 5400RPM drive. > Is it as loud as `hdparm -y /dev/hdX"? That makes no noise at all except normal drive seek noises. > Try `smartctl -d ata -a /dev/hdX | grep -i unload` too. Hmm. Power_Cycle_Count ... 108 Power-Off_Retract_Count ... 90 I did a normal poweroff and the retract count went to 91. There is an almost-unnoticeable click when I do it that way. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - 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
On Sat, 14 Apr 2007, Pavel Machek wrote: > How common are notebooks that cut power to disks during reboot? Not common at all. Given that it wears the electronics a lot, it must be either a defect (of the kinds Brazilian law forces the manufacturer to either fix or give you your money back). 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. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - 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
Fwd: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen on SATA hd
Hi, 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? Some extra info on my system: kernel: Linux version 2.6.20.7 ([EMAIL PROTECTED]) (gcc version 4.1.1 (Gentoo 4.1.1-r3)) #1 Sun Apr 15 10:23:37 BRT 2007 lspci: 01:07.0 Mass storage controller: ALi Corporation ALi M5281 Serial ATA / RAID Host Controller (rev a1) 01:07.1 Mass storage controller: ALi Corporation M5228 ALi ATA/RAID Controller (rev c6) dmesg: sata_uli :01:07.0: version 1.0 ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19 ACPI: PCI Interrupt :01:07.0[A] -> Link [APC4] -> GSI 19 (level, high) -> IRQ 16 ata1: SATA max UDMA/133 cmd 0x9000 ctl 0x9402 bmdma 0xA000 irq 16 ata2: SATA max UDMA/133 cmd 0x9800 ctl 0x9C02 bmdma 0xA008 irq 16 scsi0 : sata_uli ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32) ata1.00: configured for UDMA/133 scsi1 : sata_uli ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: ATA-7, max UDMA/133, 586114704 sectors: LBA48 NCQ (depth 0/32) ata2.00: ata2: dev 0 multi count 0 ata2.00: configured for UDMA/133 scsi 0:0:0:0: Direct-Access ATA ST3250820AS 3.AA PQ: 0 ANSI: 5 SCSI device sda: 488397168 512-byte hdwr sectors (250059 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 SCSI device sda: 488397168 512-byte hdwr sectors (250059 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 sda: sda1 sd 0:0:0:0: Attached scsi disk sda scsi 1:0:0:0: Direct-Access ATA Maxtor 6L300S0 BACE PQ: 0 ANSI: 5 SCSI device sdb: 586114704 512-byte hdwr sectors (300091 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdb: 586114704 512-byte hdwr sectors (300091 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sd 1:0:0:0: Attached scsi disk sdb Please let me know if there is any extra info or tests necessary. 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: Loud "pop" coming from hard drive on reboot
Hi! > When I reboot my notebook, it powers off and powers back on. > On poweroff a loud snapping noise seems to be coming from the > hard drive. Today I noticed there is no "shutdown: hda" on > the console when I reboot. Whne I do a normal poweroff the > message is displayed and there is no noise. Should the IDE > code be changed so it always shuts down the drive? Well... most machines have reboot handling where they do not cut power to disk drive. That means that shutting down their hdds would unneccessarily wear their drives. ...while we unneccessarily wear *your* drive :-(. How common are notebooks that cut power to disks during reboot? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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
