Hello,
Bartlomiej Zolnierkiewicz wrote:
> * (partially) fix DMA in RAID mode
>
> Code intended to check DMA status was checking DMA command register.
> Moreover firmware seems to "forget" to set DMA capable bit for the
> slave device (at least in RAID mode but without ITE RAID volumes) so
>
[EMAIL PROTECTED] wrote:
> Problem Sata disks are connected to onboard sata ports of PowerEdge
> 1900 (ESB2 southbridge chipset). If one of the port is disabled in
> the bios then they get enabled again by the ata_piix driver because
> of a default port map being written to the Port control and sta
* fix PIO setup for devices with different PIO speeds in passthru mode
IT821x allows one PIO setting per port se we have to limit maximum
PIO mode to the one of the slowest device on the port.
* (partially) fix DMA in RAID mode
Code intended to check DMA status was checking DMA command re
On Sat, 9 Jun 2007 00:42:50 +0200
Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
> On Friday 08 June 2007, Alan Cox wrote:
> > On Fri, 8 Jun 2007 14:18:55 +0200
> > Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
> >
> > > On Monday 04 June 2007, Jiri Slaby wrote:
> > > > ide-generic,
On Friday 08 June 2007, Alan Cox wrote:
> On Fri, 8 Jun 2007 14:18:55 +0200
> Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
>
> > On Monday 04 June 2007, Jiri Slaby wrote:
> > > ide-generic, add another device exception
> >
> > ide-generic is a generic ISA IDE driver, this one is drivers/i
Robert de Rooy wrote:
Mark Lord wrote:
I still don't see much evidence that interrupts are actually
functioning here.
It would be good to see /proc/interrupts before/after libata tries to
talk to it.
Let's assume for the moment that interrupts are b0rken.
The legacy IDE driver can talk to suc
Mark Lord wrote:
I still don't see much evidence that interrupts are actually
functioning here.
It would be good to see /proc/interrupts before/after libata tries to
talk to it.
Let's assume for the moment that interrupts are b0rken.
The legacy IDE driver can talk to such devices completely wi
On Fri, 8 Jun 2007 14:18:55 +0200
Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
> On Monday 04 June 2007, Jiri Slaby wrote:
> > ide-generic, add another device exception
>
> ide-generic is a generic ISA IDE driver, this one is drivers/ide/pci/generic
> (a generic IDE PCI driver) - fixed pa
Hi,
On Friday 08 June 2007, Jeff Garzik wrote:
> On Fri, Jun 08, 2007 at 02:18:55PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Monday 04 June 2007, Jiri Slaby wrote:
> > > ide-generic, add another device exception
> >
> > ide-generic is a generic ISA IDE driver, this one is drivers/ide/pci/g
I just confirmed that two PATA-era major BIOS brands do SRST. They do
check for the device signature in TF registers... but only for the ATA
device signature.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
Mor
> I agree IT821x wants fixing, FWIW, just trying to get a handle on
> the big picture. I'm not surprised that IT821x gets reset wrong,
> since it's a very non-standard BIOS.
Its a firmware emulation bug, the IT821X is emulating an IDE device
rather than neccessarily exposing one directly to the k
On Fri, Jun 08, 2007 at 04:46:30PM +0100, Alan Cox wrote:
> > Ah, I guess I misunderstood. I thought you were referring to Fedora
> > 7 bug reports, since there are not a load of people with IT821x.
>
> There are. Several vendors shipped it on the motherboard and there are
> either quite a few us
> Ah, I guess I misunderstood. I thought you were referring to Fedora
> 7 bug reports, since there are not a load of people with IT821x.
There are. Several vendors shipped it on the motherboard and there are
either quite a few users, or they all use Fedora and they like filing
bugs 8(
Alan
-
To
On Fri, 8 Jun 2007 11:35:13 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 08, 2007 at 04:38:04PM +0100, Alan Cox wrote:
> > > See a URL I posted earlier in this thread. With dumb ATAPI devices we
> > > actually have to wait a bit for BSY to be asserted. Not only at reset,
> > > but
On Fri, Jun 08, 2007 at 04:33:37PM +0100, Alan Cox wrote:
> > > Allowing legacy to be used on non-PCI systems was your idea! Alright,
> > > then we can drop a lot of junk from legacy SFF code. Will prep another
> > > patch. Please ignore two patches in this thread.
> >
> > Alan seems to be igno
On Fri, Jun 08, 2007 at 04:38:04PM +0100, Alan Cox wrote:
> > See a URL I posted earlier in this thread. With dumb ATAPI devices we
> > actually have to wait a bit for BSY to be asserted. Not only at reset,
> > but also for every command
>
> 400nS and the current code correctly accounts for it.
On Fri, Jun 08, 2007 at 04:36:15PM +0100, Alan Cox wrote:
> On Fri, 8 Jun 2007 10:28:22 -0400
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Jun 08, 2007 at 12:40:58PM +0100, Alan Cox wrote:
> > > Seems best to me - we know the current code breaks a load of systems and
> > > the change sho
> See a URL I posted earlier in this thread. With dumb ATAPI devices we
> actually have to wait a bit for BSY to be asserted. Not only at reset,
> but also for every command
400nS and the current code correctly accounts for it.
> > How about limiting nsect/lbal wait duration? Say, 100ms or 500
On Fri, 8 Jun 2007 10:28:22 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 08, 2007 at 12:40:58PM +0100, Alan Cox wrote:
> > Seems best to me - we know the current code breaks a load of systems and
> > the change should not break anything but fix them all. If we ship without
> > it bei
> > Allowing legacy to be used on non-PCI systems was your idea! Alright,
> > then we can drop a lot of junk from legacy SFF code. Will prep another
> > patch. Please ignore two patches in this thread.
>
> Alan seems to be ignoring that idea, so it turned out to be useless... :/
For the init
On Fri, Jun 08, 2007 at 05:02:24PM +0900, Tejun Heo wrote:
> I don't think the first one is probable considering BSY is supposed to
> set when SRST is received. This is pretty fundamental in the protocol
> and necessary for the device to work properly as master, so I think this
> is one of few thi
On Fri, Jun 08, 2007 at 12:40:58PM +0100, Alan Cox wrote:
> Seems best to me - we know the current code breaks a load of systems and
> the change should not break anything but fix them all. If we ship without
> it being changed then a load of people are stuck with broken ATA.
So you have verified
On Fri, Jun 08, 2007 at 11:12:01PM +0900, Tejun Heo wrote:
> Jeff Garzik wrote:
> > On Fri, Jun 08, 2007 at 08:41:19PM +0900, Tejun Heo wrote:
> >> libata used to claim only cmd ports for legacy SFF ports. Claim ctl
> >> ports too.
> >>
> >> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
> >> ---
>
Problem
Sata disks are connected to onboard sata ports of PowerEdge 1900 (ESB2
southbridge chipset). If one of the port is disabled in the bios then they get
enabled again by the ata_piix driver because of a default port map being
written to the Port control and status register(0x91-93).
Instea
Jeff Garzik wrote:
> On Fri, Jun 08, 2007 at 08:41:19PM +0900, Tejun Heo wrote:
>> libata used to claim only cmd ports for legacy SFF ports. Claim ctl
>> ports too.
>>
>> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
>> ---
>> This has been this way as long as I can remember. It's almost
>> pleasa
On Fri, Jun 08, 2007 at 02:18:55PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Monday 04 June 2007, Jiri Slaby wrote:
> > ide-generic, add another device exception
>
> ide-generic is a generic ISA IDE driver, this one is drivers/ide/pci/generic
> (a generic IDE PCI driver) - fixed patch descripti
On Fri, Jun 08, 2007 at 08:41:19PM +0900, Tejun Heo wrote:
> libata used to claim only cmd ports for legacy SFF ports. Claim ctl
> ports too.
>
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
> ---
> This has been this way as long as I can remember. It's almost
> pleasant to see that it survived
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/bart/ide-2.6.git/
to receive the following updates:
drivers/ide/ide-disk.c| 12 +
drivers/ide/ide-probe.c | 12 +-
drivers/ide/ide.c |9 ++-
drivers/ide/pci/amd74xx.c | 12
On Wednesday 06 June 2007, Sergei Shtylyov wrote:
> Eliminate UltraATA/133 support for HPT374 -- the chip isn't capable of this
> mode
> according to the manual, and doesn't even seem to tolerate 66 MHz DPLL
> clock...
>
> Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
applied
-
To unsubscr
On Tuesday 05 June 2007, Sergei Shtylyov wrote:
> Hello.
>
> Bartlomiej Zolnierkiewicz wrote:
>
> >>There's no reason to have the speedproc() method wrapper for the two quite
> >>different chip families, so just get rid of it.
>
> >>Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
>
> >>---
>
On Tuesday 05 June 2007, Sergei Shtylyov wrote:
> Hello.
>
> Bartlomiej Zolnierkiewicz wrote:
>
> >>>The log of a typical IDE reset is available here:
>
> >>>http://petra.hos.u-szeged.hu/~wildy/syslog.gz
>
> >>>This was the worst case: the IDE bus was resetted during the system
> >
On Wednesday 06 June 2007, Sergei Shtylyov wrote:
> Simplify UltraDMA mode filtering in the driver:
>
> - make use of the newly introduced 'udma_mask' field of 'ide_pci_device_t' to
> set the correct hwif->ultra_mask, modifying init_setup_hpt366() to select
> the correct mask based on the chip
On Monday 04 June 2007, Alan Cox wrote:
> > Cc: Alan Cox <[EMAIL PROTECTED]>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
>
> Looks good to me - and I can confirm no libata problem reports from us
> always setting modes ourselves.
Thanks for review, added your ACK to the patch
On Monday 04 June 2007, Jiri Slaby wrote:
> ide-generic, add another device exception
ide-generic is a generic ISA IDE driver, this one is drivers/ide/pci/generic
(a generic IDE PCI driver) - fixed patch description to avoid confusion.
[ Yes, both drivers need a rename - patches are welcomed. ]
On Sunday 03 June 2007, Robert P. J. Day wrote:
>
> Delete the unnecessary macro ARY_LEN and use ARRAY_SIZE directly.
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
applied
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTE
Michel Lespinasse wrote:
> On Sun, Jun 03, 2007 at 10:24:38AM -0400, Jeff Garzik wrote:
>> Michel Lespinasse wrote:
>>> * Is there anything one needs to know before hot-removing a drive ?
>> Make sure all data is flushed to the drive before removing it.
>
> Sure. Is there a way to do that, though,
Tejun Heo wrote:
Jun 7 21:10:29 localhost kernel: ata3.00: CFA: Memory Card Adapter,
20011212, max PIO1
Jun 7 21:10:29 localhost kernel: ata3.00: 253696 sectors, multi 0: LBA
Jun 7 21:10:29 localhost kernel: ata3.00: issuing IDENTIFY
Jun 7 21:10:29 localhost kernel: ata3.00: IDENTIFY comple
> It was that way to allow legacy SFF code to be used in non-PCI
> environment. Is it gonna?
Probably best to keep that in the affected driver - we have two drivers
at the moment which know bits about ISA legacy and I'm currently folding
them into one. I don't think they can usefully use the liba
For legacy SFF port, cmd ioport is claimed in legacy_dr while ctl
ioport is claimed using resource-managed pci_request_region(). Move
ctl port claiming into legacy_dr for consistency. This also makes
legacy SFF code easier to use for non-PCI device.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
-
Alan Cox wrote:
> On Fri, 8 Jun 2007 20:41:19 +0900
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> libata used to claim only cmd ports for legacy SFF ports. Claim ctl
>> ports too.
>
> Just use pci resource functions. The quirk handlers do the rest for you
> already.
It was that way to allow legac
On Fri, 8 Jun 2007 20:41:19 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> libata used to claim only cmd ports for legacy SFF ports. Claim ctl
> ports too.
Just use pci resource functions. The quirk handlers do the rest for you
already.
-
To unsubscribe from this list: send the line "unsubscribe
libata used to claim only cmd ports for legacy SFF ports. Claim ctl
ports too.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
This has been this way as long as I can remember. It's almost
pleasant to see that it survived through all the devres/init rework.
I guess it's time for a change.
dri
> If we still have several rc's left, how about just removing it and
> watching the fireworks? Jeff?
Seems best to me - we know the current code breaks a load of systems and
the change should not break anything but fix them all. If we ship without
it being changed then a load of people are stuck
Alan Cox wrote:
>> Upto 2.6.21, if the same condition triggers, it delays 30secs and just
>> continue, so I don't think it was a worthy protection against ghost
>> devices or TF malfunction. The only protection it offers is preventing
>> libata from accessing slave's status register too early. SR
> Upto 2.6.21, if the same condition triggers, it delays 30secs and just
> continue, so I don't think it was a worthy protection against ghost
> devices or TF malfunction. The only protection it offers is preventing
> libata from accessing slave's status register too early. SRST sequence
> looks
Hello,
Jeff Garzik wrote:
> On Thu, Jun 07, 2007 at 01:56:11PM -0700, Linus Torvalds wrote:
>> On Thu, 7 Jun 2007, Tejun Heo wrote:
>>> Ah.. okay. Now I see what's going on. Jeff, this is another device
>>> which doesn't set nsect and lbal to 1 after reset. Gregor, please try
>>> the attached p
-stable review patch. If anyone has any objections, please let us know.
-
From: Tejun Heo <[EMAIL PROTECTED]>
For some reason, sata_via is missing PM hooks. Add them. Spotted by
Jeroen Janssen <[EMAIL PROTECTED]>.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Jeroen Jan
Hello,
Robert de Rooy wrote:
> Jun 7 21:10:28 localhost kernel: ata3: soft resetting port
> Jun 7 21:10:28 localhost kernel: ata3: reset complete
> Jun 7 21:10:28 localhost kernel: ATA: abnormal status 0x80 on port
> 0x00014107
> Jun 7 21:10:28 localhost kernel: ATA: abnormal status 0x80 on po
48 matches
Mail list logo
