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
Hello, Jeff, Linus.
Jeff Garzik wrote:
> Linus Torvalds wrote:
>>
>> On Fri, 1 Jun 2007, Jeff Garzik wrote:
>>> With these old PATA devices, device reset is "six of one, half-dozen
>>> of the
>>> other." Using SRST is the only way to kick some ATAPI devices into
>>> working:
>>> http://suif.stanf
Jeff Garzik wrote:
Upon quick review, it appears it should be 110ms. And actually the spec
says 3ms. But to answer your question anyway... :)
Actually the 3ms is the DRQ assertion delay.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Fri, Jun 01, 2007 at 11:30:49AM -0700, Linus Torvalds wrote:
> > There are no old drivers in F7 and beyond.
> > # CONFIG_IDE is not set
>
> Ahh, that's certainly going to root out the issues. Now let's hope that
> people install it..
Whilst it's too early to tell yet, there are a few re
Linus Torvalds wrote:
On Fri, 1 Jun 2007, Jeff Garzik wrote:
With these old PATA devices, device reset is "six of one, half-dozen of the
other." Using SRST is the only way to kick some ATAPI devices into working:
http://suif.stanford.edu/~csapuntz/blackmagic.html#reset
Well, wouldn't it be a
On Fri, 1 Jun 2007, Dave Jones wrote:
>
> There are no old drivers in F7 and beyond.
>
> # CONFIG_IDE is not set
Ahh, that's certainly going to root out the issues. Now let's hope that
people install it..
(Fedora seems to make it hard on purpose to upgrade between major
revisions, but maybe
On Fri, Jun 01, 2007 at 10:59:51AM -0700, Linus Torvalds wrote:
> > I'm mainly interested in hearing feedback from Fedora 7 damage, before
> > making
> > a major decision about the probing code. If this is a single dain bramaged
> > device, we should avoid punishing the majority. But if thi
On Fri, 1 Jun 2007, Jeff Garzik wrote:
>
> With these old PATA devices, device reset is "six of one, half-dozen of the
> other." Using SRST is the only way to kick some ATAPI devices into working:
> http://suif.stanford.edu/~csapuntz/blackmagic.html#reset
Well, wouldn't it be a good thing to
Linus Torvalds wrote:
On Fri, 1 Jun 2007, Jeff Garzik wrote:
I'm about to dive into some heads-down RHEL backporting (whee), so I cannot
look at the code in depth this weekend, but here are my basic thoughts:
* We knew there would be fallout from the new reset-sequence code, and this is
clearl
On Fri, 1 Jun 2007, Jeff Garzik wrote:
>
> I'm about to dive into some heads-down RHEL backporting (whee), so I cannot
> look at the code in depth this weekend, but here are my basic thoughts:
>
> * We knew there would be fallout from the new reset-sequence code, and this is
> clearly in that c
Tejun Heo wrote:
Most BIOSen, Windows and old IDE driver don't reset at all during
probing. They first issue IDENTIFY unconditionally, if that fails,
IDENTIFY_PACKET. From the beginning, libata has issued reset during
Not true for BIOS. A large sub-section of BIOS (Phoenix and/or
Award-base
Hello,
Linus Torvalds wrote:
> On Fri, 1 Jun 2007, Tejun Heo wrote:
>> Gregor's cdrom has broken SRST support which is extremely rare and
>> broken.
>
> Well, the concept is neither rare nor arguably all that broken.
>
> The paper standards floating around in the industry are so much toilet
>
On Fri, 1 Jun 2007, Tejun Heo wrote:
>
> Gregor's cdrom has broken SRST support which is extremely rare and
> broken.
Well, the concept is neither rare nor arguably all that broken.
The paper standards floating around in the industry are so much toilet
paper. The only standard that seems to r
Hello, Linus. Sorry about late response. I'm still recovering from jet
lag.
Linus Torvalds wrote:
> On Tue, 29 May 2007, Tejun Heo wrote:
>> Aieee, so the drive doesn't like the new SRST sequence.
>
> It would appear that the old code largely ignored the SRST error entirely,
> no?
Yes, we use
On Tue, 29 May 2007, Tejun Heo wrote:
>
> Aieee, so the drive doesn't like the new SRST sequence.
It would appear that the old code largely ignored the SRST error entirely,
no?
If we *used* to do (in ata_bus_post_reset()):
if (dev0)
ata_busy_sleep(ap, ATA_TMOUT_BOOT_Q
2007/5/29, Tejun Heo <[EMAIL PROTECTED]>:
Aieee, so the drive doesn't like the new SRST sequence. Indan pointed
me to your original posting and before the reset sequence update your
drive was reset successfully but only after 30sec delay, right? If you
change the first entry in ata_eh_reset_tim
Hello, Gregor.
Gregor Jasny wrote:
> [ 18.639188] ata_piix :00:07.1: version 2.11
> [ 18.639718] scsi0 : ata_piix
> [ 18.640189] scsi1 : ata_piix
> [ 18.640541] ata1: PATA max UDMA/33 cmd 0x000101f0 ctl 0x000103f6
> bmdma 0x00010860 irq 14
> [ 18.641148] ata2: PATA max UDMA/33 cmd 0x
Jeff Garzik wrote:
Several people have reported LITE-ON LTR-48246S detection failed
because SETXFER fails. It seems the device raises IRQ too early after
SETXFER. This is controller independent. The same problem has been
reported for different controllers.
So, now we have pata_via where the
Hi Tejun,
2007/5/28, Tejun Heo <[EMAIL PROTECTED]>:
I can't find the rest of this thread.
http://lkml.org/lkml/2007/5/27/63
Old report:
http://lkml.org/lkml/2007/3/1/243
Can you post the result of 'dmesg' and 'lspci -nn'?
2.6.22-rc3 dmesg:
[0.00] On node 0 totalpages: 65499
[0.
On Mon, May 28, 2007 at 02:35:12PM +0800, Qi Yong wrote:
> On 26/05/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> >It's Friday evening, and the US is preparing for a long three-day weekend,
> >often considered the official start of summer here.
> >
> >So what's a pasty white nerd to do? You c
Gregor Jasny wrote:
> 2007/5/27, Linus Torvalds <[EMAIL PROTECTED]>:
>> But if it doesn't help for you, you have some other issue (which is not
>> surprising - yours wasn't a SETFXSR error, and I don't think it would
>> have
>> worked very well before either).
>>
>> So since it apparently _did_ wor
On Mon, May 28, 2007 at 02:35:12PM +0800, Qi Yong wrote:
> >Ben Dooks (6):
> > [ARM] 4395/1: S3C24XX: add include of to relevant
> > machines
> > [ARM] 4396/1: S3C2443: Add missing HCLK clocks
> > [ARM] 4397/1: S3C2443: remove SDI0/1 IRQ ambiguity
> > [ARM] 4398/1: S3C244
On 26/05/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
It's Friday evening, and the US is preparing for a long three-day weekend,
often considered the official start of summer here.
So what's a pasty white nerd to do? You can't go out on the beach, because
the goodlooking people will laugh at y
2007/5/27, Linus Torvalds <[EMAIL PROTECTED]>:
But if it doesn't help for you, you have some other issue (which is not
surprising - yours wasn't a SETFXSR error, and I don't think it would have
worked very well before either).
So since it apparently _did_ work for you before, can you bisect it?
On Sun, 27 May 2007, Gregor Jasny wrote:
> 2007/5/27, Jeff Garzik <[EMAIL PROTECTED]>:
> > Does the attached patch fix things?
>
> No it doesn't. Note that I'm using ata_piix.
The commit message for that thing is badly worded. It definitely hits
ata_piix too, and it concerns a lot more than j
2007/5/27, Jeff Garzik <[EMAIL PROTECTED]>:
Does the attached patch fix things?
No it doesn't. Note that I'm using ata_piix.
Gregor
-
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
On 5/26/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
But now you _can_ do something: you can download the latest -rc kernel,
and smile smugly to yourself, knowing that you are running the latest and
greatest on your machine.
Got this only after "recompile". "make clean" will make the warnings
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
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 works as expected. W
It felt slightly lag while switching the firefox's tab compared to the 2.6.20.
-
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:/
On May 25 2007 20:21, Linus Torvalds wrote:
>
>It's Friday evening, and the US is preparing for a long three-day weekend,
>often considered the official start of summer here.
>
>So what's a pasty white nerd to do?
Doing a commit like c420bc9f09a0926b708c3edb27eacba434a4f4ba on Makefile
line 5..
56 matches
Mail list logo
