Linus Torvalds wrote:
So what's the resolution? Right now this is apparently the reasong for
Based on the thread it sounded like Tejun was going to post a slightly
modified version of his patch?
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Thu, 7 Jun 2007, Jeff Garzik wrote:
>
> Ack'ing the sata_promise change was easy, but with this one it would
> be nice to wait a bit before changing the core probe code that [now]
> every ATA setup goes through, based on a single bug report.
So what's the resolution? Right now this is apparen
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-kernel" in
the body of a message to [EMAIL PROTECTED]
> 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: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
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
> 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
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 patch.
> Tejun, since Jeff is
On Thu, 7 Jun 2007 13:56:11 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> 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 pa
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 patch.
Tejun, since Jeff is apparently traveling this week, and Gregor tested the
patch successfu
2007/6/7, Tejun Heo <[EMAIL PROTECTED]>:
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 patch.
It works like a charm.
Thanks for debugging.
Gregor
[ 307.605884] ata_piix :00:07.1:
Gregor Jasny wrote:
> 2007/6/6, Tejun Heo <[EMAIL PROTECTED]>:
>> Let's see where we're failing.
>
> [ 186.849280] ata_piix :00:07.1: version 2.11
> [ 186.849665] scsi0 : ata_piix
> [ 186.850241] scsi1 : ata_piix
> [ 186.850596] ata1: PATA max UDMA/33 cmd 0x000101f0 ctl 0x000103f6
> bmdma
2007/6/6, Tejun Heo <[EMAIL PROTECTED]>:
Let's see where we're failing.
[ 186.849280] ata_piix :00:07.1: version 2.11
[ 186.849665] scsi0 : ata_piix
[ 186.850241] scsi1 : ata_piix
[ 186.850596] ata1: PATA max UDMA/33 cmd 0x000101f0 ctl 0x000103f6
bmdma 0x00010860 irq 14
[ 186.851203] a
Gregor Jasny wrote:
> 2007/6/2, Jeff Garzik <[EMAIL PROTECTED]>:
>> Does this patch change the behavior at all?
>
> No. It still times out. I've raised the first timeout to 60 seconds
> but still no luck.
Let's see where we're failing. Please apply the attached patch and
report what kernel says.
2007/6/2, Jeff Garzik <[EMAIL PROTECTED]>:
Does this patch change the behavior at all?
No. It still times out. I've raised the first timeout to 60 seconds
but still no luck.
[ 19.403632] ata_piix :00:07.1: version 2.11
[ 19.404013] scsi0 : ata_piix
[ 19.404482] scsi1 : ata_piix
[ 1
Gregor Jasny wrote:
Hi,
2007/5/26, Linus Torvalds <[EMAIL PROTECTED]>:
What more could you possibly want? Some ATA updates? USB suspend problem
22-rc3 broke the CDROM in my Dell notebook. After I've switched to
libata som time ago, I've got some delays/timeouts during boot [1].
But the drive
26 matches
Mail list logo
