Re: [PATCH 0/7] sg_ring: a ring of scatterlist arrays

2008-01-06 Thread Tejun Heo 
Rusty Russell wrote:
> On Monday 07 January 2008 16:01:40 Tejun Heo wrote:
>>> But we hit the same problems:
>>>
>>> 1) sg_chain loses information.  The clever chain packaging makes reading
>>> easy, but manipulation is severely limited.  You can append to your own
>>> chains by padding, but not someone elses.  This works for SCSI, but what
>>> about the rest of us?  And don't even think of joining mapped chains: it
>>> will almost work.
>> You can append by allocating one more element on the chain to be
>> appended and moving the last element of the first chain to it while
>> using the last element for chaining.
> 
> Hi Tejun,
> 
>Nice try!  Even ignoring the ugliness of undoing such an operation if the 
> caller doesn't expect you to mangle their chains, consider a one-element sg 
> array. :(

Heh heh, that can be dealt with by skipping the first chain if the first
chain is empty after chaining.  Please take a look at
ata_sg_setup_extra() in the following.

http://git.kernel.org/?p=linux/kernel/git/tj/libata-dev.git;a=blob;f=drivers/ata/libata-core.c;h=32dde5bbc75ed53e89ac17040da2cd0621a37161;hb=c8847e473a4a2844244784226eb362be10d52ce9

That said, yeah, it's seriously ugly.  Restoring the original sg is ugly
too.  I definitely agree that we need some improvements here.

-- 
tejun
-
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 0/7] sg_ring: a ring of scatterlist arrays

2008-01-06 Thread Rusty Russell 
On Monday 07 January 2008 16:01:40 Tejun Heo wrote:
> > But we hit the same problems:
> >
> > 1) sg_chain loses information.  The clever chain packaging makes reading
> > easy, but manipulation is severely limited.  You can append to your own
> > chains by padding, but not someone elses.  This works for SCSI, but what
> > about the rest of us?  And don't even think of joining mapped chains: it
> > will almost work.
>
> You can append by allocating one more element on the chain to be
> appended and moving the last element of the first chain to it while
> using the last element for chaining.

Hi Tejun,

   Nice try!  Even ignoring the ugliness of undoing such an operation if the 
caller doesn't expect you to mangle their chains, consider a one-element sg 
array. :(

Cheers,
Rusty.
-
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 0/7] sg_ring: a ring of scatterlist arrays

2008-01-06 Thread Tejun Heo 
Hello,

Rusty Russell wrote:
>> The other thing I note is that the problem you're claiming to solve with
>> sg_ring (the ability to add extra scatterlists to the front or the back
>> of an existing one) is already solved with sg_chain, so the only real
>> advantage of sg_ring was that it contains explicit counts, which
>> sg_table (in -mm) also introduces.
> 
> I just converted virtio using latest Linus for fair comparison, and it's 
> still 
> pretty ugly.  sg_ring needs more work to de-scsi it.  sg_table is almost 
> sg_ring except it retains all the chaining warts.

I agree it's ugly.

> But we hit the same problems:
> 
> 1) sg_chain loses information.  The clever chain packaging makes reading 
> easy, 
> but manipulation is severely limited.  You can append to your own chains by 
> padding, but not someone elses.  This works for SCSI, but what about the rest 
> of us?  And don't even think of joining mapped chains: it will almost work.

You can append by allocating one more element on the chain to be
appended and moving the last element of the first chain to it while
using the last element for chaining.  Join can be done by similar
technique using three element extra chain in the middle.  But, yeah,
it's ugly as hell.

-- 
tejun
-
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 0/7] sg_ring: a ring of scatterlist arrays

2008-01-06 Thread Rusty Russell 
On Sunday 06 January 2008 02:31:12 James Bottomley wrote:
> On Wed, 2007-12-19 at 17:31 +1100, Rusty Russell wrote:
> > This patch series is the start of my attempt to simplify and make
> > explicit the chained scatterlist logic.
> >
> > It's not complete: my SATA box boots and seems happy, but all the other
> > users of SCSI need to be updated and checked.  But I've gotten far enough
> > to believe it's worth persuing.
>
> Sorry for the delay in looking at this, I was busy with Holidays and
> things.

Thankyou for your consideration.

> When I compare sg_ring with the current sg_chain (and later sg_table)
> implementations, I'm actually struck by how similar they are.

I agree, they're solving the same problem.  It is possible that the pain of 
change is no longer worthwhile, but I hate to see us give up on this.  We're 
adding complexity without making it harder to misuse.

> The other thing I note is that the problem you're claiming to solve with
> sg_ring (the ability to add extra scatterlists to the front or the back
> of an existing one) is already solved with sg_chain, so the only real
> advantage of sg_ring was that it contains explicit counts, which
> sg_table (in -mm) also introduces.

I just converted virtio using latest Linus for fair comparison, and it's still 
pretty ugly.  sg_ring needs more work to de-scsi it.  sg_table is almost 
sg_ring except it retains all the chaining warts.

But we hit the same problems:

1) sg_chain loses information.  The clever chain packaging makes reading easy, 
but manipulation is severely limited.  You can append to your own chains by 
padding, but not someone elses.  This works for SCSI, but what about the rest 
of us?  And don't even think of joining mapped chains: it will almost work.

2) sg_chain's end marker is only for reading non-dma elements, not for mapped 
chains, nor for writing into chains.  Plus it's a duplicate of the num arg, 
which is still passed around for efficiency.  (virtio had to implement 
count_sg() because I didn't want those two redundant num args).

3) By overloading struct scatterlist, it's invisible what code has been 
converted to chains, and which hasn't.  Too clever by half!

Look at sg_chain(): it claims to join two scatterlists, but it doesn't.  It 
assumes that prv is an array, not a chain.  Because you've overloaded an 
existing type, this happens everywhere.  Try passing skb_to_sgvec a chained 
skb.

sg_ring would not have required any change to existing drivers, just those 
that want to use long sg lists.  And then it's damn obvious which are which.

4) sg_chain missed a chance to combine all the relevent information (max, num, 
num_dma and the sg array). sg_table comes close, but you still can't join 
them (no max information, and even if there were, what if it's full?).  
Unlike sg_ring, it's unlikely to reduce bugs.

5) (A little moot now) sg_ring didn't require arch changes.

> The other differences are that sg_ring only allows adding at the front
> or back of an existing sg_ring, it doesn't allow splicing at any point
> like sg_chain does, so I'd say it's less functional (not that I actually
> want anyone ever to do this, of course ...)

Well it's just as possible, but you might have to copy more elements (with sg 
chaining you need only copy 1 sg element to make room for the chain elem).  
Agreed that it's a little out there...

> The final point is that sg_ring requires a two level traversal:  ring
> list then scatterlist, whereas sg_chain only requires a single level
> traversal.  I grant that we can abstract out the traversal into
> something that would make users think they're only doing a single level,
> but I don't see what the extra level really buys us.

We hide the real complexity from users and it makes it less safe for 
non-trivial cases.

Hence the introduction of YA datastructure: sg_table.  This is getting close: 
just hang the array off it and you'll have sg_ring and no requirement for 
dynamic alloc all the time.  And once you have a header, no need for chaining 
tricks...

> The only thing missing from sg_chain perhaps is an accessor function
> that does the splicing, which I can easily construct if you want to try
> it out in virtio.

I don't need that (I prepend and append), but it'd be nice if sg_next took a 
const struct scatterlist *.

Cheers,
Rusty.
-
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: Believed resolved: SATA kern-buffRd read slow: based on promise driver bug

2008-01-06 Thread Robert Hancock 

Linda Walsh wrote:

Mikael Pettersson wrote:

Linda Walsh writes:
 > Mikael Pettersson wrote:
 > > Linda Walsh writes:
 > >  > > Linda Walsh wrote:
 > >  >  read rate began falling; (.25 - .3);  > >  > more 
importantly; a chronic error message associated

 > >  > with drive may be causing some or all of the problem(s):
 > >  > ---
 > >  > ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
 > >  > ata1.00: port_status 0x2008
 > >  > ata1.00: cmd c8/00:10:30:06:03/00:00:00:00:00/e0 tag 0 cdb 0x0 
data 8192 in
 > >  >  res 50/00:00:3f:06:03/00:00:00:00:00/e0 Emask 0x2 
(HSM violation)

 > >  > ata1: limiting SATA link speed to 1.5 Gbps
 > >
 > > Looks like the Promise ASIC SG bug. Apply
 > > 
 


 > > and let us know if things improve.
 > > /Mikael
 > ---
 > Yep!  Hope that's making it into a patch soon or, at least 2.6.24.
 > Kernel buffered
Good to hear that it solved this problem.
The patch is in 2.6.24-rc2 and newer kernels, and will be sent
to -stable for the 2.6.23 and 2.6.22 series.
  

---
   Will 'likely' wait till -stable since I use the machine as a 'server'
for just about any/everything that needs "serving" or "proxy" services.
 >  That and I'd like to find out why TCQ/NCQ doesn't work with the 
Seagate drives --


The driver doesn't yet support NCQ.


   Is 'main' diff between NCQ/TCQ that TCQ can re-arrange 'write'
priority under driver control, whereas NCQ is mostly a FIFO queue?


First off one has to distinguish between ATA TCQ and SCSI TCQ. ATA TCQ 
is essentially abandoned, very few drives and fewer still controllers 
and matching drivers ever supported it.


SCSI TCQ has "head of queue", "ordered" and "simple" queueing modes. ATA 
NCQ effectively only has "simple" where the drive always decides what 
order to service the requests in. There is a FUA mode, which tells the 
drive that the command (normally a write) has to access the physical 
media before reporting completion.




   On a Journal'ed file system, isn't "write-order" control required
for integrity?  That would seem to imply TCQ could be used, but
NCQ doesn't seem to offer much benefit, since the higher level
kernel drivers usually have a "larger picture" of sectors that need
to be written.  The only advantage I can see for NCQ drives might


There are cases where writes need to complete in a specific order. This 
can be done either by using FUA bits (though libata doesn't do this by 
default currently) or by issuing cache flushes before and after certain 
commands.



be that the kernel may not know the drive's internal physical
structure nor where the disk is in its current revolution.  That could
allow drive write re-ordering where based on the exact-current state
of the drive that the kernel might not have access to, but it seems
this would be a minor benefit -- and, depending on firmware,
possibly higher overhead in command processing?


That's a big part of it. The kernel doesn't necessarily know what 
sectors will be the fastest to access at any given time whereas the 
drive can.


Also, NCQ has some other improvements that are independent of actually 
queueing commands - for instance, because the drive controls the DMA 
data transfer, it can transfer the data for one request in an 
out-of-order fashion instead of having to transfer to the host strictly 
from beginning to end as in traditional ATA.




Am trying to differentiate NCQ/TCQ and SAS v. SCSI benefits.
It seems both support (SAS & SATA) some type of port-multiplier/
multiplexor/ option to allow more disks/port.

However, (please correct?) SATA uses a hub type architecture while
SAS uses a switch architecture.  My experience with network hubs vs.
switches is that network hubs can be much slower if there is
communication contention.  Is the word 'hub' being used in the
"shared-communication media sense", or is someone using the term
'hub' as a [sic] replacement for a 'switch'?


I believe that they're essentially the same in that regard, though 
someone can correct me if I'm wrong..


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.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: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

2008-01-06 Thread Alan Cox 
On Sun, 06 Jan 2008 12:25:10 -0800
Linda Walsh <[EMAIL PROTECTED]> wrote:

> Robert Hancock wrote:
> >
> > If this is a Seagate, I believe that they don't have AAM enabled on 
> > any of their newer drives (something about a lawsuit for patent 
> > infringement on that feature, or something). Quite likely they don't 
> > support that power management command, either.
> --
> Do you have a source for this -- haven't heard of such a conflict -- 

There were patent questions around AAM. There are some discussions on the
t13 archive then it goes silent and nothing is ever said again, which I
imagine is when it got lawyered.

> besides, doesn't
> ATA-7 require some of those functions? 

No.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

2008-01-06 Thread Mehmet Kemal EROL 
Linda Walsh:

> 
> Seagate would
> remove those features -- especially since they are mentioned on 
> Seagate's drive
> information page as being supported features.
> 

Since you're there ... you might want to download `Seagate's SeaTools'
and (if) give the hdd's controller a try ... ;)

-- 
Esenlikle   <~>   Mehmet Kemal

_/_/  IBM Pollyanna Principle:
_/Machines should work,
_/People should think...

-
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 kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

2008-01-06 Thread Linda Walsh 

Robert Hancock wrote:


If this is a Seagate, I believe that they don't have AAM enabled on 
any of their newer drives (something about a lawsuit for patent 
infringement on that feature, or something). Quite likely they don't 
support that power management command, either.

--
   Do you have a source for this -- haven't heard of such a conflict -- 
besides, doesn't
ATA-7 require some of those functions?  Given the trend toward 
power-saving and
quieter (also usually less vibration)  hard disks, I strongly disbelieve 
Seagate would
remove those features -- especially since they are mentioned on 
Seagate's drive

information page as being supported features.



-
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: Believed resolved: SATA kern-buffRd read slow: based on promise driver bug

2008-01-06 Thread Linda Walsh 

Mikael Pettersson wrote:

Linda Walsh writes:
 > Mikael Pettersson wrote:
 > > Linda Walsh writes:
 > >  > > Linda Walsh wrote:
 > >  >  read rate began falling; (.25 - .3); 
 > >  > more importantly; a chronic error message associated

 > >  > with drive may be causing some or all of the problem(s):
 > >  > ---
 > >  > ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
 > >  > ata1.00: port_status 0x2008
 > >  > ata1.00: cmd c8/00:10:30:06:03/00:00:00:00:00/e0 tag 0 cdb 0x0 data 
8192 in
 > >  >  res 50/00:00:3f:06:03/00:00:00:00:00/e0 Emask 0x2 (HSM 
violation)
 > >  > ata1: limiting SATA link speed to 1.5 Gbps
 > >
 > > Looks like the Promise ASIC SG bug. Apply
 > > 

 > > and let us know if things improve.
 > > /Mikael
 > ---
 > Yep!  Hope that's making it into a patch soon or, at least 2.6.24.
 > Kernel buffered
Good to hear that it solved this problem.
The patch is in 2.6.24-rc2 and newer kernels, and will be sent
to -stable for the 2.6.23 and 2.6.22 series.
  

---
   Will 'likely' wait till -stable since I use the machine as a 'server'
for just about any/everything that needs "serving" or "proxy" services.

 >  That and I'd like to find out why TCQ/NCQ doesn't work with the Seagate 
drives --

The driver doesn't yet support NCQ.


   Is 'main' diff between NCQ/TCQ that TCQ can re-arrange 'write'
priority under driver control, whereas NCQ is mostly a FIFO queue?

   On a Journal'ed file system, isn't "write-order" control required
for integrity?  That would seem to imply TCQ could be used, but
NCQ doesn't seem to offer much benefit, since the higher level
kernel drivers usually have a "larger picture" of sectors that need
to be written.  The only advantage I can see for NCQ drives might
be that the kernel may not know the drive's internal physical
structure nor where the disk is in its current revolution.  That could
allow drive write re-ordering where based on the exact-current state
of the drive that the kernel might not have access to, but it seems
this would be a minor benefit -- and, depending on firmware,
possibly higher overhead in command processing?

Am trying to differentiate NCQ/TCQ and SAS v. SCSI benefits.
It seems both support (SAS & SATA) some type of port-multiplier/
multiplexor/ option to allow more disks/port.

However, (please correct?) SATA uses a hub type architecture while
SAS uses a switch architecture.  My experience with network hubs vs.
switches is that network hubs can be much slower if there is
communication contention.  Is the word 'hub' being used in the
"shared-communication media sense", or is someone using the term
'hub' as a [sic] replacement for a 'switch'?




-
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: 80 wire cable detection patch

2008-01-06 Thread George Kibardin 

Signed-off-by: George Kibardin <[EMAIL PROTECTED]>

--- drivers/ide/ide-iops.c.orig 2008-01-03 18:35:23.0 +0300
+++ drivers/ide/ide-iops.c  2008-01-03 18:12:29.0 +0300
@@ -612,12 +612,12 @@
  printk(KERN_DEBUG "%s: skipping word 93 validity check\n",
drive->name);

-   if (hwif->cbl != ATA_CBL_PATA80 && !ivb)
-   goto no_80w;
-
  if (ide_dev_is_sata(id) && !ivb)
  return 1;

+   if (hwif->cbl != ATA_CBL_PATA80 && !ivb)
+   goto no_80w;
+
  /*
   * FIXME:
   * - change master/slave IDENTIFY order

Best,
George



Hi,

On Thursday 03 January 2008, George Kibardin wrote:
  

Hi Bartlomiej,

I hope that you are the right person to look at my proposal.
I use 2.6.23-gentoo-r3 kernel on VIA Epia EX motherboard with WD SATA 
HDD connected to it. (I don't understand exactly why, but kernel thinks 
that this is not SATA HDD. It assigns name hda to it, there is no words 
SATA in logs, loading via_sata modules doesn't change situation, 
via82cxxx module detect this chipset correctly, there is no word SATA in 
BIOS etc.). During boot I get:



There is probably PATA->SATA bridge on the motherboard.

  

host side 80-wire cable detection failed, limiting max speed to UDMA33

(of course it is true - I don't have even 40 wires :-)
Digging the code I've figured out that for some reason checking that 
there is 80 wire cable connected happens before checking that drive is 
SATA. I've changed the order and this fixed my problem. Unfortunately, I 
have not enough hardware to test this. The only thing I'm wondering - is 
this bug or feature? Maybe you know the reason why sata check should go 
almost last?



Your fix looks fine and is similar to how libata handles PATA->SATA bridges.

Please add "Signed-off-by:" line,

  

--- drivers/ide/ide-iops.c.orig 2008-01-03 18:35:23.0 +0300
+++ drivers/ide/ide-iops.c  2008-01-03 18:12:29.0 +0300
@@ -612,12 +612,12 @@
printk(KERN_DEBUG "%s: skipping word 93 validity check\n",
  drive->name);

-   if (hwif->cbl != ATA_CBL_PATA80 && !ivb)
-   goto no_80w;
-
if (ide_dev_is_sata(id))
return 1;



change it to 'if (ide_dev_is_sata(id) && !ivb)' (some ATAPI devices needing
IVB quirk like to identify themselves like SATA ones, but they aren't),

  

+   if (hwif->cbl != ATA_CBL_PATA80 && !ivb)
+   goto no_80w;
+
/*
 * FIXME:
 * - change master/slave IDENTIFY order




and resubmit (cc:ing linux-ide@vger.kernel.org mailing list).

Thanks,
Bart

  


-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Still having problems after sata_promise: ASIC PRD table bug workaround

2008-01-06 Thread Volker Sauer 
On Sa, 05 Jan 2008, Volker Sauer <[EMAIL PROTECTED]> wrote:
> I'm running a Promise Technology PDC20318 (SATA150 TX4) (rev 02) 
> controller in on of my servers and I gettig the following error from time
> to time - espacially when there's high load on the disks:

[...]

> /dev/sda: Seagate ST3250620AS
> /dev/sdb: Hitachi HDS722525VLSA80
> /dev/sdc: Seagate ST3250620AS
> /dev/sdd: Hitachi HDS722525VLSA80

Hi,

now I got an error from sdb, too:

ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
ata4.00: port_status 0x2020
ata4.00: cmd 35/00:f8:b5:35:95/00:03:02:00:00/e0 tag 0 dma 520192 out
 res 51/84:00:ac:39:95/84:00:02:00:00/e2 Emask 0x10 (ATA bus error)
ata4.00: status: { DRDY ERR }
ata4.00: error: { ICRC ABRT }
ata4: soft resetting link
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata4.00: configured for UDMA/100
ata4: EH complete
sd 3:0:0:0: [sdb] 488397168 512-byte hardware sectors (250059 MB)
sd 3:0:0:0: [sdb] Write Protect is off
sd 3:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA

I built the latest smartmontools which can query SATA disks and get:

/dev/sda: ATA Error Count: 0
/dev/sdb: ATA Error Count: 16
/dev/sdc: ATA Error Count: 0
/dev/sdd: ATA Error Count: 33

I'm thinking about replacing the Hitachi disks by 2 Seagate
ST3250620AS.

Any comments on this?

Regards
Volker


signature.asc
Description: Digital signature

[PATCH 7/8] ide: add struct ide_port_info instances to legacy host drivers

2008-01-06 Thread Bartlomiej Zolnierkiewicz 
* Remove 'struct pci_dev *dev' argument from ide_hwif_setup_dma().

* Un-static ide_hwif_setup_dma() and add CONFIG_BLK_DEV_IDEDMA_PCI=n version.

* Add 'const struct ide_port_info *d' argument to ide_device_add[_all]().

* Factor out generic ports init from ide_pci_setup_ports() to ide_init_port(),
  move it to ide-probe.c and call it in in ide_device_add_all() instead of
  ide_pci_setup_ports().

* Move ->mate setup to ide_device_add_all() from ide_port_init().

* Add IDE_HFLAG_NO_AUTOTUNE host flag for host drivers that don't enable
  ->autotune currently.

* Setup hwif->chipset in ide_init_port() but iff pi->chipset is set
  (to not override setup done by ide_hwif_configure()).

* Add ETRAX host handling to ide_device_add_all().

* cmd640.c: set IDE_HFLAG_ABUSE_* also for CONFIG_BLK_DEV_CMD640_ENHANCED=n.

* pmac.c: make pmac_ide_setup_dma() return an error value and move DMA masks
  setup to pmac_ide_setup_device().

* Add 'struct ide_port_info' instances to legacy host drivers, pass them to
  ide_device_add() calls and then remove open-coded ports initialization.

Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
 drivers/ide/arm/icside.c  |   25 +--
 drivers/ide/arm/ide_arm.c |2 
 drivers/ide/arm/rapide.c  |2 
 drivers/ide/cris/ide-cris.c   |   18 
 drivers/ide/h8300/ide-h8300.c |2 
 drivers/ide/ide-generic.c |2 
 drivers/ide/ide-pnp.c |2 
 drivers/ide/ide-probe.c   |   82 +++--
 drivers/ide/ide.c |2 
 drivers/ide/legacy/ali14xx.c  |   24 --
 drivers/ide/legacy/buddha.c   |2 
 drivers/ide/legacy/dtc2278.c  |   24 --
 drivers/ide/legacy/falconide.c|2 
 drivers/ide/legacy/gayle.c|2 
 drivers/ide/legacy/ht6560b.c  |   22 -
 drivers/ide/legacy/ide_platform.c |2 
 drivers/ide/legacy/macide.c   |2 
 drivers/ide/legacy/q40ide.c   |2 
 drivers/ide/legacy/qd65xx.c   |   23 +-
 drivers/ide/legacy/umc8672.c  |   24 --
 drivers/ide/mips/au1xxx-ide.c |   31 --
 drivers/ide/mips/swarm.c  |2 
 drivers/ide/pci/cmd640.c  |   31 ++
 drivers/ide/pci/cs5520.c  |2 
 drivers/ide/pci/sgiioc4.c |   18 +---
 drivers/ide/ppc/mpc8xx.c  |2 
 drivers/ide/ppc/pmac.c|   84 +++---
 drivers/ide/setup-pci.c   |   81 +++-
 include/linux/ide.h   |   13 -
 29 files changed, 259 insertions(+), 271 deletions(-)

Index: b/drivers/ide/arm/icside.c
===
--- a/drivers/ide/arm/icside.c
+++ b/drivers/ide/arm/icside.c
@@ -377,9 +377,6 @@ static void icside_dma_lost_irq(ide_driv
 
 static void icside_dma_init(ide_hwif_t *hwif)
 {
-   hwif->mwdma_mask= 7; /* MW0..2 */
-   hwif->swdma_mask= 7; /* SW0..2 */
-
hwif->dmatable_cpu  = NULL;
hwif->dmatable_dma  = 0;
hwif->set_dma_mode  = icside_set_dma_mode;
@@ -459,11 +456,19 @@ icside_register_v5(struct icside_state *
 
idx[0] = hwif->index;
 
-   ide_device_add(idx);
+   ide_device_add(idx, NULL);
 
return 0;
 }
 
+static const struct ide_port_info icside_v6_port_info __initdata = {
+   .host_flags = IDE_HFLAG_SERIALIZE |
+ IDE_HFLAG_NO_DMA | /* no SFF-style DMA */
+ IDE_HFLAG_NO_AUTOTUNE,
+   .mwdma_mask = ATA_MWDMA2,
+   .swdma_mask = ATA_SWDMA2,
+};
+
 static int __init
 icside_register_v6(struct icside_state *state, struct expansion_card *ec)
 {
@@ -472,6 +477,7 @@ icside_register_v6(struct icside_state *
unsigned int sel = 0;
int ret;
u8 idx[4] = { 0xff, 0xff, 0xff, 0xff };
+   struct ide_port_info d = icside_v6_port_info;
 
ioc_base = ecardm_iomap(ec, ECARD_RES_IOCFAST, 0, 0);
if (!ioc_base) {
@@ -521,30 +527,25 @@ icside_register_v6(struct icside_state *
state->hwif[1]= mate;
 
hwif->maskproc= icside_maskproc;
-   hwif->channel = 0;
hwif->hwif_data   = state;
-   hwif->mate= mate;
-   hwif->serialized  = 1;
hwif->config_data = (unsigned long)ioc_base;
hwif->select_data = sel;
 
mate->maskproc= icside_maskproc;
-   mate->channel = 1;
mate->hwif_data   = state;
-   mate->mate= hwif;
-   mate->serialized  = 1;
mate->config_data = (unsigned long)ioc_base;
mate->select_data = sel | 1;
 
if (ec->dma != NO_DMA && !request_dma(ec->dma, hwif->name)) {
icside_dma_init(hwif);
icside_dma_init(mate);
-   }
+   } else
+   d.mwdma_mask = d.swdma_mask = 0;
 
idx[0] = hw

[PATCH 8/8] ide: add ->cable_detect method to ide_hwif_t

2008-01-06 Thread Bartlomiej Zolnierkiewicz 
* Add ->cable_detect method to ide_hwif_t.

* Call the new method in ide_init_port() if:
  - the host supports UDMA modes > UDMA2 ('hwif->ultra_mask & 78')
  - DMA initialization was successful (if hwif->dma_base is not set
ide_init_port() sets hwif->ultra_mask to zero)
  - "idex=ata66" is not used ('hwif->cbl != ATA_CBL_PATA40_SHORT')

* Convert PCI host drivers to use ->cable_detect method.

While at it:

* Factor out cable detection to separate functions (if not already done).

* hpt366.c/it8213.c/slc90e66.c:
  - don't check cable type if "idex=ata66" is used

* pdc202xx_new.c:
  - add __devinit tag to pdcnew_cable_detect()

* pdc202xx_old.c:
  - rename pdc202xx_old_cable_detect() to pdc2026x_old_cable_detect()
  - add __devinit tag to pdc2026x_old_cable_detect()

Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
-105 bytes
 drivers/ide/ide-probe.c|5 ++
 drivers/ide/pci/aec62xx.c  |   25 +---
 drivers/ide/pci/alim15x3.c |5 --
 drivers/ide/pci/amd74xx.c  |   18 
 drivers/ide/pci/atiixp.c   |6 --
 drivers/ide/pci/cmd64x.c   |5 --
 drivers/ide/pci/cs5535.c   |6 --
 drivers/ide/pci/hpt366.c   |   84 ++---
 drivers/ide/pci/it8213.c   |   21 +-
 drivers/ide/pci/it821x.c   |5 --
 drivers/ide/pci/jmicron.c  |6 --
 drivers/ide/pci/pdc202xx_new.c |8 ---
 drivers/ide/pci/pdc202xx_old.c |   10 ++--
 drivers/ide/pci/piix.c |7 ---
 drivers/ide/pci/scc_pata.c |3 -
 drivers/ide/pci/serverworks.c  |9 
 drivers/ide/pci/siimage.c  |5 --
 drivers/ide/pci/sis5513.c  |5 --
 drivers/ide/pci/slc90e66.c |   19 +
 drivers/ide/pci/tc86c001.c |   24 +++
 drivers/ide/pci/via82cxxx.c|6 --
 include/linux/ide.h|2 
 22 files changed, 137 insertions(+), 147 deletions(-)

Index: b/drivers/ide/ide-probe.c
===
--- a/drivers/ide/ide-probe.c
+++ b/drivers/ide/ide-probe.c
@@ -1343,6 +1343,11 @@ static void ide_init_port(ide_hwif_t *hw
/* call chipset specific routine for each enabled port */
if (d->init_hwif)
d->init_hwif(hwif);
+
+   if (hwif->cable_detect && (hwif->ultra_mask & 0x78)) {
+   if (hwif->cbl != ATA_CBL_PATA40_SHORT)
+   hwif->cbl = hwif->cable_detect(hwif);
+   }
 }
 
 int ide_device_add_all(u8 idx[MAX_HWIFS], const struct ide_port_info *d)
Index: b/drivers/ide/pci/aec62xx.c
===
--- a/drivers/ide/pci/aec62xx.c
+++ b/drivers/ide/pci/aec62xx.c
@@ -166,6 +166,16 @@ static unsigned int __devinit init_chips
return dev->irq;
 }
 
+static u8 __devinit atp86x_cable_detect(ide_hwif_t *hwif)
+{
+   struct pci_dev *dev = to_pci_dev(hwif->dev);
+   u8 ata66 = 0, mask = hwif->channel ? 0x02 : 0x01;
+
+   pci_read_config_byte(dev, 0x49, &ata66);
+
+   return (ata66 & mask) ? ATA_CBL_PATA40 : ATA_CBL_PATA80;
+}
+
 static void __devinit init_hwif_aec62xx(ide_hwif_t *hwif)
 {
struct pci_dev *dev = to_pci_dev(hwif->dev);
@@ -174,21 +184,10 @@ static void __devinit init_hwif_aec62xx(
 
if (dev->device == PCI_DEVICE_ID_ARTOP_ATP850UF)
hwif->set_dma_mode = &aec6210_set_mode;
-   else
+   else {
hwif->set_dma_mode = &aec6260_set_mode;
 
-   if (hwif->dma_base == 0)
-   return;
-
-   if (dev->device == PCI_DEVICE_ID_ARTOP_ATP850UF)
-   return;
-
-   if (hwif->cbl != ATA_CBL_PATA40_SHORT) {
-   u8 ata66 = 0, mask = hwif->channel ? 0x02 : 0x01;
-
-   pci_read_config_byte(dev, 0x49, &ata66);
-
-   hwif->cbl = (ata66 & mask) ? ATA_CBL_PATA40 : ATA_CBL_PATA80;
+   hwif->cable_detect = atp86x_cable_detect;
}
 }
 
Index: b/drivers/ide/pci/alim15x3.c
===
--- a/drivers/ide/pci/alim15x3.c
+++ b/drivers/ide/pci/alim15x3.c
@@ -666,13 +666,12 @@ static void __devinit init_hwif_common_a
hwif->set_dma_mode = &ali_set_dma_mode;
hwif->udma_filter = &ali_udma_filter;
 
+   hwif->cable_detect = ata66_ali15x3;
+
if (hwif->dma_base == 0)
return;
 
hwif->dma_setup = &ali15x3_dma_setup;
-
-   if (hwif->cbl != ATA_CBL_PATA40_SHORT)
-   hwif->cbl = ata66_ali15x3(hwif);
 }
 
 /**
Index: b/drivers/ide/pci/amd74xx.c
===
--- a/drivers/ide/pci/amd74xx.c
+++ b/drivers/ide/pci/amd74xx.c
@@ -199,6 +199,14 @@ static unsigned int __devinit init_chips
return dev->irq;
 }
 
+static u8 __devinit amd_cable_detect(ide_hwif_t *hwif)
+{
+   if ((amd_80w >> hwif->channel) & 1)
+   return ATA_CBL_PATA80;
+   else
+   return ATA_CBL_PATA40;
+}
+
 stati

[PATCH 6/8] ide: separate PCI specific init from generic init in ide_pci_setup_ports()

2008-01-06 Thread Bartlomiej Zolnierkiewicz 
* Setup ->mate and ->channel in ide_pci_setup_ports() instead of
  in ide_hwif_configure().

* Make 'port' parameter for ide_hwif_configure() 'unsigned int'.

* Separate PCI specific init from generic init in ide_pci_setup_ports().

Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
+28 bytes
 drivers/ide/setup-pci.c |   29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

Index: b/drivers/ide/setup-pci.c
===
--- a/drivers/ide/setup-pci.c
+++ b/drivers/ide/setup-pci.c
@@ -337,7 +337,8 @@ static int ide_pci_check_iomem(struct pc
  * ide_hwif_configure  -   configure an IDE interface
  * @dev: PCI device holding interface
  * @d: IDE port info
- * @mate: Paired interface if any
+ * @port: port number
+ * @irq: PCI IRQ
  *
  * Perform the initial set up for the hardware interface structure. This
  * is done per interface port rather than per PCI device. There may be
@@ -346,7 +347,9 @@ static int ide_pci_check_iomem(struct pc
  * Returns the new hardware interface structure, or NULL on a failure
  */
 
-static ide_hwif_t *ide_hwif_configure(struct pci_dev *dev, const struct 
ide_port_info *d, ide_hwif_t *mate, int port, int irq)
+static ide_hwif_t *ide_hwif_configure(struct pci_dev *dev,
+ const struct ide_port_info *d,
+ unsigned int port, int irq)
 {
unsigned long ctl = 0, base = 0;
ide_hwif_t *hwif;
@@ -392,12 +395,7 @@ static ide_hwif_t *ide_hwif_configure(st
 
hwif->dev = &dev->dev;
hwif->cds = d;
-   hwif->channel = port;
 
-   if (mate) {
-   hwif->mate = mate;
-   mate->mate = hwif;
-   }
return hwif;
 }
 
@@ -525,10 +523,25 @@ void ide_pci_setup_ports(struct pci_dev 
continue;   /* port not enabled */
}
 
-   if ((hwif = ide_hwif_configure(dev, d, mate, port, pciirq)) == 
NULL)
+   hwif = ide_hwif_configure(dev, d, port, pciirq);
+   if (hwif == NULL)
continue;
 
*(idx + port) = hwif->index;
+   }
+
+   for (port = 0; port < channels; ++port) {
+   if (*(idx + port) == 0xff)
+   continue;
+
+   hwif = &ide_hwifs[*(idx + port)];
+
+   if (mate) {
+   hwif->mate = mate;
+   mate->mate = hwif;
+   }
+
+   hwif->channel = port;
 
if (d->init_iops)
d->init_iops(hwif);
-
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/8] macide: remove drive->capacity64 quirk

2008-01-06 Thread Bartlomiej Zolnierkiewicz 
Nowadays IDE core always provides drive ID and ide-disk always setups
drive->capacity64 so this quirk is no longer needed.

Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
 drivers/ide/legacy/macide.c |   10 --
 1 file changed, 10 deletions(-)

Index: b/drivers/ide/legacy/macide.c
===
--- a/drivers/ide/legacy/macide.c
+++ b/drivers/ide/legacy/macide.c
@@ -123,16 +123,6 @@ static int __init macide_init(void)
ide_init_port_data(hwif, index);
ide_init_port_hw(hwif, &hw);
 
-   if (macintosh_config->ide_type == MAC_IDE_BABOON &&
-   macintosh_config->ident == MAC_MODEL_PB190) {
-   /* Fix breakage in ide-disk.c: drive capacity   */
-   /* is not initialized for drives without a  */
-   /* hardware ID, and we can't get that without   */
-   /* probing the drive which freezes a 190.   */
-   ide_drive_t *drive = &hwif->drives[0];
-   drive->capacity64 = drive->cyl*drive->head*drive->sect;
-   }
-
hwif->mmio = 1;
 
ide_device_add(idx);
-
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 5/8] ide: always set DMA masks in ide_pci_setup_ports()

2008-01-06 Thread Bartlomiej Zolnierkiewicz 
Always set DMA masks in ide_pci_setup_ports() to make sure that the valid
masks for a host are set.

Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
+34 bytes
 drivers/ide/setup-pci.c |   13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

Index: b/drivers/ide/setup-pci.c
===
--- a/drivers/ide/setup-pci.c
+++ b/drivers/ide/setup-pci.c
@@ -556,10 +556,15 @@ void ide_pci_setup_ports(struct pci_dev 
hwif->drives[1].unmask = 1;
}
 
-   if (hwif->dma_base) {
-   hwif->swdma_mask = d->swdma_mask;
-   hwif->mwdma_mask = d->mwdma_mask;
-   hwif->ultra_mask = d->udma_mask;
+   hwif->swdma_mask = d->swdma_mask;
+   hwif->mwdma_mask = d->mwdma_mask;
+   hwif->ultra_mask = d->udma_mask;
+
+   if ((d->host_flags && IDE_HFLAG_NO_DMA) == 0 &&
+   hwif->dma_base == 0) {
+   hwif->swdma_mask = 0;
+   hwif->mwdma_mask = 0;
+   hwif->ultra_mask = 0;
}
 
hwif->drives[0].autotune = 1;
-
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 3/8] atiixp/cs5535/scc_pata: fix "idex=ata66" parameter handling

2008-01-06 Thread Bartlomiej Zolnierkiewicz 
Don't override the cable type if the "idex=ata66" parameter was used.

While at it:

* atiixp.c: factor out cable detection to atiixp_cable_detect() from
  init_hwif_atiixp().

* cs5535.c: pass 'ide_hwif_t *hwif' instead of 'struct pci_dev *dev' to
  cs5535_cable_detect().

* scc_pata.c: factor out cable detection to scc_cable_detect() from
  init_hwif_scc() and remove incorrect comment.

Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
+16 bytes
 drivers/ide/pci/atiixp.c   |   24 +++-
 drivers/ide/pci/cs5535.c   |8 
 drivers/ide/pci/scc_pata.c |9 +++--
 3 files changed, 26 insertions(+), 15 deletions(-)

Index: b/drivers/ide/pci/atiixp.c
===
--- a/drivers/ide/pci/atiixp.c
+++ b/drivers/ide/pci/atiixp.c
@@ -121,6 +121,19 @@ static void atiixp_set_dma_mode(ide_driv
spin_unlock_irqrestore(&atiixp_lock, flags);
 }
 
+static u8 __devinit atiixp_cable_detect(ide_hwif_t *hwif)
+{
+   struct pci_dev *pdev = to_pci_dev(hwif->dev);
+   u8 udma_mode = 0, ch = hwif->channel;
+
+   pci_read_config_byte(pdev, ATIIXP_IDE_UDMA_MODE + ch, &udma_mode);
+
+   if ((udma_mode & 0x07) >= 0x04 || (udma_mode & 0x70) >= 0x40)
+   return ATA_CBL_PATA80;
+   else
+   return ATA_CBL_PATA40;
+}
+
 /**
  * init_hwif_atiixp-   fill in the hwif for the ATIIXP
  * @hwif: IDE interface
@@ -131,21 +144,14 @@ static void atiixp_set_dma_mode(ide_driv
 
 static void __devinit init_hwif_atiixp(ide_hwif_t *hwif)
 {
-   struct pci_dev *pdev = to_pci_dev(hwif->dev);
-   u8 udma_mode = 0, ch = hwif->channel;
-
hwif->set_pio_mode = &atiixp_set_pio_mode;
hwif->set_dma_mode = &atiixp_set_dma_mode;
 
if (!hwif->dma_base)
return;
 
-   pci_read_config_byte(pdev, ATIIXP_IDE_UDMA_MODE + ch, &udma_mode);
-
-   if ((udma_mode & 0x07) >= 0x04 || (udma_mode & 0x70) >= 0x40)
-   hwif->cbl = ATA_CBL_PATA80;
-   else
-   hwif->cbl = ATA_CBL_PATA40;
+   if (hwif->cbl != ATA_CBL_PATA40_SHORT)
+   hwif->cbl = atiixp_cable_detect(hwif);
 }
 
 static const struct ide_port_info atiixp_pci_info[] __devinitdata = {
Index: b/drivers/ide/pci/cs5535.c
===
--- a/drivers/ide/pci/cs5535.c
+++ b/drivers/ide/pci/cs5535.c
@@ -155,8 +155,9 @@ static void cs5535_set_pio_mode(ide_driv
cs5535_set_speed(drive, XFER_PIO_0 + pio);
 }
 
-static u8 __devinit cs5535_cable_detect(struct pci_dev *dev)
+static u8 __devinit cs5535_cable_detect(ide_hwif_t *hwif)
 {
+   struct pci_dev *dev = to_pci_dev(hwif->dev);
u8 bit;
 
/* if a 80 wire cable was detected */
@@ -175,15 +176,14 @@ static u8 __devinit cs5535_cable_detect(
  */
 static void __devinit init_hwif_cs5535(ide_hwif_t *hwif)
 {
-   struct pci_dev *dev = to_pci_dev(hwif->dev);
-
hwif->set_pio_mode = &cs5535_set_pio_mode;
hwif->set_dma_mode = &cs5535_set_dma_mode;
 
if (hwif->dma_base == 0)
return;
 
-   hwif->cbl = cs5535_cable_detect(dev);
+   if (hwif->cbl != ATA_CBL_PATA40_SHORT)
+   hwif->cbl = cs5535_cable_detect(hwif);
 }
 
 static const struct ide_port_info cs5535_chipset __devinitdata = {
Index: b/drivers/ide/pci/scc_pata.c
===
--- a/drivers/ide/pci/scc_pata.c
+++ b/drivers/ide/pci/scc_pata.c
@@ -644,6 +644,11 @@ static void __devinit init_iops_scc(ide_
init_mmio_iops_scc(hwif);
 }
 
+static u8 __devinit scc_cable_detect(ide_hwif_t *hwif)
+{
+   return ATA_CBL_PATA80;
+}
+
 /**
  * init_hwif_scc   -   set up hwif
  * @hwif: interface to set up
@@ -678,8 +683,8 @@ static void __devinit init_hwif_scc(ide_
else
hwif->ultra_mask = ATA_UDMA5; /* 100MHz */
 
-   /* we support 80c cable only. */
-   hwif->cbl = ATA_CBL_PATA80;
+   if (hwif->cbl != ATA_CBL_PATA40_SHORT)
+   hwif->cbl = scc_cable_detect(hwif);
 }
 
 #define DECLARE_SCC_DEV(name_str)  \
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/8] au1xxx-ide: fix ->io_32bit handling

2008-01-06 Thread Bartlomiej Zolnierkiewicz 
The host driver must set hwif's ->no_io_32bit setting not drive's one
(ide_port_tune_devices() overrides drive's setting).

Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
 drivers/ide/mips/au1xxx-ide.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

Index: b/drivers/ide/mips/au1xxx-ide.c
===
--- a/drivers/ide/mips/au1xxx-ide.c
+++ b/drivers/ide/mips/au1xxx-ide.c
@@ -658,8 +658,7 @@ static int au_ide_probe(struct device *d
hwif->drives[0].autotune= 1;/* 1=autotune, 2=noautotune, 
0=default */
hwif->drives[1].autotune= 1;
 
-   hwif->drives[0].no_io_32bit = 1;
-   hwif->drives[1].no_io_32bit = 1;
+   hwif->no_io_32bit   = 1;
 
auide_hwif.hwif = hwif;
hwif->hwif_data = &auide_hwif;
-
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/8] ide: more IDE probing code rework

2008-01-06 Thread Bartlomiej Zolnierkiewicz 

* Convert legacy host drivers to use struct ide_port_info + ide_device_add()
  instead of open-coding initialization of IDE port data structures.

* Add ->cable_detect method for cable detection + use it in PCI host drivers.

* Fix some bugs in the process (handling of "idex=ata66" in atiixp, cs5535
  and scc_pata and handling I/O 32-bit setting in dtc2278 and au1xxx-ide).

diffstat:

 drivers/ide/arm/icside.c  |   25 ---
 drivers/ide/arm/ide_arm.c |2
 drivers/ide/arm/rapide.c  |2
 drivers/ide/cris/ide-cris.c   |   18 +++--
 drivers/ide/h8300/ide-h8300.c |2
 drivers/ide/ide-generic.c |2
 drivers/ide/ide-pnp.c |2
 drivers/ide/ide-probe.c   |   87 +-
 drivers/ide/ide.c |6 -
 drivers/ide/legacy/ali14xx.c  |   24 ++-
 drivers/ide/legacy/buddha.c   |2
 drivers/ide/legacy/dtc2278.c  |   36 ---
 drivers/ide/legacy/falconide.c|2
 drivers/ide/legacy/gayle.c|2
 drivers/ide/legacy/ht6560b.c  |   22 +++---
 drivers/ide/legacy/ide_platform.c |2
 drivers/ide/legacy/macide.c   |   12 ---
 drivers/ide/legacy/q40ide.c   |2
 drivers/ide/legacy/qd65xx.c   |   23 ---
 drivers/ide/legacy/umc8672.c  |   24 ++-
 drivers/ide/mips/au1xxx-ide.c |   34 +++---
 drivers/ide/mips/swarm.c  |2
 drivers/ide/pci/aec62xx.c |   25 +++
 drivers/ide/pci/alim15x3.c|5 -
 drivers/ide/pci/amd74xx.c |   18 ++---
 drivers/ide/pci/atiixp.c  |   30 -
 drivers/ide/pci/cmd640.c  |   31 -
 drivers/ide/pci/cmd64x.c  |5 -
 drivers/ide/pci/cs5520.c  |2
 drivers/ide/pci/cs5535.c  |   14 +---
 drivers/ide/pci/hpt366.c  |   84 ++---
 drivers/ide/pci/it8213.c  |   21 +++---
 drivers/ide/pci/it821x.c  |5 -
 drivers/ide/pci/jmicron.c |6 -
 drivers/ide/pci/pdc202xx_new.c|8 --
 drivers/ide/pci/pdc202xx_old.c|   10 +--
 drivers/ide/pci/piix.c|7 --
 drivers/ide/pci/scc_pata.c|   12 ++-
 drivers/ide/pci/serverworks.c |9 --
 drivers/ide/pci/sgiioc4.c |   18 +++--
 drivers/ide/pci/siimage.c |5 -
 drivers/ide/pci/sis5513.c |5 -
 drivers/ide/pci/slc90e66.c|   19 +++--
 drivers/ide/pci/tc86c001.c|   24 ---
 drivers/ide/pci/via82cxxx.c   |6 -
 drivers/ide/ppc/mpc8xx.c  |2
 drivers/ide/ppc/pmac.c|   84 ++---
 drivers/ide/setup-pci.c   |  123 +++---
 include/linux/ide.h   |   15 
 49 files changed, 459 insertions(+), 467 deletions(-)
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/8] dtc2278: fix ->io_32bit handling

2008-01-06 Thread Bartlomiej Zolnierkiewicz 
On DTC2278 32-bit I/O has to be enabled for both devices on the port
so always enable it during init time and disallow further changes.

Cc: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
 drivers/ide/ide.c|4 
 drivers/ide/legacy/dtc2278.c |   12 ++--
 2 files changed, 6 insertions(+), 10 deletions(-)

Index: b/drivers/ide/ide.c
===
--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
@@ -791,10 +791,6 @@ int set_io_32bit(ide_drive_t *drive, int
return -EBUSY;
 
drive->io_32bit = arg;
-#ifdef CONFIG_BLK_DEV_DTC2278
-   if (HWIF(drive)->chipset == ide_dtc2278)
-   HWIF(drive)->drives[!drive->select.b.unit].io_32bit = arg;
-#endif /* CONFIG_BLK_DEV_DTC2278 */
 
spin_unlock_irq(&ide_lock);
 
Index: b/drivers/ide/legacy/dtc2278.c
===
--- a/drivers/ide/legacy/dtc2278.c
+++ b/drivers/ide/legacy/dtc2278.c
@@ -84,12 +84,6 @@ static void dtc2278_set_pio_mode(ide_dri
/* Actually we do - there is a data sheet available for the
   Winbond but does anyone actually care */
}
-
-   /*
-* 32bit I/O has to be enabled for *both* drives at the same time.
-*/
-   drive->io_32bit = 1;
-   HWIF(drive)->drives[!drive->select.b.unit].io_32bit = 1;
 }
 
 static int __init dtc2278_probe(void)
@@ -123,18 +117,24 @@ static int __init dtc2278_probe(void)
local_irq_restore(flags);
 
hwif->serialized = 1;
+   hwif->no_io_32bit = 1;  /* disallow ->io_32bit changes */
hwif->chipset = ide_dtc2278;
hwif->pio_mask = ATA_PIO4;
hwif->set_pio_mode = &dtc2278_set_pio_mode;
hwif->drives[0].no_unmask = 1;
hwif->drives[1].no_unmask = 1;
+   hwif->drives[0].io_32bit = 1;
+   hwif->drives[1].io_32bit = 1;
hwif->mate = mate;
 
mate->serialized = 1;
+   mate->no_io_32bit = 1;
mate->chipset = ide_dtc2278;
mate->pio_mask = ATA_PIO4;
mate->drives[0].no_unmask = 1;
mate->drives[1].no_unmask = 1;
+   mate->drives[0].io_32bit = 1;
+   mate->drives[1].io_32bit = 1;
mate->mate = hwif;
mate->channel = 1;
 
-
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: [RFC PATCH] ide-floppy: remove struct idefloppy_capabilities_page

2008-01-06 Thread Bartlomiej Zolnierkiewicz 
On Sunday 06 January 2008, Borislav Petkov wrote:
> Hi Bart,
> 
> before removing all those typedefs in ide-floppy i wanted to check with you 
> whether what
> i have in mind is in the right direction before doing all the work for 
> nothing.
> Here's the first patch removing struct idefloppy_capabilities_page. Please, 
> tell
> me whether it is similar to what you guys have in mind or is it missing the
> point.
> 
> Thanks.

You are 100% on the right track. :)

> From 41c791f40e3fcf2287aa245f25796fa58bb17afc Mon Sep 17 00:00:00 2001
> From: Borislav Petkov <[EMAIL PROTECTED]>
> Date: Sun, 6 Jan 2008 10:37:47 +0100
> Subject: [PATCH] ide-floppy: remove struct idefloppy_capabilities_page
> 
> This change is rather temporary and is in preparation of using generic 
> commands
> as is the case with ide-cd and the uniform cdrom layer (i.e. 
> init_cdrom_command())
> However, before this happens, we'll have to remove all typedefs and teach
> idefloppy_create_mode_sense_cmd() to work directly on u8 buffers.
> 
> Also, since idefloppy_get_capability_page() was used to read only the sfrp 
> bit,
> rename the latter so that the name reflects what it does.
> 
> Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>

applied
-
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: [RESEND PATCH 06/10] ide-floppy: report DMA handling in idefloppy_pc_intr() properly

2008-01-06 Thread Bartlomiej Zolnierkiewicz 
On Saturday 05 January 2008, Borislav Petkov wrote:
> On Sat, Jan 05, 2008 at 04:46:05PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > Hmm, no.  The driver is called ide-floppy (ide_floppy) and it is more
> > readable this way.
> > 
> > >  {
> > >   idefloppy_t *floppy = drive->driver_data;
> > >   struct gendisk *g = floppy->disk;
> > > @@ -1479,7 +1450,7 @@ static ide_proc_entry_t idefloppy_proc[] = {
> > >  };
> > >  #endif   /* CONFIG_IDE_PROC_FS */
> > >  
> > > -static int ide_floppy_probe(ide_drive_t *);
> > > +static int idefloppy_probe(ide_drive_t *);
> > 
> > ditto
> >  
> > [...]
> > 
> > > @@ -1733,7 +1704,7 @@ static struct block_device_operations idefloppy_ops 
> > > = {
> > >   .revalidate_disk= idefloppy_revalidate_disk
> > >  };
> > >  
> > > -static int ide_floppy_probe(ide_drive_t *drive)
> > > +static int idefloppy_probe(ide_drive_t *drive)
> > 
> > ditto
> Shouldn't those also conform to the driver function format idefloppy_bla() -
> after all, those function names are unambiguous for the whole file...?

Why conform to something sub-optimal instead of changing it?

+ I was using ide_floppy_* in the new code to tag the areas that were
rewritten. Currently it doesn't look that optimistic since there are five
ide_floppy_* functions and fifty idefloppy_* ones but I'm hoping that this
statistics will improve after your patches. :)

Thanks,
Bart
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Fwd: Re: libata , Silicon Image 3124]

2008-01-06 Thread Kasimir Müller 
Hi Tejun,

Old communication appended below.

I wish you a Happy Xmas and a successful New Year.

I spent some time during Christmas to further investigate the problem. I
bought a new 500GB disk and put all data on this disk.
This is also contineously watched by nagios and cacti
Then
1.) All 5 disks in the external case connected via Portmapper and sil24
card have excellent health-status with smartd.
2.) I get no() errors at all if I use the disks as single drives or
with lvm. I verified this by copying large amounts of data (100-200GB)
 with rsync , cp-av and running bonnie++ single and simultaneously 
to  various combinations of drives.
3.) I get the errors as soon as I use raid. Same errors with raid0 (2
disks), 1 (2 disks), 5 (3 disks) in any combination of the drives
4.) The errors appear usually first during mkfs (same with ext3 and
reiserfs) and than
 after writing about 10-50 GB to the raid, and repeat then at 5 to
10 minute intervals according the disk activity.
5.) I used Kernel 2.6.23.1 with Your latest patch: same result
6.) I used kernel 2.6.24 patch rc-6 : same result
7.) during the tests I marked all files with md5-sums:  No data
corruption (!!!), so maybe I can live with it.


linux:/var/log # cat /proc/interrupts
   CPU0
  0:   12457604XT-PIC-XTtimer
  1:  8XT-PIC-XTi8042
  2:  0XT-PIC-XTcascade
  4: 186738XT-PIC-XTserial
  5:   13328470XT-PIC-XTsata_via, ehci_hcd:usb5, VIA8237,
fcpci, eth0
  6:  5XT-PIC-XTfloppy
  8:  0XT-PIC-XTrtc
  9:  0XT-PIC-XTacpi
 10:8019753XT-PIC-XTsata_sil24
 11:114XT-PIC-XTuhci_hcd:usb1, uhci_hcd:usb2
 14: 468588XT-PIC-XTlibata
 15:  0XT-PIC-XTlibata, uhci_hcd:usb3, uhci_hcd:usb4
NMI:  0
LOC:   12457724
ERR:  1


complete log of kernel errors from today appended as gz:

In the opensuse mailing-list some people reported related errors.
http://lists.opensuse.org/opensuse-de/2007-12/msg00939.html

Can You make someting out of this ? Do You need any more information
(please detail, because I am not a linux-guru)

Yours sincerely

Kasimir Mueller

> [EMAIL PROTECTED] didn't work.  Forwarding to the original address.
>   
it is [EMAIL PROTECTED]
>   
>
> 
>
> Betreff:
> Re: libata , Silicon Image 3124
> Von:
> Tejun Heo <[EMAIL PROTECTED]>
> Datum:
> Wed, 14 Nov 2007 11:10:57 +0900
> An:
> Kasimir Mueller <[EMAIL PROTECTED]>
>
> An:
> Kasimir Mueller <[EMAIL PROTECTED]>
> CC:
> IDE/ATA development list 
>
> Return-Path:
> <[EMAIL PROTECTED]>
> X-Original-To:
> [EMAIL PROTECTED]
> Delivered-To:
> [EMAIL PROTECTED]
> Received:
> from [127.0.0.2] (htj.dyndns.org [127.0.0.2]) by htj.dyndns.org
> (Postfix) with ESMTP id 50E1813A81CF; Wed, 14 Nov 2007 11:10:57 +0900
> (KST)
> Nachricht-ID:
> <[EMAIL PROTECTED]>
> User-Agent:
> Thunderbird 2.0.0.6 (X11/20070801)
> MIME-Version:
> 1.0
> Referenzen:
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> In-Reply-To:
> <[EMAIL PROTECTED]>
> X-Enigmail-Version:
> 0.95.3
> Content-Type:
> text/plain; charset=ISO-8859-15
> Content-Transfer-Encoding:
> 8bit
>
>
> [linux-ide added back. please don't drop cc list]
>
> Kasimir Mueller wrote:
>   
>> Tejun Heo schrieb:
>> 
>>> Kasimir Müller wrote:
>>>  
>>>   
 Nov 12 19:28:42 linux kernel: ata6.02: cmd
 ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0
 Nov 12 19:28:42 linux kernel:  res
 40/00:00:09:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
 
 
>>> That's flush timing out, which isn't good.
>>>
>>> 1. Are the errors localized to ata6.02?
>>>   
>>>   
>> I think it's ata6.01
>> 
>
> The above message says 6.02 tho.  Anyways, if the errors are localized
> to one drive, please swap that drive with another drive.  Do the errors
> follow the drive or stay with the slot?
>
>   
>>> 2. Is FLUSH always involved (ie. is cmd always ea)?
>>>   
>>>   
>> yes
>> 
>
> Hmmm... okay.  That sounds like a dying drive to me.  What does
> 'smartctl -a /dev/sdX' say?
>
>   
>>> 3. If you disable NCQ, what do errors look like?
>>>   
>>>   
>> I put all disk-drives in the blacklist , without a change
>> 
>
> So, NCQ isn't the problem.
>
> ATM, it sounds like a dying drive to me.  Please double check the errors
> are localized to one drive, check smartctl log and try to verify as
> written above.
>
> Thanks.
>
>   



kernel.log.today.gz
Description: GNU Zip compressed data

[RFC PATCH] ide-floppy: remove struct idefloppy_capabilities_page

2008-01-06 Thread Borislav Petkov 
Hi Bart,

before removing all those typedefs in ide-floppy i wanted to check with you 
whether what
i have in mind is in the right direction before doing all the work for nothing.
Here's the first patch removing struct idefloppy_capabilities_page. Please, tell
me whether it is similar to what you guys have in mind or is it missing the
point.

Thanks.


>From 41c791f40e3fcf2287aa245f25796fa58bb17afc Mon Sep 17 00:00:00 2001
From: Borislav Petkov <[EMAIL PROTECTED]>
Date: Sun, 6 Jan 2008 10:37:47 +0100
Subject: [PATCH] ide-floppy: remove struct idefloppy_capabilities_page

This change is rather temporary and is in preparation of using generic commands
as is the case with ide-cd and the uniform cdrom layer (i.e. 
init_cdrom_command())
However, before this happens, we'll have to remove all typedefs and teach
idefloppy_create_mode_sense_cmd() to work directly on u8 buffers.

Also, since idefloppy_get_capability_page() was used to read only the sfrp bit,
rename the latter so that the name reflects what it does.

Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
---
 drivers/ide/ide-floppy.c |   55 +-
 1 files changed, 6 insertions(+), 49 deletions(-)

diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index e8fe8ef..2b9885f 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -120,44 +120,6 @@ typedef struct idefloppy_packet_command_s {
 #definePC_SUPPRESS_ERROR   6   /* Suppress error 
reporting */
 
 /*
- * Removable Block Access Capabilities Page
- */
-typedef struct {
-#if defined(__LITTLE_ENDIAN_BITFIELD)
-   unsignedpage_code   :6; /* Page code - Should be 0x1b */
-   unsignedreserved1_6 :1; /* Reserved */
-   unsignedps  :1; /* Should be 0 */
-#elif defined(__BIG_ENDIAN_BITFIELD)
-   unsignedps  :1; /* Should be 0 */
-   unsignedreserved1_6 :1; /* Reserved */
-   unsignedpage_code   :6; /* Page code - Should be 0x1b */
-#else
-#error "Bitfield endianness not defined! Check your byteorder.h"
-#endif
-   u8  page_length;/* Page Length - Should be 0xa 
*/
-#if defined(__LITTLE_ENDIAN_BITFIELD)
-   unsignedreserved2   :6;
-   unsignedsrfp:1; /* Supports reporting progress 
of format */
-   unsignedsflp:1; /* System floppy type device */
-   unsignedtlun:3; /* Total logical units 
supported by the device */
-   unsignedreserved3   :3;
-   unsignedsml :1; /* Single / Multiple lun 
supported */
-   unsignedncd :1; /* Non cd optical device */
-#elif defined(__BIG_ENDIAN_BITFIELD)
-   unsignedsflp:1; /* System floppy type device */
-   unsignedsrfp:1; /* Supports reporting progress 
of format */
-   unsignedreserved2   :6;
-   unsignedncd :1; /* Non cd optical device */
-   unsignedsml :1; /* Single / Multiple lun 
supported */
-   unsignedreserved3   :3;
-   unsignedtlun:3; /* Total logical units 
supported by the device */
-#else
-#error "Bitfield endianness not defined! Check your byteorder.h"
-#endif
-   u8  reserved[8];
-} idefloppy_capabilities_page_t;
-
-/*
  * Flexible disk page.
  */
 typedef struct {
@@ -397,7 +359,8 @@ typedef struct {
 } idefloppy_request_sense_result_t;
 
 /*
- * Pages of the SELECT SENSE / MODE SENSE packet commands.
+ * Pages of the SELECT SENSE / MODE SENSE packet commands.
+ * See SFF-8070i spec.
  */
 #defineIDEFLOPPY_CAPABILITIES_PAGE 0x1b
 #define IDEFLOPPY_FLEXIBLE_DISK_PAGE   0x05
@@ -1273,25 +1236,20 @@ static int idefloppy_get_flexible_disk_page 
(ide_drive_t *drive)
return 0;
 }
 
-static int idefloppy_get_capability_page(ide_drive_t *drive)
+static int idefloppy_get_sfrp_bit(ide_drive_t *drive)
 {
idefloppy_floppy_t *floppy = drive->driver_data;
idefloppy_pc_t pc;
-   idefloppy_mode_parameter_header_t *header;
-   idefloppy_capabilities_page_t *page;
 
floppy->srfp = 0;
idefloppy_create_mode_sense_cmd(&pc, IDEFLOPPY_CAPABILITIES_PAGE,
 MODE_SENSE_CURRENT);
 
set_bit(PC_SUPPRESS_ERROR, &pc.flags);
-   if (idefloppy_queue_pc_tail(drive,&pc)) {
+   if (idefloppy_queue_pc_tail(drive, &pc))
return 1;
-   }
 
-   header = (idefloppy_mode_parameter_header_t *) pc.buffer;
-   page= (idefloppy_capabilities_page_t *)(header+1);
-   floppy->srfp = page->srfp;
+   floppy->srfp = pc.buffer[8 + 2] & 0x40;
return (0);
 }
 
@@ -1497,8 +1455,7 @@ static int idefloppy_begin_format(ide_drive_t *drive