Re: [PATCH] Re: Linux v2.6.22-rc3
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 body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 apparently the reasong for two of our current regressions, and we need to solve it. "Just wait" is not an option. The options are: - fix things - revert everything that caused the regressions and quite frankly, I don't think the second alternative is palatable to anybody, including you. > The values assist in detecting ghost devices (same device appearing > on both master and slave) and TF register malfunctions, and I would > appreciate not breaking _that_ so late in 2.6.22-rc for a single > report. Thankfully we have -some- ghost device prevention code > elsewhere, but this is part of it. Apparently this isn't even true. As far as I can tell, the old code used to wait for lbal to be 1, but if it never became one, it would just silently time out and not *do* anything about it. Later commands would "just work", and the device would go its merry ways. IOW, the new code is *crap*. The old code was arguably not wonderful either, but because of its nature, the old code not working didn't actually matter all that much. So the biggest change (and the one that broke peoples machines) is that the code that you claim matters, *never* apparently did matter, and now that we've made it matter (by returning an error, and aborting the SRST sequence as a failure), people are complaining. I really think we should apply Tejun's patch. Add a delay there, by all means if you are nervous: but no, it shouldn't be 150ms. This is the _post_ reset handling, we've already done the 150ms wait for the reset! In fact, if you look at ata_bus_post_reset(), you'll notice that for port0, we just do the "ata_wait_ready()" call. Tejun's patch just made us do the same (logical) thing for port1 too! If you think it breaks due to ome timeout issue, then the port0 thing was already broken. (And maybe we could make the ap->ops->dev_select(ap, 1); rc = ata_wait_ready(ap, deadline); instead be a ata_dev_select(ap, 1, 1, 1); and you'd wait even more? But that's actually a bigger change than Tejun's thing, and it uses "ata_wait_idle()" rather than "ata_wait_ready()", and doesn't return any status.. I dunno. But right now, we have several known broken things, that apparently weren't broken before!) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 apparently the reasong for two of our current regressions, and we need to solve it. Just wait is not an option. The options are: - fix things - revert everything that caused the regressions and quite frankly, I don't think the second alternative is palatable to anybody, including you. The values assist in detecting ghost devices (same device appearing on both master and slave) and TF register malfunctions, and I would appreciate not breaking _that_ so late in 2.6.22-rc for a single report. Thankfully we have -some- ghost device prevention code elsewhere, but this is part of it. Apparently this isn't even true. As far as I can tell, the old code used to wait for lbal to be 1, but if it never became one, it would just silently time out and not *do* anything about it. Later commands would just work, and the device would go its merry ways. IOW, the new code is *crap*. The old code was arguably not wonderful either, but because of its nature, the old code not working didn't actually matter all that much. So the biggest change (and the one that broke peoples machines) is that the code that you claim matters, *never* apparently did matter, and now that we've made it matter (by returning an error, and aborting the SRST sequence as a failure), people are complaining. I really think we should apply Tejun's patch. Add a delay there, by all means if you are nervous: but no, it shouldn't be 150ms. This is the _post_ reset handling, we've already done the 150ms wait for the reset! In fact, if you look at ata_bus_post_reset(), you'll notice that for port0, we just do the ata_wait_ready() call. Tejun's patch just made us do the same (logical) thing for port1 too! If you think it breaks due to ome timeout issue, then the port0 thing was already broken. (And maybe we could make the ap-ops-dev_select(ap, 1); rc = ata_wait_ready(ap, deadline); instead be a ata_dev_select(ap, 1, 1, 1); and you'd wait even more? But that's actually a bigger change than Tejun's thing, and it uses ata_wait_idle() rather than ata_wait_ready(), and doesn't return any status.. I dunno. But right now, we have several known broken things, that apparently weren't broken before!) Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
> 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 kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 users, or they all use Fedora and they like filing > bugs 8( Honestly I expected way more bug reports than just that. 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. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
> 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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 also for every command > > > > 400nS and the current code correctly accounts for it. > > No, _far_ longer than 400nS. 2ms minimum by the spec, but, > > ATADRVR. blackmagic.html and googling around shows plenty of ATAPI > devices that don't get their shit together for 50-100ms. 400nS is commands. Reset is indeed about 150mS or so if you catch a drive right - eg in the middle of revalidating a dodgy disk. One or two have really weird behaviour in that they take MUCH longer to come out of reset with no media loaded. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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. No, _far_ longer than 400nS. 2ms minimum by the spec, but, ATADRVR. blackmagic.html and googling around shows plenty of ATAPI devices that don't get their shit together for 50-100ms. The BIOS source I'm reviewing right now waits 50ms, after SRST. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 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 that Tejun's experimental change "fixes them all"? > > > > Proof? Bugzilla URLs pointing to users that have ack'd this fix? > > It unbreaks the IT821x, see the proposed patches I sent before for > discussion. Those are tested and do work. I've got a test case here and > its the case that the IT821x card doesn't get the magic trickery you rely > on right. 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. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
> 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 500ms? That > > can somewhat ease our paranoia and should show acceptable behavior for > > braindead devices too. > > That's quite reasonable. Agreed - means the IT821x takes a bit longer to respond but ensures that we avoid any unpleasant suprises elsewhere. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 being changed then a load of people are stuck with broken ATA. > > So you have verified that Tejun's experimental change "fixes them all"? > > Proof? Bugzilla URLs pointing to users that have ack'd this fix? It unbreaks the IT821x, see the proposed patches I sent before for discussion. Those are tested and do work. I've got a test case here and its the case that the IT821x card doesn't get the magic trickery you rely on right. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 things we can rely upon. 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. > How about limiting nsect/lbal wait duration? Say, 100ms or 500ms? That > can somewhat ease our paranoia and should show acceptable behavior for > braindead devices too. That's quite reasonable. Jeff P.S. We can probably reduce the msleep(150) sprinkled about the code to msleep(100), for the dumb-ATAPI-device wait. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 that Tejun's experimental change "fixes them all"? Proof? Bugzilla URLs pointing to users that have ack'd this fix? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
> 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 with broken ATA. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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. SRST sequence >> looks like the following. > > I've seen no bug where it looked like it saved something, and the only > ghost device bugs I've seen it failed to detect anyway (hence the PCMCIA > drivers own ghost detection logic) If we still have several rc's left, how about just removing it and watching the fireworks? Jeff? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
> 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 like the following. I've seen no bug where it looked like it saved something, and the only ghost device bugs I've seen it failed to detect anyway (hence the PCMCIA drivers own ghost detection logic) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 patch. > >> Tejun, since Jeff is apparently traveling this week, and Gregor tested the >> patch successfully (and it looks sane anyway - why in Gods name _would_ we >> care what the initial setting of nsect/lbal is?), can you send this in >> with the changelog and sign-off? > > 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. Yeap, I'm not so sure about the change either. The posted patch is more of proof-of-concept. Currently we have three related reports. * this one * IT8212 raid mode Alan is working on * (likely) pata_pcmcia http://thread.gmane.org/gmane.linux.kernel/530099 > The values assist in detecting ghost devices (same device appearing > on both master and slave) and TF register malfunctions, and I would > appreciate not breaking _that_ so late in 2.6.22-rc for a single > report. Thankfully we have -some- ghost device prevention code > elsewhere, but this is part of it. 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 like the following. 1. SRST raised, delay, and cleared 2. libata waits for master device readiness after 150ms pause. After finishing reset, if slave is present, master waits for PDIAG- assert. 3. slave asserts PDIAG-, master asserts readiness. libata goes on to check for the slave device nsect/lbal. 4. slave sets nsect/lbal, libata goes on to check readiness 5. slave asserts readiness, SRST complete. So, the nsect/lbal check is meaningful iff 1. slave lies about device readiness after releasing PDIAG- but before setting nsect/lbal, or 2. master/slave register selection is flimsy. 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 things we can rely upon. To me, the second one sounds pretty far fetched too but, well, it's ATA. Who knows? How about limiting nsect/lbal wait duration? Say, 100ms or 500ms? That can somewhat ease our paranoia and should show acceptable behavior for braindead devices too. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 patch. Tejun, since Jeff is apparently traveling this week, and Gregor tested the patch successfully (and it looks sane anyway - why in Gods name _would_ we care what the initial setting of nsect/lbal is?), can you send this in with the changelog and sign-off? 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. Yeap, I'm not so sure about the change either. The posted patch is more of proof-of-concept. Currently we have three related reports. * this one * IT8212 raid mode Alan is working on * (likely) pata_pcmcia http://thread.gmane.org/gmane.linux.kernel/530099 The values assist in detecting ghost devices (same device appearing on both master and slave) and TF register malfunctions, and I would appreciate not breaking _that_ so late in 2.6.22-rc for a single report. Thankfully we have -some- ghost device prevention code elsewhere, but this is part of it. 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 like the following. 1. SRST raised, delay, and cleared 2. libata waits for master device readiness after 150ms pause. After finishing reset, if slave is present, master waits for PDIAG- assert. 3. slave asserts PDIAG-, master asserts readiness. libata goes on to check for the slave device nsect/lbal. 4. slave sets nsect/lbal, libata goes on to check readiness 5. slave asserts readiness, SRST complete. So, the nsect/lbal check is meaningful iff 1. slave lies about device readiness after releasing PDIAG- but before setting nsect/lbal, or 2. master/slave register selection is flimsy. 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 things we can rely upon. To me, the second one sounds pretty far fetched too but, well, it's ATA. Who knows? How about limiting nsect/lbal wait duration? Say, 100ms or 500ms? That can somewhat ease our paranoia and should show acceptable behavior for braindead devices too. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 like the following. I've seen no bug where it looked like it saved something, and the only ghost device bugs I've seen it failed to detect anyway (hence the PCMCIA drivers own ghost detection logic) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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. SRST sequence looks like the following. I've seen no bug where it looked like it saved something, and the only ghost device bugs I've seen it failed to detect anyway (hence the PCMCIA drivers own ghost detection logic) If we still have several rc's left, how about just removing it and watching the fireworks? Jeff? -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 with broken ATA. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 things we can rely upon. 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. How about limiting nsect/lbal wait duration? Say, 100ms or 500ms? That can somewhat ease our paranoia and should show acceptable behavior for braindead devices too. That's quite reasonable. Jeff P.S. We can probably reduce the msleep(150) sprinkled about the code to msleep(100), for the dumb-ATAPI-device wait. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 that Tejun's experimental change fixes them all? Proof? Bugzilla URLs pointing to users that have ack'd this fix? Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 also for every command 400nS and the current code correctly accounts for it. No, _far_ longer than 400nS. 2ms minimum by the spec, but, ATADRVR. blackmagic.html and googling around shows plenty of ATAPI devices that don't get their shit together for 50-100ms. 400nS is commands. Reset is indeed about 150mS or so if you catch a drive right - eg in the middle of revalidating a dodgy disk. One or two have really weird behaviour in that they take MUCH longer to come out of reset with no media loaded. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 kernel. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 users, or they all use Fedora and they like filing bugs 8( Honestly I expected way more bug reports than just that. 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. Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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. No, _far_ longer than 400nS. 2ms minimum by the spec, but, ATADRVR. blackmagic.html and googling around shows plenty of ATAPI devices that don't get their shit together for 50-100ms. The BIOS source I'm reviewing right now waits 50ms, after SRST. Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 being changed then a load of people are stuck with broken ATA. So you have verified that Tejun's experimental change fixes them all? Proof? Bugzilla URLs pointing to users that have ack'd this fix? It unbreaks the IT821x, see the proposed patches I sent before for discussion. Those are tested and do work. I've got a test case here and its the case that the IT821x card doesn't get the magic trickery you rely on right. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 500ms? That can somewhat ease our paranoia and should show acceptable behavior for braindead devices too. That's quite reasonable. Agreed - means the IT821x takes a bit longer to respond but ensures that we avoid any unpleasant suprises elsewhere. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 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 that Tejun's experimental change fixes them all? Proof? Bugzilla URLs pointing to users that have ack'd this fix? It unbreaks the IT821x, see the proposed patches I sent before for discussion. Those are tested and do work. I've got a test case here and its the case that the IT821x card doesn't get the magic trickery you rely on right. 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. Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 apparently traveling this week, and Gregor tested the > patch successfully (and it looks sane anyway - why in Gods name _would_ we > care what the initial setting of nsect/lbal is?), can you send this in > with the changelog and sign-off? 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. The values assist in detecting ghost devices (same device appearing on both master and slave) and TF register malfunctions, and I would appreciate not breaking _that_ so late in 2.6.22-rc for a single report. Thankfully we have -some- ghost device prevention code elsewhere, but this is part of it. Fedora 7 reports are starting to come in, and those will help point us in the right direction too. I'll be home for a bit in 36 hours (->net driver fixes go then) and for good on Tuesday, so I'm hoping you can wait until then. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 patch. > > Tejun, since Jeff is apparently traveling this week, and Gregor tested the > patch successfully (and it looks sane anyway - why in Gods name _would_ we > care what the initial setting of nsect/lbal is?), can you send this in Its a sanity check, and if the vendors could get their chips right a good one, but specs/toilet paper usual story > with the changelog and sign-off? > > Maybe it can go through Andrew like the other patch (the sata_promise > irq/polling handling), but I can take it directly too. Whatever seems > best. I'll certainly ACK it, and it also means I can drop a pending patch to handle the IT8212 raid mode which also gets this wrong. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 successfully (and it looks sane anyway - why in Gods name _would_ we care what the initial setting of nsect/lbal is?), can you send this in with the changelog and sign-off? Maybe it can go through Andrew like the other patch (the sata_promise irq/polling handling), but I can take it directly too. Whatever seems best. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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: version 2.11 [ 307.606268] scsi0 : ata_piix [ 307.606728] scsi1 : ata_piix [ 307.607080] ata1: PATA max UDMA/33 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x00010860 irq 14 [ 307.607790] ata2: PATA max UDMA/33 cmd 0x00010170 ctl 0x00010376 bmdma 0x00010868 irq 15 [0.65] Marking TSC unstable due to: possible TSC halt in C2. [0.65] Time: acpi_pm clocksource has been installed. [0.65] Switched to NOHz mode on CPU #0 [0.70] ata1: ata_bus_post_reset: EXIT3 [0.70] ata1.00: ata_hpa_resize 1: sectors = 78242976, hpa_sectors = 78242976 [0.72] ata1.00: ATA-7: SAMSUNG MP0402H, UC100-14, max UDMA/100 [0.73] ata1.00: 78242976 sectors, multi 8: LBA48 [0.76] ata1.00: ata_hpa_resize 1: sectors = 78242976, hpa_sectors = 78242976 [0.77] ata1.00: configured for UDMA/33 [0.79] ata2: ata_bus_post_reset: EXIT3 [0.97] ata2.00: ATAPI, max UDMA/33 [1.14] ata2.00: configured for UDMA/33 [1.15] scsi 0:0:0:0: Direct-Access ATA SAMSUNG MP0402H UC10 PQ: 0 ANSI: 5 [...] [1.32] scsi 1:0:0:0: CD-ROMSAMSUNG CD-ROM SN-124 N102 PQ: 0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 0x00010860 irq 14
> [ 186.851203] ata2: PATA max UDMA/33 cmd 0x00010170 ctl 0x00010376
> bmdma 0x00010868 irq 15
> [0.65] Marking TSC unstable due to: possible TSC halt in C2.
> [0.65] Time: acpi_pm clocksource has been installed.
> [0.65] Switched to NOHz mode on CPU #0
> [0.65] ata1: ata_bus_post_reset: EXIT3
> [0.70] ata1.00: ata_hpa_resize 1: sectors = 78242976,
> hpa_sectors = 78242976
> [0.72] ata1.00: ATA-7: SAMSUNG MP0402H, UC100-14, max UDMA/100
> [0.73] ata1.00: 78242976 sectors, multi 8: LBA48
> [0.76] ata1.00: ata_hpa_resize 1: sectors = 78242976,
> hpa_sectors = 78242976
> [0.77] ata1.00: configured for UDMA/33
> [1.37] Clocksource tsc unstable (delta = -498091579 ns)
> [ 10.78] ata2: ata_bus_post_reset: EXIT1
> [ 10.813332] ata2: SRST failed (errno=-16)
> [ 20.836664] ata2: ata_bus_post_reset: EXIT1
> [ 20.849997] ata2: SRST failed (errno=-16)
> [ 55.869994] ata2: ata_bus_post_reset: EXIT1
> [ 55.883327] ata2: SRST failed (errno=-16)
> [ 60.903327] ata2: ata_bus_post_reset: EXIT1
> [ 60.916660] ata2: SRST failed (errno=-16)
> [ 60.929993] ata2: reset failed, giving up
> [ 60.946660] scsi 0:0:0:0: Direct-Access ATA SAMSUNG
> MP0402H UC10 PQ: 0 ANSI: 5
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.
Thanks.
--
tejun
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4733f00..bac5e1f 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3042,7 +3042,6 @@ int ata_wait_ready(struct ata_port *ap, unsigned long deadline)
static int ata_bus_post_reset(struct ata_port *ap, unsigned int devmask,
unsigned long deadline)
{
- struct ata_ioports *ioaddr = >ioaddr;
unsigned int dev0 = devmask & (1 << 0);
unsigned int dev1 = devmask & (1 << 1);
int rc, ret = 0;
@@ -3059,22 +3058,9 @@ static int ata_bus_post_reset(struct ata_port *ap, unsigned int devmask,
}
}
- /* if device 1 was found in ata_devchk, wait for
- * register access, then wait for BSY to clear
- */
- while (dev1) {
- u8 nsect, lbal;
-
- ap->ops->dev_select(ap, 1);
- nsect = ioread8(ioaddr->nsect_addr);
- lbal = ioread8(ioaddr->lbal_addr);
- if ((nsect == 1) && (lbal == 1))
- break;
- if (time_after(jiffies, deadline))
- return -EBUSY;
- msleep(50); /* give drive a breather */
- }
+ /* wait for device 1 */
if (dev1) {
+ ap->ops->dev_select(ap, 1);
rc = ata_wait_ready(ap, deadline);
if (rc) {
if (rc != -ENODEV)
Re: [PATCH] Re: Linux v2.6.22-rc3
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] ata2: PATA max UDMA/33 cmd 0x00010170 ctl 0x00010376 bmdma 0x00010868 irq 15 [0.65] Marking TSC unstable due to: possible TSC halt in C2. [0.65] Time: acpi_pm clocksource has been installed. [0.65] Switched to NOHz mode on CPU #0 [0.65] ata1: ata_bus_post_reset: EXIT3 [0.70] ata1.00: ata_hpa_resize 1: sectors = 78242976, hpa_sectors = 78242976 [0.72] ata1.00: ATA-7: SAMSUNG MP0402H, UC100-14, max UDMA/100 [0.73] ata1.00: 78242976 sectors, multi 8: LBA48 [0.76] ata1.00: ata_hpa_resize 1: sectors = 78242976, hpa_sectors = 78242976 [0.77] ata1.00: configured for UDMA/33 [1.37] Clocksource tsc unstable (delta = -498091579 ns) [ 10.78] ata2: ata_bus_post_reset: EXIT1 [ 10.813332] ata2: SRST failed (errno=-16) [ 20.836664] ata2: ata_bus_post_reset: EXIT1 [ 20.849997] ata2: SRST failed (errno=-16) [ 55.869994] ata2: ata_bus_post_reset: EXIT1 [ 55.883327] ata2: SRST failed (errno=-16) [ 60.903327] ata2: ata_bus_post_reset: EXIT1 [ 60.916660] ata2: SRST failed (errno=-16) [ 60.929993] ata2: reset failed, giving up [ 60.946660] scsi 0:0:0:0: Direct-Access ATA SAMSUNG MP0402H UC10 PQ: 0 ANSI: 5 Thanks, 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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] ata2: PATA max UDMA/33 cmd 0x00010170 ctl 0x00010376 bmdma 0x00010868 irq 15 [0.65] Marking TSC unstable due to: possible TSC halt in C2. [0.65] Time: acpi_pm clocksource has been installed. [0.65] Switched to NOHz mode on CPU #0 [0.65] ata1: ata_bus_post_reset: EXIT3 [0.70] ata1.00: ata_hpa_resize 1: sectors = 78242976, hpa_sectors = 78242976 [0.72] ata1.00: ATA-7: SAMSUNG MP0402H, UC100-14, max UDMA/100 [0.73] ata1.00: 78242976 sectors, multi 8: LBA48 [0.76] ata1.00: ata_hpa_resize 1: sectors = 78242976, hpa_sectors = 78242976 [0.77] ata1.00: configured for UDMA/33 [1.37] Clocksource tsc unstable (delta = -498091579 ns) [ 10.78] ata2: ata_bus_post_reset: EXIT1 [ 10.813332] ata2: SRST failed (errno=-16) [ 20.836664] ata2: ata_bus_post_reset: EXIT1 [ 20.849997] ata2: SRST failed (errno=-16) [ 55.869994] ata2: ata_bus_post_reset: EXIT1 [ 55.883327] ata2: SRST failed (errno=-16) [ 60.903327] ata2: ata_bus_post_reset: EXIT1 [ 60.916660] ata2: SRST failed (errno=-16) [ 60.929993] ata2: reset failed, giving up [ 60.946660] scsi 0:0:0:0: Direct-Access ATA SAMSUNG MP0402H UC10 PQ: 0 ANSI: 5 Thanks, 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 0x00010860 irq 14
[ 186.851203] ata2: PATA max UDMA/33 cmd 0x00010170 ctl 0x00010376
bmdma 0x00010868 irq 15
[0.65] Marking TSC unstable due to: possible TSC halt in C2.
[0.65] Time: acpi_pm clocksource has been installed.
[0.65] Switched to NOHz mode on CPU #0
[0.65] ata1: ata_bus_post_reset: EXIT3
[0.70] ata1.00: ata_hpa_resize 1: sectors = 78242976,
hpa_sectors = 78242976
[0.72] ata1.00: ATA-7: SAMSUNG MP0402H, UC100-14, max UDMA/100
[0.73] ata1.00: 78242976 sectors, multi 8: LBA48
[0.76] ata1.00: ata_hpa_resize 1: sectors = 78242976,
hpa_sectors = 78242976
[0.77] ata1.00: configured for UDMA/33
[1.37] Clocksource tsc unstable (delta = -498091579 ns)
[ 10.78] ata2: ata_bus_post_reset: EXIT1
[ 10.813332] ata2: SRST failed (errno=-16)
[ 20.836664] ata2: ata_bus_post_reset: EXIT1
[ 20.849997] ata2: SRST failed (errno=-16)
[ 55.869994] ata2: ata_bus_post_reset: EXIT1
[ 55.883327] ata2: SRST failed (errno=-16)
[ 60.903327] ata2: ata_bus_post_reset: EXIT1
[ 60.916660] ata2: SRST failed (errno=-16)
[ 60.929993] ata2: reset failed, giving up
[ 60.946660] scsi 0:0:0:0: Direct-Access ATA SAMSUNG
MP0402H UC10 PQ: 0 ANSI: 5
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.
Thanks.
--
tejun
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4733f00..bac5e1f 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3042,7 +3042,6 @@ int ata_wait_ready(struct ata_port *ap, unsigned long deadline)
static int ata_bus_post_reset(struct ata_port *ap, unsigned int devmask,
unsigned long deadline)
{
- struct ata_ioports *ioaddr = ap-ioaddr;
unsigned int dev0 = devmask (1 0);
unsigned int dev1 = devmask (1 1);
int rc, ret = 0;
@@ -3059,22 +3058,9 @@ static int ata_bus_post_reset(struct ata_port *ap, unsigned int devmask,
}
}
- /* if device 1 was found in ata_devchk, wait for
- * register access, then wait for BSY to clear
- */
- while (dev1) {
- u8 nsect, lbal;
-
- ap-ops-dev_select(ap, 1);
- nsect = ioread8(ioaddr-nsect_addr);
- lbal = ioread8(ioaddr-lbal_addr);
- if ((nsect == 1) (lbal == 1))
- break;
- if (time_after(jiffies, deadline))
- return -EBUSY;
- msleep(50); /* give drive a breather */
- }
+ /* wait for device 1 */
if (dev1) {
+ ap-ops-dev_select(ap, 1);
rc = ata_wait_ready(ap, deadline);
if (rc) {
if (rc != -ENODEV)
Re: [PATCH] Re: Linux v2.6.22-rc3
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: version 2.11 [ 307.606268] scsi0 : ata_piix [ 307.606728] scsi1 : ata_piix [ 307.607080] ata1: PATA max UDMA/33 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x00010860 irq 14 [ 307.607790] ata2: PATA max UDMA/33 cmd 0x00010170 ctl 0x00010376 bmdma 0x00010868 irq 15 [0.65] Marking TSC unstable due to: possible TSC halt in C2. [0.65] Time: acpi_pm clocksource has been installed. [0.65] Switched to NOHz mode on CPU #0 [0.70] ata1: ata_bus_post_reset: EXIT3 [0.70] ata1.00: ata_hpa_resize 1: sectors = 78242976, hpa_sectors = 78242976 [0.72] ata1.00: ATA-7: SAMSUNG MP0402H, UC100-14, max UDMA/100 [0.73] ata1.00: 78242976 sectors, multi 8: LBA48 [0.76] ata1.00: ata_hpa_resize 1: sectors = 78242976, hpa_sectors = 78242976 [0.77] ata1.00: configured for UDMA/33 [0.79] ata2: ata_bus_post_reset: EXIT3 [0.97] ata2.00: ATAPI, max UDMA/33 [1.14] ata2.00: configured for UDMA/33 [1.15] scsi 0:0:0:0: Direct-Access ATA SAMSUNG MP0402H UC10 PQ: 0 ANSI: 5 [...] [1.32] scsi 1:0:0:0: CD-ROMSAMSUNG CD-ROM SN-124 N102 PQ: 0 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 successfully (and it looks sane anyway - why in Gods name _would_ we care what the initial setting of nsect/lbal is?), can you send this in with the changelog and sign-off? Maybe it can go through Andrew like the other patch (the sata_promise irq/polling handling), but I can take it directly too. Whatever seems best. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 patch. Tejun, since Jeff is apparently traveling this week, and Gregor tested the patch successfully (and it looks sane anyway - why in Gods name _would_ we care what the initial setting of nsect/lbal is?), can you send this in Its a sanity check, and if the vendors could get their chips right a good one, but specs/toilet paper usual story with the changelog and sign-off? Maybe it can go through Andrew like the other patch (the sata_promise irq/polling handling), but I can take it directly too. Whatever seems best. I'll certainly ACK it, and it also means I can drop a pending patch to handle the IT8212 raid mode which also gets this wrong. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 apparently traveling this week, and Gregor tested the patch successfully (and it looks sane anyway - why in Gods name _would_ we care what the initial setting of nsect/lbal is?), can you send this in with the changelog and sign-off? 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. The values assist in detecting ghost devices (same device appearing on both master and slave) and TF register malfunctions, and I would appreciate not breaking _that_ so late in 2.6.22-rc for a single report. Thankfully we have -some- ghost device prevention code elsewhere, but this is part of it. Fedora 7 reports are starting to come in, and those will help point us in the right direction too. I'll be home for a bit in 36 hours (-net driver fixes go then) and for good on Tuesday, so I'm hoping you can wait until then. Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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.
Thanks.
--
tejun
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4733f00..ae6f177 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3053,8 +3053,11 @@ static int ata_bus_post_reset(struct ata_port *ap, unsigned int devmask,
if (dev0) {
rc = ata_wait_ready(ap, deadline);
if (rc) {
- if (rc != -ENODEV)
+ if (rc != -ENODEV) {
+ata_port_printk(ap, KERN_WARNING,
+ "ata_bus_post_reset: EXIT0\n");
return rc;
+ }
ret = rc;
}
}
@@ -3070,15 +3073,21 @@ static int ata_bus_post_reset(struct ata_port *ap, unsigned int devmask,
lbal = ioread8(ioaddr->lbal_addr);
if ((nsect == 1) && (lbal == 1))
break;
- if (time_after(jiffies, deadline))
+ if (time_after(jiffies, deadline)) {
+ ata_port_printk(ap, KERN_WARNING,
+ "ata_bus_post_reset: EXIT1\n");
return -EBUSY;
+ }
msleep(50); /* give drive a breather */
}
if (dev1) {
rc = ata_wait_ready(ap, deadline);
if (rc) {
- if (rc != -ENODEV)
+ if (rc != -ENODEV) {
+ata_port_printk(ap, KERN_WARNING,
+ "ata_bus_post_reset: EXIT2\n");
return rc;
+ }
ret = rc;
}
}
@@ -3090,6 +3099,7 @@ static int ata_bus_post_reset(struct ata_port *ap, unsigned int devmask,
if (dev0)
ap->ops->dev_select(ap, 0);
+ ata_port_printk(ap, KERN_WARNING, "ata_bus_post_reset: EXIT3\n");
return ret;
}
Re: [PATCH] Re: Linux v2.6.22-rc3
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.
Thanks.
--
tejun
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4733f00..ae6f177 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3053,8 +3053,11 @@ static int ata_bus_post_reset(struct ata_port *ap, unsigned int devmask,
if (dev0) {
rc = ata_wait_ready(ap, deadline);
if (rc) {
- if (rc != -ENODEV)
+ if (rc != -ENODEV) {
+ata_port_printk(ap, KERN_WARNING,
+ ata_bus_post_reset: EXIT0\n);
return rc;
+ }
ret = rc;
}
}
@@ -3070,15 +3073,21 @@ static int ata_bus_post_reset(struct ata_port *ap, unsigned int devmask,
lbal = ioread8(ioaddr-lbal_addr);
if ((nsect == 1) (lbal == 1))
break;
- if (time_after(jiffies, deadline))
+ if (time_after(jiffies, deadline)) {
+ ata_port_printk(ap, KERN_WARNING,
+ ata_bus_post_reset: EXIT1\n);
return -EBUSY;
+ }
msleep(50); /* give drive a breather */
}
if (dev1) {
rc = ata_wait_ready(ap, deadline);
if (rc) {
- if (rc != -ENODEV)
+ if (rc != -ENODEV) {
+ata_port_printk(ap, KERN_WARNING,
+ ata_bus_post_reset: EXIT2\n);
return rc;
+ }
ret = rc;
}
}
@@ -3090,6 +3099,7 @@ static int ata_bus_post_reset(struct ata_port *ap, unsigned int devmask,
if (dev0)
ap-ops-dev_select(ap, 0);
+ ata_port_printk(ap, KERN_WARNING, ata_bus_post_reset: EXIT3\n);
return ret;
}
Re: [PATCH] Re: Linux v2.6.22-rc3
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 [ 19.404836] ata1: PATA max UDMA/33 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x00010860 irq 14 [ 19.405443] ata2: PATA max UDMA/33 cmd 0x00010170 ctl 0x00010376 bmdma 0x00010868 irq 15 [0.66] Marking TSC unstable due to: possible TSC halt in C2. [0.66] Time: acpi_pm clocksource has been installed. [0.66] Switched to NOHz mode on CPU #0 [0.71] ata1.00: ata_hpa_resize 1: sectors = 78242976, hpa_sectors = 78242976 [0.71] ata1.00: ATA-7: SAMSUNG MP0402H, UC100-14, max UDMA/100 [0.73] ata1.00: 78242976 sectors, multi 8: LBA48 [0.75] ata1.00: ata_hpa_resize 1: sectors = 78242976, hpa_sectors = 78242976 [0.76] ata1.00: configured for UDMA/33 [1.37] Clocksource tsc unstable (delta = -498119555 ns) [ 10.793332] ata2: SRST failed (errno=-16) [ 20.813331] ata2: SRST failed (errno=-16) [ 55.833327] ata2: SRST failed (errno=-16) [ 60.853327] ata2: SRST failed (errno=-16) [ 60.80] ata2: reset failed, giving up [ 60.879993] scsi 0:0:0:0: Direct-Access ATA SAMSUNG MP0402H UC10 PQ: 0 ANSI: 5 Cheers, 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux v2.6.22-rc3
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 [ 19.404836] ata1: PATA max UDMA/33 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x00010860 irq 14 [ 19.405443] ata2: PATA max UDMA/33 cmd 0x00010170 ctl 0x00010376 bmdma 0x00010868 irq 15 [0.66] Marking TSC unstable due to: possible TSC halt in C2. [0.66] Time: acpi_pm clocksource has been installed. [0.66] Switched to NOHz mode on CPU #0 [0.71] ata1.00: ata_hpa_resize 1: sectors = 78242976, hpa_sectors = 78242976 [0.71] ata1.00: ATA-7: SAMSUNG MP0402H, UC100-14, max UDMA/100 [0.73] ata1.00: 78242976 sectors, multi 8: LBA48 [0.75] ata1.00: ata_hpa_resize 1: sectors = 78242976, hpa_sectors = 78242976 [0.76] ata1.00: configured for UDMA/33 [1.37] Clocksource tsc unstable (delta = -498119555 ns) [ 10.793332] ata2: SRST failed (errno=-16) [ 20.813331] ata2: SRST failed (errno=-16) [ 55.833327] ata2: SRST failed (errno=-16) [ 60.853327] ata2: SRST failed (errno=-16) [ 60.80] ata2: reset failed, giving up [ 60.879993] scsi 0:0:0:0: Direct-Access ATA SAMSUNG MP0402H UC10 PQ: 0 ANSI: 5 Cheers, 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: Linux v2.6.22-rc3
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 works as expected. With 2.6.22-rc3 I've got the
following messages during bootup:
Does this patch change the behavior at all?
Jeff
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 9c07b88..8b58597 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -288,6 +288,7 @@ static const struct ata_port_operations piix_pata_ops = {
.exec_command = ata_exec_command,
.dev_select = ata_std_dev_select,
+ .cable_detect = ata_cable_40wire,
.bmdma_setup= ata_bmdma_setup,
.bmdma_start= ata_bmdma_start,
.bmdma_stop = ata_bmdma_stop,
@@ -300,7 +301,6 @@ static const struct ata_port_operations piix_pata_ops = {
.thaw = ata_bmdma_thaw,
.error_handler = piix_pata_error_handler,
.post_internal_cmd = ata_bmdma_post_internal_cmd,
- .cable_detect = ata_cable_40wire,
.irq_handler= ata_interrupt,
.irq_clear = ata_bmdma_irq_clear,
@@ -322,6 +322,7 @@ static const struct ata_port_operations ich_pata_ops = {
.exec_command = ata_exec_command,
.dev_select = ata_std_dev_select,
+ .cable_detect = ich_pata_cable_detect,
.bmdma_setup= ata_bmdma_setup,
.bmdma_start= ata_bmdma_start,
.bmdma_stop = ata_bmdma_stop,
@@ -334,7 +335,6 @@ static const struct ata_port_operations ich_pata_ops = {
.thaw = ata_bmdma_thaw,
.error_handler = piix_pata_error_handler,
.post_internal_cmd = ata_bmdma_post_internal_cmd,
- .cable_detect = ich_pata_cable_detect,
.irq_handler= ata_interrupt,
.irq_clear = ata_bmdma_irq_clear,
@@ -353,6 +353,7 @@ static const struct ata_port_operations piix_sata_ops = {
.exec_command = ata_exec_command,
.dev_select = ata_std_dev_select,
+ .cable_detect = ata_cable_sata,
.bmdma_setup= ata_bmdma_setup,
.bmdma_start= ata_bmdma_start,
.bmdma_stop = ata_bmdma_stop,
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 3ca9c61..dbd590a 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3035,7 +3035,7 @@ int ata_wait_ready(struct ata_port *ap, unsigned long
deadline)
warned = 1;
}
- msleep(50);
+ msleep(5);
}
}
@@ -3072,7 +3072,7 @@ static int ata_bus_post_reset(struct ata_port *ap,
unsigned int devmask,
break;
if (time_after(jiffies, deadline))
return -EBUSY;
- msleep(50); /* give drive a breather */
+ msleep(5); /* give drive a breather */
}
if (dev1) {
rc = ata_wait_ready(ap, deadline);
@@ -3101,23 +3101,13 @@ static int ata_bus_softreset(struct ata_port *ap,
unsigned int devmask,
DPRINTK("ata%u: bus reset via SRST\n", ap->print_id);
/* software reset. causes dev0 to be selected */
- iowrite8(ap->ctl, ioaddr->ctl_addr);
- udelay(20); /* FIXME: flush */
iowrite8(ap->ctl | ATA_SRST, ioaddr->ctl_addr);
- udelay(20); /* FIXME: flush */
+ ata_pause(ap);
iowrite8(ap->ctl, ioaddr->ctl_addr);
+ ata_pause(ap);
- /* spec mandates ">= 2ms" before checking status.
-* We wait 150ms, because that was the magic delay used for
-* ATAPI devices in Hale Landis's ATADRVR, for the period of time
-* between when the ATA command register is written, and then
-* status is checked. Because waiting for "a while" before
-* checking status is fine, post SRST, we perform this magic
-* delay here as well.
-*
-* Old drivers/ide uses the 2mS rule and then waits for ready
-*/
- msleep(150);
+ /* spec mandates ">= 2ms" before checking status */
+ msleep(2);
/* Before we perform post reset processing we want to see if
* the bus shows 0xFF because the odd clown forgets the D7
@@ -3363,6 +3353,35 @@ int ata_std_prereset(struct ata_port *ap, unsigned long
deadline)
"link for reset (errno=%d)\n", rc);
}
+ return 0;
+}
+
+/**
+ * sata_std_prereset - prepare for reset
+ * @ap: ATA port to be reset
+ * @deadline: deadline jiffies for the operation
+ *
+ *
Re: Linux v2.6.22-rc3
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.stanford.edu/~csapuntz/blackmagic.html#reset >> >> Well, wouldn't it be a good thing to >> 1) if BUSY/DRQ is set even before you try the problem, obviously skip >> the two polite cases, and go to #4 >> 2) try to just do an IDENTIFY 3) if that doesn't work, do a HOST >> RESET and then try again >> 4) if that doesn't work, do the full SRST >> >> (or some variation of the above). > > Skipping reset means it doesn't get the device away from a state that > the previous boot may have configured itself to... standard "I didn't do > reset" problems you see with any hardware. Transfer modes and > removeable media status notification are the most notable that are left > in a semi-random state, but there are many other minor feature bits that > fall into this category as well. libata configures most of the stuff, so I don't think we'll see big surprises even if we skip SRST during probing but I agree that it's nice to give good kicks in the devices' asses during probing. We can try IDENTIFY/IDENTIFY_PACKET with short timeout first and then issue reset if the device isn't in reset blacklist, but it would make probe sequence IDENTIFY -> reset -> IDENTIFY -> configure -> IDENTIFY for reval Which doesn't seem too attractive. We can use the result from the first IDENTIFY for configuration but it's probably a good idea to re-read IDENTIFY page after reset. It would be best if we can handle these braindead SRST-impaired devices in the common code, if that's not feasible, we should at least provide some option to allow correct (without timeout) detection of these devices. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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.stanford.edu/~csapuntz/blackmagic.html#reset Well, wouldn't it be a good thing to 1) if BUSY/DRQ is set even before you try the problem, obviously skip the two polite cases, and go to #4 2) try to just do an IDENTIFY 3) if that doesn't work, do a HOST RESET and then try again 4) if that doesn't work, do the full SRST (or some variation of the above). Skipping reset means it doesn't get the device away from a state that the previous boot may have configured itself to... standard I didn't do reset problems you see with any hardware. Transfer modes and removeable media status notification are the most notable that are left in a semi-random state, but there are many other minor feature bits that fall into this category as well. libata configures most of the stuff, so I don't think we'll see big surprises even if we skip SRST during probing but I agree that it's nice to give good kicks in the devices' asses during probing. We can try IDENTIFY/IDENTIFY_PACKET with short timeout first and then issue reset if the device isn't in reset blacklist, but it would make probe sequence IDENTIFY - reset - IDENTIFY - configure - IDENTIFY for reval Which doesn't seem too attractive. We can use the result from the first IDENTIFY for configuration but it's probably a good idea to re-read IDENTIFY page after reset. It would be best if we can handle these braindead SRST-impaired devices in the common code, if that's not feasible, we should at least provide some option to allow correct (without timeout) detection of these devices. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: Linux v2.6.22-rc3
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 works as expected. With 2.6.22-rc3 I've got the
following messages during bootup:
Does this patch change the behavior at all?
Jeff
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 9c07b88..8b58597 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -288,6 +288,7 @@ static const struct ata_port_operations piix_pata_ops = {
.exec_command = ata_exec_command,
.dev_select = ata_std_dev_select,
+ .cable_detect = ata_cable_40wire,
.bmdma_setup= ata_bmdma_setup,
.bmdma_start= ata_bmdma_start,
.bmdma_stop = ata_bmdma_stop,
@@ -300,7 +301,6 @@ static const struct ata_port_operations piix_pata_ops = {
.thaw = ata_bmdma_thaw,
.error_handler = piix_pata_error_handler,
.post_internal_cmd = ata_bmdma_post_internal_cmd,
- .cable_detect = ata_cable_40wire,
.irq_handler= ata_interrupt,
.irq_clear = ata_bmdma_irq_clear,
@@ -322,6 +322,7 @@ static const struct ata_port_operations ich_pata_ops = {
.exec_command = ata_exec_command,
.dev_select = ata_std_dev_select,
+ .cable_detect = ich_pata_cable_detect,
.bmdma_setup= ata_bmdma_setup,
.bmdma_start= ata_bmdma_start,
.bmdma_stop = ata_bmdma_stop,
@@ -334,7 +335,6 @@ static const struct ata_port_operations ich_pata_ops = {
.thaw = ata_bmdma_thaw,
.error_handler = piix_pata_error_handler,
.post_internal_cmd = ata_bmdma_post_internal_cmd,
- .cable_detect = ich_pata_cable_detect,
.irq_handler= ata_interrupt,
.irq_clear = ata_bmdma_irq_clear,
@@ -353,6 +353,7 @@ static const struct ata_port_operations piix_sata_ops = {
.exec_command = ata_exec_command,
.dev_select = ata_std_dev_select,
+ .cable_detect = ata_cable_sata,
.bmdma_setup= ata_bmdma_setup,
.bmdma_start= ata_bmdma_start,
.bmdma_stop = ata_bmdma_stop,
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 3ca9c61..dbd590a 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3035,7 +3035,7 @@ int ata_wait_ready(struct ata_port *ap, unsigned long
deadline)
warned = 1;
}
- msleep(50);
+ msleep(5);
}
}
@@ -3072,7 +3072,7 @@ static int ata_bus_post_reset(struct ata_port *ap,
unsigned int devmask,
break;
if (time_after(jiffies, deadline))
return -EBUSY;
- msleep(50); /* give drive a breather */
+ msleep(5); /* give drive a breather */
}
if (dev1) {
rc = ata_wait_ready(ap, deadline);
@@ -3101,23 +3101,13 @@ static int ata_bus_softreset(struct ata_port *ap,
unsigned int devmask,
DPRINTK(ata%u: bus reset via SRST\n, ap-print_id);
/* software reset. causes dev0 to be selected */
- iowrite8(ap-ctl, ioaddr-ctl_addr);
- udelay(20); /* FIXME: flush */
iowrite8(ap-ctl | ATA_SRST, ioaddr-ctl_addr);
- udelay(20); /* FIXME: flush */
+ ata_pause(ap);
iowrite8(ap-ctl, ioaddr-ctl_addr);
+ ata_pause(ap);
- /* spec mandates = 2ms before checking status.
-* We wait 150ms, because that was the magic delay used for
-* ATAPI devices in Hale Landis's ATADRVR, for the period of time
-* between when the ATA command register is written, and then
-* status is checked. Because waiting for a while before
-* checking status is fine, post SRST, we perform this magic
-* delay here as well.
-*
-* Old drivers/ide uses the 2mS rule and then waits for ready
-*/
- msleep(150);
+ /* spec mandates = 2ms before checking status */
+ msleep(2);
/* Before we perform post reset processing we want to see if
* the bus shows 0xFF because the odd clown forgets the D7
@@ -3363,6 +3353,35 @@ int ata_std_prereset(struct ata_port *ap, unsigned long
deadline)
link for reset (errno=%d)\n, rc);
}
+ return 0;
+}
+
+/**
+ * sata_std_prereset - prepare for reset
+ * @ap: ATA port to be reset
+ * @deadline: deadline jiffies for the operation
+ *
+ * @ap is about to be
Re: Linux v2.6.22-rc3
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 a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 really nasty bugs that made it into our final kernel (based on 2.6.21.3). For eg, a whole class of Dell laptops won't boot unless you boot with maxcpus=1 I root-caused this to one of tglx's patches that went into 2.6.21.2, but it's a head-scratcher as to why it's responsible. I'm praying that this is the worst of the 'cant install' bugs we get, and then I can just push out a 2.6.22 some time that will magically make all these problems go away. (Because .22 is going to be flawless right?) > (Fedora seems to make it hard on purpose to upgrade between major > revisions, but maybe that's just me not reading the docs as usual ;) Probably :-) I've done two successful upgrades yesterday, one with anaconda, and one using just rpm -U of the fedora-release rpm from F7 and then 'yum update'. (The former did go a little smoother though tbh). Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 good thing to
1) if BUSY/DRQ is set even before you try the problem, obviously skip the
two polite cases, and go to #4
2) try to just do an IDENTIFY
3) if that doesn't work, do a HOST RESET and then try again
4) if that doesn't work, do the full SRST
(or some variation of the above).
Skipping reset means it doesn't get the device away from a state that
the previous boot may have configured itself to... standard "I didn't do
reset" problems you see with any hardware. Transfer modes and
removeable media status notification are the most notable that are left
in a semi-random state, but there are many other minor feature bits that
fall into this category as well.
(Btw, the 150ms wait after reset is really nasty. A few of those, and
we're wasting seconds during bootup. Why the hell does it do that, when
the old driver - and the spec - said 2ms?)
Upon quick review, it appears it should be 110ms. And actually the spec
says 3ms. But to answer your question anyway... :)
The basic libata probe came from the code procedure that is found in a
lot of PC BIOSen, even (IMO) more exposure than Linux: Hale Landis's
ATADRVR. See the attached code sample for the relevant procedure, or
the entire driver source code (PC DOS-style) at
http://www.ata-atapi.com/atadrvr.zip
Upon further review, it looks like the 110ms delay is only per-ATAPI
command, not during reset, as the sub_atapi_delay() calls don't actually
delay before the ATAPI signature has been detected.
I thought the default in Fedora was to use the PATA driver first? If so,
(see davej's reply)
Jeff
//*
//
// reg_config() - Check the host adapter and determine the
//number and type of drives attached.
//
// This process is not documented by any of the ATA standards.
//
// Infomation is returned by this function is in
// reg_config_info[] -- see ATAIO.H.
//
//*
int reg_config( void )
{
int numDev = 0;
unsigned char sc;
unsigned char sn;
unsigned char cl;
unsigned char ch;
unsigned char st;
unsigned char devCtrl;
// setup register values
devCtrl = CB_DC_HD15 | ( int_use_intr_flag ? 0 : CB_DC_NIEN );
// mark start of config in low level trace
trc_llt( 0, 0, TRC_LLT_S_CFG );
// assume there are no devices
reg_config_info[0] = REG_CONFIG_TYPE_NONE;
reg_config_info[1] = REG_CONFIG_TYPE_NONE;
// set up Device Control register
pio_outbyte( CB_DC, devCtrl );
// lets see if there is a device 0
pio_outbyte( CB_DH, CB_DH_DEV0 );
DELAY400NS;
pio_outbyte( CB_SC, 0x55 );
pio_outbyte( CB_SN, 0xaa );
pio_outbyte( CB_SC, 0xaa );
pio_outbyte( CB_SN, 0x55 );
pio_outbyte( CB_SC, 0x55 );
pio_outbyte( CB_SN, 0xaa );
sc = pio_inbyte( CB_SC );
sn = pio_inbyte( CB_SN );
if ( ( sc == 0x55 ) && ( sn == 0xaa ) )
reg_config_info[0] = REG_CONFIG_TYPE_UNKN;
// lets see if there is a device 1
pio_outbyte( CB_DH, CB_DH_DEV1 );
DELAY400NS;
pio_outbyte( CB_SC, 0x55 );
pio_outbyte( CB_SN, 0xaa );
pio_outbyte( CB_SC, 0xaa );
pio_outbyte( CB_SN, 0x55 );
pio_outbyte( CB_SC, 0x55 );
pio_outbyte( CB_SN, 0xaa );
sc = pio_inbyte( CB_SC );
sn = pio_inbyte( CB_SN );
if ( ( sc == 0x55 ) && ( sn == 0xaa ) )
reg_config_info[1] = REG_CONFIG_TYPE_UNKN;
// now we think we know which devices, if any are there,
// so lets try a soft reset (ignoring any errors).
pio_outbyte( CB_DH, CB_DH_DEV0 );
DELAY400NS;
reg_reset( 0, 0 );
// lets check device 0 again, is device 0 really there?
// is it ATA or ATAPI?
pio_outbyte( CB_DH, CB_DH_DEV0 );
DELAY400NS;
sc = pio_inbyte( CB_SC );
sn = pio_inbyte( CB_SN );
if ( ( sc == 0x01 ) && ( sn == 0x01 ) )
{
reg_config_info[0] = REG_CONFIG_TYPE_UNKN;
cl = pio_inbyte( CB_CL );
ch = pio_inbyte( CB_CH );
st = pio_inbyte( CB_STAT );
if ( ( cl == 0x14 ) && ( ch == 0xeb ) )
reg_config_info[0] = REG_CONFIG_TYPE_ATAPI;
else
if ( ( cl == 0x00 ) && ( ch == 0x00 ) && ( st != 0x00 ) )
reg_config_info[0] = REG_CONFIG_TYPE_ATA;
}
// lets check device 1 again, is device 1 really there?
// is it ATA or ATAPI?
pio_outbyte( CB_DH, CB_DH_DEV1 );
DELAY400NS;
sc = pio_inbyte( CB_SC );
sn = pio_inbyte( CB_SN );
if ( ( sc == 0x01 ) && ( sn == 0x01 ) )
{
reg_config_info[1] = REG_CONFIG_TYPE_UNKN;
cl = pio_inbyte( CB_CL );
ch = pio_inbyte( CB_CH );
st = pio_inbyte( CB_STAT );
if ( ( cl == 0x14 ) && ( ch == 0xeb ) )
Re: Linux v2.6.22-rc3
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 that's just me not reading the docs as usual ;) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 this is a trend, it > > warrants careful reconsideration. > > I thought the default in Fedora was to use the PATA driver first? If so, > you're going to miss a lot of cases that "just work", because they use the > old driver. There are no old drivers in F7 and beyond. # CONFIG_IDE is not set Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 1) if BUSY/DRQ is set even before you try the problem, obviously skip the two polite cases, and go to #4 2) try to just do an IDENTIFY 3) if that doesn't work, do a HOST RESET and then try again 4) if that doesn't work, do the full SRST (or some variation of the above). That at least has the potential to get you six working devices, and half a dozen other working devices, for a total of 12. With no unnecessary resets or long timeouts! (Btw, the 150ms wait after reset is really nasty. A few of those, and we're wasting seconds during bootup. Why the hell does it do that, when the old driver - and the spec - said 2ms?) > 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 this is a trend, it > warrants careful reconsideration. I thought the default in Fedora was to use the PATA driver first? If so, you're going to miss a lot of cases that "just work", because they use the old driver. At least that was what my situation was on the P4 that I recently complained about the "set transfer mode" problem: it used to use the old PATA drivers that didn't have the issue, so I never even _knew_ the new libata-based code had problems. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 clearly in that category. * It worked before #reset-seq merge AFAICT, which implies the old method of probing -- which included SRST -- worked. Well, I don't think it really "worked" before. It apparently always had a bad 30-second timeout (probably because the reset just didn't work at all). It's just that the old code didn't care, and since the identify then worked, it was all good. Ah, indeed. I certainly prefer the old result to the new one. 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 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 this is a trend, it warrants careful reconsideration. The current code already has the IDENTIFY retry stuff, so it sounds like restoring the "don't care" part should be enough to restore the older behavior. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 category. > > * It worked before #reset-seq merge AFAICT, which implies the old method of > probing -- which included SRST -- worked. Well, I don't think it really "worked" before. It apparently always had a bad 30-second timeout (probably because the reset just didn't work at all). It's just that the old code didn't care, and since the identify then worked, it was all good. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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-based BIOSen) do SRST along with the Hale Landis device detection (ata_devchk in libata-core.c). Ditto for several ATA vendor BIOS found on the card. 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 category. * It worked before #reset-seq merge AFAICT, which implies the old method of probing -- which included SRST -- worked. * If this was a major problem, I would think there would be a flood of bug reports for Fedora 7 (just released, and in testing w/ #reset-seq for a little while), since it is using libata for PATA as well as SATA. So this, just this one bug report right? I would go back and look at the differences in the low-level register bitbanging, and what specifically changed there. If the old stuff worked, that tends to imply a problem with the new stuff... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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-based BIOSen) do SRST along with the Hale Landis device detection (ata_devchk in libata-core.c). Ditto for several ATA vendor BIOS found on the card. 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 category. * It worked before #reset-seq merge AFAICT, which implies the old method of probing -- which included SRST -- worked. * If this was a major problem, I would think there would be a flood of bug reports for Fedora 7 (just released, and in testing w/ #reset-seq for a little while), since it is using libata for PATA as well as SATA. So this, just this one bug report right? I would go back and look at the differences in the low-level register bitbanging, and what specifically changed there. If the old stuff worked, that tends to imply a problem with the new stuff... Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 category. * It worked before #reset-seq merge AFAICT, which implies the old method of probing -- which included SRST -- worked. Well, I don't think it really worked before. It apparently always had a bad 30-second timeout (probably because the reset just didn't work at all). It's just that the old code didn't care, and since the identify then worked, it was all good. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 clearly in that category. * It worked before #reset-seq merge AFAICT, which implies the old method of probing -- which included SRST -- worked. Well, I don't think it really worked before. It apparently always had a bad 30-second timeout (probably because the reset just didn't work at all). It's just that the old code didn't care, and since the identify then worked, it was all good. reviews thread again Ah, indeed. I certainly prefer the old result to the new one. 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 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 this is a trend, it warrants careful reconsideration. The current code already has the IDENTIFY retry stuff, so it sounds like restoring the don't care part should be enough to restore the older behavior. Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 1) if BUSY/DRQ is set even before you try the problem, obviously skip the two polite cases, and go to #4 2) try to just do an IDENTIFY 3) if that doesn't work, do a HOST RESET and then try again 4) if that doesn't work, do the full SRST (or some variation of the above). That at least has the potential to get you six working devices, and half a dozen other working devices, for a total of 12. With no unnecessary resets or long timeouts! (Btw, the 150ms wait after reset is really nasty. A few of those, and we're wasting seconds during bootup. Why the hell does it do that, when the old driver - and the spec - said 2ms?) 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 this is a trend, it warrants careful reconsideration. I thought the default in Fedora was to use the PATA driver first? If so, you're going to miss a lot of cases that just work, because they use the old driver. At least that was what my situation was on the P4 that I recently complained about the set transfer mode problem: it used to use the old PATA drivers that didn't have the issue, so I never even _knew_ the new libata-based code had problems. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 this is a trend, it warrants careful reconsideration. I thought the default in Fedora was to use the PATA driver first? If so, you're going to miss a lot of cases that just work, because they use the old driver. There are no old drivers in F7 and beyond. # CONFIG_IDE is not set Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 good thing to
1) if BUSY/DRQ is set even before you try the problem, obviously skip the
two polite cases, and go to #4
2) try to just do an IDENTIFY
3) if that doesn't work, do a HOST RESET and then try again
4) if that doesn't work, do the full SRST
(or some variation of the above).
Skipping reset means it doesn't get the device away from a state that
the previous boot may have configured itself to... standard I didn't do
reset problems you see with any hardware. Transfer modes and
removeable media status notification are the most notable that are left
in a semi-random state, but there are many other minor feature bits that
fall into this category as well.
(Btw, the 150ms wait after reset is really nasty. A few of those, and
we're wasting seconds during bootup. Why the hell does it do that, when
the old driver - and the spec - said 2ms?)
Upon quick review, it appears it should be 110ms. And actually the spec
says 3ms. But to answer your question anyway... :)
The basic libata probe came from the code procedure that is found in a
lot of PC BIOSen, even (IMO) more exposure than Linux: Hale Landis's
ATADRVR. See the attached code sample for the relevant procedure, or
the entire driver source code (PC DOS-style) at
http://www.ata-atapi.com/atadrvr.zip
Upon further review, it looks like the 110ms delay is only per-ATAPI
command, not during reset, as the sub_atapi_delay() calls don't actually
delay before the ATAPI signature has been detected.
I thought the default in Fedora was to use the PATA driver first? If so,
grin (see davej's reply)
Jeff
//*
//
// reg_config() - Check the host adapter and determine the
//number and type of drives attached.
//
// This process is not documented by any of the ATA standards.
//
// Infomation is returned by this function is in
// reg_config_info[] -- see ATAIO.H.
//
//*
int reg_config( void )
{
int numDev = 0;
unsigned char sc;
unsigned char sn;
unsigned char cl;
unsigned char ch;
unsigned char st;
unsigned char devCtrl;
// setup register values
devCtrl = CB_DC_HD15 | ( int_use_intr_flag ? 0 : CB_DC_NIEN );
// mark start of config in low level trace
trc_llt( 0, 0, TRC_LLT_S_CFG );
// assume there are no devices
reg_config_info[0] = REG_CONFIG_TYPE_NONE;
reg_config_info[1] = REG_CONFIG_TYPE_NONE;
// set up Device Control register
pio_outbyte( CB_DC, devCtrl );
// lets see if there is a device 0
pio_outbyte( CB_DH, CB_DH_DEV0 );
DELAY400NS;
pio_outbyte( CB_SC, 0x55 );
pio_outbyte( CB_SN, 0xaa );
pio_outbyte( CB_SC, 0xaa );
pio_outbyte( CB_SN, 0x55 );
pio_outbyte( CB_SC, 0x55 );
pio_outbyte( CB_SN, 0xaa );
sc = pio_inbyte( CB_SC );
sn = pio_inbyte( CB_SN );
if ( ( sc == 0x55 ) ( sn == 0xaa ) )
reg_config_info[0] = REG_CONFIG_TYPE_UNKN;
// lets see if there is a device 1
pio_outbyte( CB_DH, CB_DH_DEV1 );
DELAY400NS;
pio_outbyte( CB_SC, 0x55 );
pio_outbyte( CB_SN, 0xaa );
pio_outbyte( CB_SC, 0xaa );
pio_outbyte( CB_SN, 0x55 );
pio_outbyte( CB_SC, 0x55 );
pio_outbyte( CB_SN, 0xaa );
sc = pio_inbyte( CB_SC );
sn = pio_inbyte( CB_SN );
if ( ( sc == 0x55 ) ( sn == 0xaa ) )
reg_config_info[1] = REG_CONFIG_TYPE_UNKN;
// now we think we know which devices, if any are there,
// so lets try a soft reset (ignoring any errors).
pio_outbyte( CB_DH, CB_DH_DEV0 );
DELAY400NS;
reg_reset( 0, 0 );
// lets check device 0 again, is device 0 really there?
// is it ATA or ATAPI?
pio_outbyte( CB_DH, CB_DH_DEV0 );
DELAY400NS;
sc = pio_inbyte( CB_SC );
sn = pio_inbyte( CB_SN );
if ( ( sc == 0x01 ) ( sn == 0x01 ) )
{
reg_config_info[0] = REG_CONFIG_TYPE_UNKN;
cl = pio_inbyte( CB_CL );
ch = pio_inbyte( CB_CH );
st = pio_inbyte( CB_STAT );
if ( ( cl == 0x14 ) ( ch == 0xeb ) )
reg_config_info[0] = REG_CONFIG_TYPE_ATAPI;
else
if ( ( cl == 0x00 ) ( ch == 0x00 ) ( st != 0x00 ) )
reg_config_info[0] = REG_CONFIG_TYPE_ATA;
}
// lets check device 1 again, is device 1 really there?
// is it ATA or ATAPI?
pio_outbyte( CB_DH, CB_DH_DEV1 );
DELAY400NS;
sc = pio_inbyte( CB_SC );
sn = pio_inbyte( CB_SN );
if ( ( sc == 0x01 ) ( sn == 0x01 ) )
{
reg_config_info[1] = REG_CONFIG_TYPE_UNKN;
cl = pio_inbyte( CB_CL );
ch = pio_inbyte( CB_CH );
st = pio_inbyte( CB_STAT );
if ( ( cl == 0x14 ) ( ch == 0xeb ) )
Re: Linux v2.6.22-rc3
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 really nasty bugs that made it into our final kernel (based on 2.6.21.3). For eg, a whole class of Dell laptops won't boot unless you boot with maxcpus=1 I root-caused this to one of tglx's patches that went into 2.6.21.2, but it's a head-scratcher as to why it's responsible. I'm praying that this is the worst of the 'cant install' bugs we get, and then I can just push out a 2.6.22 some time that will magically make all these problems go away. (Because .22 is going to be flawless right?) (Fedora seems to make it hard on purpose to upgrade between major revisions, but maybe that's just me not reading the docs as usual ;) Probably :-) I've done two successful upgrades yesterday, one with anaconda, and one using just rpm -U of the fedora-release rpm from F7 and then 'yum update'. (The former did go a little smoother though tbh). Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 that's just me not reading the docs as usual ;) Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 > paper. The only standard that seems to really matter is what Windows has > traditionally done. We may not like it, but there it is... > > This bites us more when it comes to the real el-cheapo stuff, notably when > it comes to various USB mass storage things (which have some random > USB->flash controller cobbled together by a senile llama on crack), and is > almost unheard of for anythign that is "server-grade", but when it comes > to no-brand random devices, it really does tend to be the case that the > only testing they ever had was using Windows. > > And hardware is seldom any different from software: if it wasn't tested, > it probably doesn't work. Yeap, agreed. SRST on PATA works on most devices tho. This device is the first reported one which genuinely doesn't like SRST itself but we also had a case where a device doesn't report proper diagnostic code and another one which reports incorrect device class code. Hardreset on SATA works better because it's much more integral part of the protocol. SRST also seems to work better but there is an emulated PMP device which craps itself if SRST is issued to it. > So it would be good if somebody knew what the Windows ID/startup sequence > was/is. I think we figured it out by trial-and-error for the USB mass > storage stuff. But it tends to boil down to: don't do things that aren't > absolutely required (for SCSI, it was things like not asking for mode > pages that weren't absolutely required, because some devices wouldn't > support it, and would simply lock up if you did so!) 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 probing. We've had a few problems regarding this but they have been worked around successfully till now. One of the upsides of doing reset during probing is that the reset code path gets tested a lot and libata is more likely to recover properly after error conditions. With SATA, this is getting more important because errors are much more common and happen occasionally even on perfectly healthy machines. As libata gets much wider userbase including old/weird PATA devices, we seem to be facing more of these broken devices. We may be reaching the point where the benefit of doing reset during probing isn't worth the price we have to pay, at least on PATA. Jeff, what do you think? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 really matter is what Windows has traditionally done. We may not like it, but there it is... This bites us more when it comes to the real el-cheapo stuff, notably when it comes to various USB mass storage things (which have some random USB->flash controller cobbled together by a senile llama on crack), and is almost unheard of for anythign that is "server-grade", but when it comes to no-brand random devices, it really does tend to be the case that the only testing they ever had was using Windows. And hardware is seldom any different from software: if it wasn't tested, it probably doesn't work. So it would be good if somebody knew what the Windows ID/startup sequence was/is. I think we figured it out by trial-and-error for the USB mass storage stuff. But it tends to boil down to: don't do things that aren't absolutely required (for SCSI, it was things like not asking for mode pages that weren't absolutely required, because some devices wouldn't support it, and would simply lock up if you did so!) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 used to ignore some error conditions, which sometimes led to
very long timeout sequence after hotplugging under certain circumstances
- a few 30sec timeouts for the reset and another 30sec for the following
IDENTIFY (because reset didn't fail after the timeouts).
> If we *used* to do (in ata_bus_post_reset()):
>
> if (dev0)
> ata_busy_sleep(ap, ATA_TMOUT_BOOT_QUICK, ATA_TMOUT_BOOT);
>
> and you changed that to actually care about the return value:
>
> if (dev0) {
> rc = ata_wait_ready(ap, deadline);
> if (rc && rc != -ENODEV)
> return rc;
> }
>
> (in _two_ places). That change also changed the same "post_reset" handling
> in a totally _different_ way: it used to do ata_busy_sleep() twice, now it
> still does it twice, but it does it with the same "timeout" value, so if
> the first one times out, then the second one won't be given any timeout AT
> ALL!
>
> And to make matters worse: the first timeout seems to be for ANOTHER PORT
> ENTIRELY! So you seem to break port 1 even if the timeout happened on port
> 0, as far as I can read that sequence.
Yes, the whole operation uses single timeout. If the given time runs
out, it fails for both devices on the channel. This is because reset
timeout is channel wide. After SRST, both devices are required to
respond in certain time (30secs max per spec). If anyone of the device
doesn't respond, it isn't clear what we can or can't do with the bus -
reset protocol itself requires responding master, cable detection needs
both devices working, etc...
> So I think your ata_bus_post_reset() changes are rather suspect. The fact
> that you don't change the timeout, and use the same deadline for two
> different ports (and for multiple commands to the same port, afaik), seems
> rather suspect. The old code also didn't care about failures in certain
> phases of the reset sequence, and it appears that it did so for good
> reason.
Gregor's cdrom has broken SRST support which is extremely rare and
broken. The reason why it works flawlessly with the ide driver is
because the ide driver doesn't issue SRST during probing and libata
worked after 30sec timeout before reset-seq change because libata didn't
use to check reset failures in some cases and the device just worked
when issued commands even when it didn't report ready status after reset.
I'll try to add some code in the reset path and see where the device
fails reset protocol. Hopefully, we can work around it. If it doesn't,
maybe we'll need to issue IDENTIFY and see whether that works after
reset timeout. :-(
Thanks.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 used to ignore some error conditions, which sometimes led to
very long timeout sequence after hotplugging under certain circumstances
- a few 30sec timeouts for the reset and another 30sec for the following
IDENTIFY (because reset didn't fail after the timeouts).
If we *used* to do (in ata_bus_post_reset()):
if (dev0)
ata_busy_sleep(ap, ATA_TMOUT_BOOT_QUICK, ATA_TMOUT_BOOT);
and you changed that to actually care about the return value:
if (dev0) {
rc = ata_wait_ready(ap, deadline);
if (rc rc != -ENODEV)
return rc;
}
(in _two_ places). That change also changed the same post_reset handling
in a totally _different_ way: it used to do ata_busy_sleep() twice, now it
still does it twice, but it does it with the same timeout value, so if
the first one times out, then the second one won't be given any timeout AT
ALL!
And to make matters worse: the first timeout seems to be for ANOTHER PORT
ENTIRELY! So you seem to break port 1 even if the timeout happened on port
0, as far as I can read that sequence.
Yes, the whole operation uses single timeout. If the given time runs
out, it fails for both devices on the channel. This is because reset
timeout is channel wide. After SRST, both devices are required to
respond in certain time (30secs max per spec). If anyone of the device
doesn't respond, it isn't clear what we can or can't do with the bus -
reset protocol itself requires responding master, cable detection needs
both devices working, etc...
So I think your ata_bus_post_reset() changes are rather suspect. The fact
that you don't change the timeout, and use the same deadline for two
different ports (and for multiple commands to the same port, afaik), seems
rather suspect. The old code also didn't care about failures in certain
phases of the reset sequence, and it appears that it did so for good
reason.
Gregor's cdrom has broken SRST support which is extremely rare and
broken. The reason why it works flawlessly with the ide driver is
because the ide driver doesn't issue SRST during probing and libata
worked after 30sec timeout before reset-seq change because libata didn't
use to check reset failures in some cases and the device just worked
when issued commands even when it didn't report ready status after reset.
I'll try to add some code in the reset path and see where the device
fails reset protocol. Hopefully, we can work around it. If it doesn't,
maybe we'll need to issue IDENTIFY and see whether that works after
reset timeout. :-(
Thanks.
--
tejun
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 really matter is what Windows has traditionally done. We may not like it, but there it is... This bites us more when it comes to the real el-cheapo stuff, notably when it comes to various USB mass storage things (which have some random USB-flash controller cobbled together by a senile llama on crack), and is almost unheard of for anythign that is server-grade, but when it comes to no-brand random devices, it really does tend to be the case that the only testing they ever had was using Windows. And hardware is seldom any different from software: if it wasn't tested, it probably doesn't work. So it would be good if somebody knew what the Windows ID/startup sequence was/is. I think we figured it out by trial-and-error for the USB mass storage stuff. But it tends to boil down to: don't do things that aren't absolutely required (for SCSI, it was things like not asking for mode pages that weren't absolutely required, because some devices wouldn't support it, and would simply lock up if you did so!) Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 paper. The only standard that seems to really matter is what Windows has traditionally done. We may not like it, but there it is... This bites us more when it comes to the real el-cheapo stuff, notably when it comes to various USB mass storage things (which have some random USB-flash controller cobbled together by a senile llama on crack), and is almost unheard of for anythign that is server-grade, but when it comes to no-brand random devices, it really does tend to be the case that the only testing they ever had was using Windows. And hardware is seldom any different from software: if it wasn't tested, it probably doesn't work. Yeap, agreed. SRST on PATA works on most devices tho. This device is the first reported one which genuinely doesn't like SRST itself but we also had a case where a device doesn't report proper diagnostic code and another one which reports incorrect device class code. Hardreset on SATA works better because it's much more integral part of the protocol. SRST also seems to work better but there is an emulated PMP device which craps itself if SRST is issued to it. So it would be good if somebody knew what the Windows ID/startup sequence was/is. I think we figured it out by trial-and-error for the USB mass storage stuff. But it tends to boil down to: don't do things that aren't absolutely required (for SCSI, it was things like not asking for mode pages that weren't absolutely required, because some devices wouldn't support it, and would simply lock up if you did so!) 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 probing. We've had a few problems regarding this but they have been worked around successfully till now. One of the upsides of doing reset during probing is that the reset code path gets tested a lot and libata is more likely to recover properly after error conditions. With SATA, this is getting more important because errors are much more common and happen occasionally even on perfectly healthy machines. As libata gets much wider userbase including old/weird PATA devices, we seem to be facing more of these broken devices. We may be reaching the point where the benefit of doing reset during probing isn't worth the price we have to pay, at least on PATA. Jeff, what do you think? -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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_QUICK, ATA_TMOUT_BOOT);
and you changed that to actually care about the return value:
if (dev0) {
rc = ata_wait_ready(ap, deadline);
if (rc && rc != -ENODEV)
return rc;
}
(in _two_ places). That change also changed the same "post_reset" handling
in a totally _different_ way: it used to do ata_busy_sleep() twice, now it
still does it twice, but it does it with the same "timeout" value, so if
the first one times out, then the second one won't be given any timeout AT
ALL!
And to make matters worse: the first timeout seems to be for ANOTHER PORT
ENTIRELY! So you seem to break port 1 even if the timeout happened on port
0, as far as I can read that sequence.
So I think your ata_bus_post_reset() changes are rather suspect. The fact
that you don't change the timeout, and use the same deadline for two
different ports (and for multiple commands to the same port, afaik), seems
rather suspect. The old code also didn't care about failures in certain
phases of the reset sequence, and it appears that it did so for good
reason.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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_timeouts[] table at the top of libata-eh.c to 35 * HZ, does it work? No, it even times out after 35 seconds. I've raised the first timeout to 60 seconds but still no success. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 0x00010170 ctl 0x00010376 > bmdma 0x00010868 irq 15 > [0.65] Marking TSC unstable due to: possible TSC halt in C2. > [0.65] Time: acpi_pm clocksource has been installed. > [0.65] Switched to NOHz mode on CPU #0 > [0.77] ata1.00: ata_hpa_resize 1: sectors = 78242976, > hpa_sectors = 78242976 > [0.77] ata1.00: ATA-7: SAMSUNG MP0402H, UC100-14, max UDMA/100 > [0.79] ata1.00: 78242976 sectors, multi 8: LBA48 > [0.81] ata1.00: ata_hpa_resize 1: sectors = 78242976, > hpa_sectors = 78242976 > [0.82] ata1.00: configured for UDMA/33 > [1.37] Clocksource tsc unstable (delta = -496294688 ns) > [ 10.85] ata2: SRST failed (errno=-16) > [ 20.87] ata2: SRST failed (errno=-16) > [ 55.946661] ata2: SRST failed (errno=-16) > [ 60.90] ata2: SRST failed (errno=-16) > [ 60.979993] ata2: reset failed, giving up 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_timeouts[] table at the top of libata-eh.c to 35 * HZ, does it work? Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 0x00010170 ctl 0x00010376 bmdma 0x00010868 irq 15 [0.65] Marking TSC unstable due to: possible TSC halt in C2. [0.65] Time: acpi_pm clocksource has been installed. [0.65] Switched to NOHz mode on CPU #0 [0.77] ata1.00: ata_hpa_resize 1: sectors = 78242976, hpa_sectors = 78242976 [0.77] ata1.00: ATA-7: SAMSUNG MP0402H, UC100-14, max UDMA/100 [0.79] ata1.00: 78242976 sectors, multi 8: LBA48 [0.81] ata1.00: ata_hpa_resize 1: sectors = 78242976, hpa_sectors = 78242976 [0.82] ata1.00: configured for UDMA/33 [1.37] Clocksource tsc unstable (delta = -496294688 ns) [ 10.85] ata2: SRST failed (errno=-16) [ 20.87] ata2: SRST failed (errno=-16) [ 55.946661] ata2: SRST failed (errno=-16) [ 60.90] ata2: SRST failed (errno=-16) [ 60.979993] ata2: reset failed, giving up 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_timeouts[] table at the top of libata-eh.c to 35 * HZ, does it work? Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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_timeouts[] table at the top of libata-eh.c to 35 * HZ, does it work? No, it even times out after 35 seconds. I've raised the first timeout to 60 seconds but still no success. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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_QUICK, ATA_TMOUT_BOOT);
and you changed that to actually care about the return value:
if (dev0) {
rc = ata_wait_ready(ap, deadline);
if (rc rc != -ENODEV)
return rc;
}
(in _two_ places). That change also changed the same post_reset handling
in a totally _different_ way: it used to do ata_busy_sleep() twice, now it
still does it twice, but it does it with the same timeout value, so if
the first one times out, then the second one won't be given any timeout AT
ALL!
And to make matters worse: the first timeout seems to be for ANOTHER PORT
ENTIRELY! So you seem to break port 1 even if the timeout happened on port
0, as far as I can read that sequence.
So I think your ata_bus_post_reset() changes are rather suspect. The fact
that you don't change the timeout, and use the same deadline for two
different ports (and for multiple commands to the same port, afaik), seems
rather suspect. The old code also didn't care about failures in certain
phases of the reset sequence, and it appears that it did so for good
reason.
Linus
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 controller raises IRQ before it's ready after SETXFER and a device which does similar thing. This patch makes libata always execute SETXFER via polling. As this only happens during EH, performance impact is nil. Setting ATA_TFLAG_POLLING is also moved from issue hot path to ata_dev_set_xfermode() - the only place where SETXFER can be issued. Note that ATA_TFLAG_POLLING applies only to drivers which implement SFF TF interface and use libata HSM. More advanced controllers ignore the flag. This doesn't matter for this fix as SFF TF controllers are the problematic ones. Not only kills two birds with a single store, but will avoid having to re-solve the problem at sometime in the future. That's good software! -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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.00] DMA zone: 32 pages used for memmap
[0.00] DMA zone: 0 pages reserved
[0.00] DMA zone: 4064 pages, LIFO batch:0
[0.00] Normal zone: 479 pages used for memmap
[0.00] Normal zone: 60924 pages, LIFO batch:15
[0.00] DMI 2.3 present.
[0.00] ACPI: RSDP 000F4040, 0014 (r0 DELL )
[0.00] ACPI: RSDT 0FFF, 0028 (r1 DELLCPi R 27D2051C
ASL61)
[0.00] ACPI: FACP 0FFF0400, 0074 (r1 DELLCPi R 27D2051C
ASL61)
[0.00] ACPI: DSDT 0FFF0800, 29A6 (r1 INT430 SYSFexxx 1001
MSFT 10D)
[0.00] ACPI: FACS 0800, 0040
[0.00] ACPI: PM-Timer IO Port: 0x808
[0.00] Allocating PCI resources starting at 2000 (gap:
1010:efd0)
[0.00] Built 1 zonelists. Total pages: 64988
[0.00] Kernel command line: root=/dev/sda1 ro vga=0x317 resume=/dev/sda3
[0.00] Enabling fast FPU save and restore... done.
[0.00] Enabling unmasked SIMD FPU exception support... done.
[0.00] Initializing CPU#0
[0.00] PID hash table entries: 1024 (order: 10, 4096 bytes)
[0.00] Detected 497.852 MHz processor.
[ 17.951694] Console: colour dummy device 80x25
[ 17.952386] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 17.953014] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 17.986017] Memory: 256764k/261996k available (1555k kernel code,
4684k reserved, 564k data, 124k init, 0k highmem)
[ 17.986078] virtual kernel memory layout:
[ 17.986083] fixmap : 0x8000 - 0xf000 ( 28 kB)
[ 17.986089] vmalloc : 0xd080 - 0x6000 ( 759 MB)
[ 17.986096] lowmem : 0xc000 - 0xcffdb000 ( 255 MB)
[ 17.986102] .init : 0xc0314000 - 0xc0333000 ( 124 kB)
[ 17.986107] .data : 0xc0284d5d - 0xc0311e94 ( 564 kB)
[ 17.986113] .text : 0xc010 - 0xc0284d5d (1555 kB)
[ 17.986177] Checking if this processor honours the WP bit even in
supervisor mode... Ok.
[ 17.986342] SLUB: Genslabs=23, HWalign=32, Order=0-1, MinObjects=4,
Processors=1, Nodes=1
[ 18.069679] Calibrating delay using timer specific routine.. 996.72
BogoMIPS (lpj=1660367)
[ 18.069779] Mount-cache hash table entries: 512
[ 18.070072] CPU: After generic identify, caps: 0383f9ff
[ 18.070110] CPU: L1 I cache: 16K, L1 D cache: 16K
[ 18.070130] CPU: L2 cache: 256K
[ 18.070145] CPU: After all inits, caps: 0383f9ff
0040
[ 18.070168] Intel machine check architecture supported.
[ 18.070189] Intel machine check reporting enabled on CPU#0.
[ 18.070215] Compat vDSO mapped to e000.
[ 18.070260] CPU: Intel Pentium III (Coppermine) stepping 01
[ 18.070287] Checking 'hlt' instruction... OK.
[ 18.083143] ACPI: Core revision 20070126
[ 18.087856] ACPI: setting ELCR to 0200 (from 0820)
[ 18.090228] NET: Registered protocol family 16
[ 18.090500] ACPI: bus type pci registered
[ 18.094673] PCI: PCI BIOS revision 2.10 entry at 0xfc0ae, last bus=1
[ 18.094693] PCI: Using configuration type 1
[ 18.094708] Setting up standard PCI resources
[ 18.130663] ACPI: Interpreter enabled
[ 18.130700] ACPI: (supports S0 S1 S3 S4 S5)
[ 18.130775] ACPI: Using PIC for interrupt routing
[ 18.168609] ACPI: PCI Root Bridge [PCI0] (:00)
[ 18.168698] PCI: Probing PCI hardware (bus 00)
[ 18.169221] PCI quirk: region 0800-083f claimed by PIIX4 ACPI
[ 18.169246] PCI quirk: region 0840-084f claimed by PIIX4 SMB
[ 18.169267] PIIX4 devres B PIO at 00e0-00e7
[ 18.169284] PIIX4 devres C PIO at 0850-085f
[ 18.169888] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[ 18.170186] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
[ 18.253152] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10
*11 12 14 15)
[ 18.253575] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 9 10
11 12 14 15)
[ 18.253923] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11
12 14 15) *0, disabled.
[ 18.254333] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10
*11 12 14 15)
[ 18.254760] ACPI: Power Resource [PADA] (on)
[ 18.254800] Linux Plug and Play Support v0.97 (c) Adam Belay
[ 18.254842] pnp: PnP ACPI init
[ 18.254880] ACPI: bus type pnp registered
[ 18.324625] pnp: PnP ACPI: found 13 devices
[ 18.324657] ACPI: ACPI bus type pnp unregistered
[ 18.325044] SCSI subsystem initialized
[ 18.325126] libata version 2.21 loaded.
[ 18.325204] PCI: Using ACPI for IRQ routing
[ 18.325225] PCI: If a device doesn't work, try "pci=routeirq". If
it helps, post a report
[ 18.328448]
Re: Linux v2.6.22-rc3
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 can't go out on the beach, because > >the goodlooking people will laugh at you, and kick sand in your face. > > > >I'm not bitter. > > > >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. And suddenly it doesn't even matter that summer > >is coming, because you can just sit in the basement, and close the blinds, > >and bask in the warm light from your LCD, rather than the harsh glare of > >the daystar.. > > > >The geeks with embedded hardware can consider themselves doubly special > >(and not just because your mothers told you you are), because we've got > >updates to ARM, SH and Blackfin. > > > >What more could you possibly want? Some ATA updates? USB suspend problem > >solving? Infiniband? DVB and MMC updates? Network drivers and some fixes > >for silly network problems? Yeah we got them! > > Unfortunately MMC update get compiling breakages. [snip] > > > >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: S3C2443: Fix watchdog IRQ number > > [ARM] 4399/2: S3C2443: Fix SMDK2443 nand timings > > [ARM] 4400/1: S3C24XX: Add high-speed MMC device definition > > CC arch/arm/plat-s3c24xx/devs.o > /home/qiyong/linux/linux-2.6/arch/arm/plat-s3c24xx/devs.c:410: error: > 'S3C2443_PA_HSMMC' undeclared here (not in a function) > /home/qiyong/linux/linux-2.6/arch/arm/plat-s3c24xx/devs.c:411: error: > 'S3C2443_SZ_HSMMC' undeclared here (not in a function) sorry about that, missed a file from the patch that adds this and missed rmk's merge request, patch is in the patch system and should be in as soon as possible. fyi: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=4402/1 -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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_ work for you before, can you bisect it? > > git bisect told me that this is the first bad commit: > commit d4b2bab4f26345ea1803feb23ea92fbe3f6b77bc > Author: Tejun Heo <[EMAIL PROTECTED]> > Date: Fri Feb 2 16:50:52 2007 +0900 > > libata: add deadline support to prereset and reset methods > > I suspected my unstable timing source and booted with acpi=off. Now > the printk timestamps are in sequence but the bug is still there. > > The drive worked flawlessly with the old ide-cd. So what's the > difference between libata and ide-cd? I can't find the rest of this thread. Can you post the result of 'dmesg' and 'lspci -nn'? > Is there a kernel parameter to completely disable probing the cdrom? Nope. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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: S3C2443: Fix watchdog IRQ number > > [ARM] 4399/2: S3C2443: Fix SMDK2443 nand timings > > [ARM] 4400/1: S3C24XX: Add high-speed MMC device definition > > CC arch/arm/plat-s3c24xx/devs.o > /home/qiyong/linux/linux-2.6/arch/arm/plat-s3c24xx/devs.c:410: error: > 'S3C2443_PA_HSMMC' undeclared here (not in a function) > /home/qiyong/linux/linux-2.6/arch/arm/plat-s3c24xx/devs.c:411: error: > 'S3C2443_SZ_HSMMC' undeclared here (not in a function) There's a fix already pending (from a day after -rc3) in my tree. You'll have to wait until the end of the week before I push it to Linus, or alternatively grab it from the patch system. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 you, and kick sand in your face. I'm not bitter. 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. And suddenly it doesn't even matter that summer is coming, because you can just sit in the basement, and close the blinds, and bask in the warm light from your LCD, rather than the harsh glare of the daystar.. The geeks with embedded hardware can consider themselves doubly special (and not just because your mothers told you you are), because we've got updates to ARM, SH and Blackfin. What more could you possibly want? Some ATA updates? USB suspend problem solving? Infiniband? DVB and MMC updates? Network drivers and some fixes for silly network problems? Yeah we got them! Unfortunately MMC update get compiling breakages. So stop worrying about those dangerous ultraviolet rays, and instead get your Vitamin D in the form God (and the pharmaceutical industry) intended: small easily swallowed pills. Beaches are overrated anyway, the sand gets into the laptop fan and soon it won't work. May you have a great summer, Linus 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: S3C2443: Fix watchdog IRQ number [ARM] 4399/2: S3C2443: Fix SMDK2443 nand timings [ARM] 4400/1: S3C24XX: Add high-speed MMC device definition CC arch/arm/plat-s3c24xx/devs.o /home/qiyong/linux/linux-2.6/arch/arm/plat-s3c24xx/devs.c:410: error: 'S3C2443_PA_HSMMC' undeclared here (not in a function) /home/qiyong/linux/linux-2.6/arch/arm/plat-s3c24xx/devs.c:411: error: 'S3C2443_SZ_HSMMC' undeclared here (not in a function) -- Qi Yong - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 you, and kick sand in your face. I'm not bitter. 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. And suddenly it doesn't even matter that summer is coming, because you can just sit in the basement, and close the blinds, and bask in the warm light from your LCD, rather than the harsh glare of the daystar.. The geeks with embedded hardware can consider themselves doubly special (and not just because your mothers told you you are), because we've got updates to ARM, SH and Blackfin. What more could you possibly want? Some ATA updates? USB suspend problem solving? Infiniband? DVB and MMC updates? Network drivers and some fixes for silly network problems? Yeah we got them! Unfortunately MMC update get compiling breakages. So stop worrying about those dangerous ultraviolet rays, and instead get your Vitamin D in the form God (and the pharmaceutical industry) intended: small easily swallowed pills. Beaches are overrated anyway, the sand gets into the laptop fan and soon it won't work. May you have a great summer, Linus Ben Dooks (6): [ARM] 4395/1: S3C24XX: add include of linux/sysdev.h to relevant machines [ARM] 4396/1: S3C2443: Add missing HCLK clocks [ARM] 4397/1: S3C2443: remove SDI0/1 IRQ ambiguity [ARM] 4398/1: S3C2443: Fix watchdog IRQ number [ARM] 4399/2: S3C2443: Fix SMDK2443 nand timings [ARM] 4400/1: S3C24XX: Add high-speed MMC device definition CC arch/arm/plat-s3c24xx/devs.o /home/qiyong/linux/linux-2.6/arch/arm/plat-s3c24xx/devs.c:410: error: 'S3C2443_PA_HSMMC' undeclared here (not in a function) /home/qiyong/linux/linux-2.6/arch/arm/plat-s3c24xx/devs.c:411: error: 'S3C2443_SZ_HSMMC' undeclared here (not in a function) -- Qi Yong - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
On Mon, May 28, 2007 at 02:35:12PM +0800, Qi Yong wrote: Ben Dooks (6): [ARM] 4395/1: S3C24XX: add include of linux/sysdev.h to relevant machines [ARM] 4396/1: S3C2443: Add missing HCLK clocks [ARM] 4397/1: S3C2443: remove SDI0/1 IRQ ambiguity [ARM] 4398/1: S3C2443: Fix watchdog IRQ number [ARM] 4399/2: S3C2443: Fix SMDK2443 nand timings [ARM] 4400/1: S3C24XX: Add high-speed MMC device definition CC arch/arm/plat-s3c24xx/devs.o /home/qiyong/linux/linux-2.6/arch/arm/plat-s3c24xx/devs.c:410: error: 'S3C2443_PA_HSMMC' undeclared here (not in a function) /home/qiyong/linux/linux-2.6/arch/arm/plat-s3c24xx/devs.c:411: error: 'S3C2443_SZ_HSMMC' undeclared here (not in a function) There's a fix already pending (from a day after -rc3) in my tree. You'll have to wait until the end of the week before I push it to Linus, or alternatively grab it from the patch system. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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_ work for you before, can you bisect it? git bisect told me that this is the first bad commit: commit d4b2bab4f26345ea1803feb23ea92fbe3f6b77bc Author: Tejun Heo [EMAIL PROTECTED] Date: Fri Feb 2 16:50:52 2007 +0900 libata: add deadline support to prereset and reset methods I suspected my unstable timing source and booted with acpi=off. Now the printk timestamps are in sequence but the bug is still there. The drive worked flawlessly with the old ide-cd. So what's the difference between libata and ide-cd? I can't find the rest of this thread. Can you post the result of 'dmesg' and 'lspci -nn'? Is there a kernel parameter to completely disable probing the cdrom? Nope. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 can't go out on the beach, because the goodlooking people will laugh at you, and kick sand in your face. I'm not bitter. 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. And suddenly it doesn't even matter that summer is coming, because you can just sit in the basement, and close the blinds, and bask in the warm light from your LCD, rather than the harsh glare of the daystar.. The geeks with embedded hardware can consider themselves doubly special (and not just because your mothers told you you are), because we've got updates to ARM, SH and Blackfin. What more could you possibly want? Some ATA updates? USB suspend problem solving? Infiniband? DVB and MMC updates? Network drivers and some fixes for silly network problems? Yeah we got them! Unfortunately MMC update get compiling breakages. [snip] Ben Dooks (6): [ARM] 4395/1: S3C24XX: add include of linux/sysdev.h to relevant machines [ARM] 4396/1: S3C2443: Add missing HCLK clocks [ARM] 4397/1: S3C2443: remove SDI0/1 IRQ ambiguity [ARM] 4398/1: S3C2443: Fix watchdog IRQ number [ARM] 4399/2: S3C2443: Fix SMDK2443 nand timings [ARM] 4400/1: S3C24XX: Add high-speed MMC device definition CC arch/arm/plat-s3c24xx/devs.o /home/qiyong/linux/linux-2.6/arch/arm/plat-s3c24xx/devs.c:410: error: 'S3C2443_PA_HSMMC' undeclared here (not in a function) /home/qiyong/linux/linux-2.6/arch/arm/plat-s3c24xx/devs.c:411: error: 'S3C2443_SZ_HSMMC' undeclared here (not in a function) sorry about that, missed a file from the patch that adds this and missed rmk's merge request, patch is in the patch system and should be in as soon as possible. fyi: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=4402/1 -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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.00] DMA zone: 32 pages used for memmap
[0.00] DMA zone: 0 pages reserved
[0.00] DMA zone: 4064 pages, LIFO batch:0
[0.00] Normal zone: 479 pages used for memmap
[0.00] Normal zone: 60924 pages, LIFO batch:15
[0.00] DMI 2.3 present.
[0.00] ACPI: RSDP 000F4040, 0014 (r0 DELL )
[0.00] ACPI: RSDT 0FFF, 0028 (r1 DELLCPi R 27D2051C
ASL61)
[0.00] ACPI: FACP 0FFF0400, 0074 (r1 DELLCPi R 27D2051C
ASL61)
[0.00] ACPI: DSDT 0FFF0800, 29A6 (r1 INT430 SYSFexxx 1001
MSFT 10D)
[0.00] ACPI: FACS 0800, 0040
[0.00] ACPI: PM-Timer IO Port: 0x808
[0.00] Allocating PCI resources starting at 2000 (gap:
1010:efd0)
[0.00] Built 1 zonelists. Total pages: 64988
[0.00] Kernel command line: root=/dev/sda1 ro vga=0x317 resume=/dev/sda3
[0.00] Enabling fast FPU save and restore... done.
[0.00] Enabling unmasked SIMD FPU exception support... done.
[0.00] Initializing CPU#0
[0.00] PID hash table entries: 1024 (order: 10, 4096 bytes)
[0.00] Detected 497.852 MHz processor.
[ 17.951694] Console: colour dummy device 80x25
[ 17.952386] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 17.953014] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 17.986017] Memory: 256764k/261996k available (1555k kernel code,
4684k reserved, 564k data, 124k init, 0k highmem)
[ 17.986078] virtual kernel memory layout:
[ 17.986083] fixmap : 0x8000 - 0xf000 ( 28 kB)
[ 17.986089] vmalloc : 0xd080 - 0x6000 ( 759 MB)
[ 17.986096] lowmem : 0xc000 - 0xcffdb000 ( 255 MB)
[ 17.986102] .init : 0xc0314000 - 0xc0333000 ( 124 kB)
[ 17.986107] .data : 0xc0284d5d - 0xc0311e94 ( 564 kB)
[ 17.986113] .text : 0xc010 - 0xc0284d5d (1555 kB)
[ 17.986177] Checking if this processor honours the WP bit even in
supervisor mode... Ok.
[ 17.986342] SLUB: Genslabs=23, HWalign=32, Order=0-1, MinObjects=4,
Processors=1, Nodes=1
[ 18.069679] Calibrating delay using timer specific routine.. 996.72
BogoMIPS (lpj=1660367)
[ 18.069779] Mount-cache hash table entries: 512
[ 18.070072] CPU: After generic identify, caps: 0383f9ff
[ 18.070110] CPU: L1 I cache: 16K, L1 D cache: 16K
[ 18.070130] CPU: L2 cache: 256K
[ 18.070145] CPU: After all inits, caps: 0383f9ff
0040
[ 18.070168] Intel machine check architecture supported.
[ 18.070189] Intel machine check reporting enabled on CPU#0.
[ 18.070215] Compat vDSO mapped to e000.
[ 18.070260] CPU: Intel Pentium III (Coppermine) stepping 01
[ 18.070287] Checking 'hlt' instruction... OK.
[ 18.083143] ACPI: Core revision 20070126
[ 18.087856] ACPI: setting ELCR to 0200 (from 0820)
[ 18.090228] NET: Registered protocol family 16
[ 18.090500] ACPI: bus type pci registered
[ 18.094673] PCI: PCI BIOS revision 2.10 entry at 0xfc0ae, last bus=1
[ 18.094693] PCI: Using configuration type 1
[ 18.094708] Setting up standard PCI resources
[ 18.130663] ACPI: Interpreter enabled
[ 18.130700] ACPI: (supports S0 S1 S3 S4 S5)
[ 18.130775] ACPI: Using PIC for interrupt routing
[ 18.168609] ACPI: PCI Root Bridge [PCI0] (:00)
[ 18.168698] PCI: Probing PCI hardware (bus 00)
[ 18.169221] PCI quirk: region 0800-083f claimed by PIIX4 ACPI
[ 18.169246] PCI quirk: region 0840-084f claimed by PIIX4 SMB
[ 18.169267] PIIX4 devres B PIO at 00e0-00e7
[ 18.169284] PIIX4 devres C PIO at 0850-085f
[ 18.169888] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[ 18.170186] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
[ 18.253152] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10
*11 12 14 15)
[ 18.253575] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 9 10
11 12 14 15)
[ 18.253923] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11
12 14 15) *0, disabled.
[ 18.254333] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10
*11 12 14 15)
[ 18.254760] ACPI: Power Resource [PADA] (on)
[ 18.254800] Linux Plug and Play Support v0.97 (c) Adam Belay
[ 18.254842] pnp: PnP ACPI init
[ 18.254880] ACPI: bus type pnp registered
[ 18.324625] pnp: PnP ACPI: found 13 devices
[ 18.324657] ACPI: ACPI bus type pnp unregistered
[ 18.325044] SCSI subsystem initialized
[ 18.325126] libata version 2.21 loaded.
[ 18.325204] PCI: Using ACPI for IRQ routing
[ 18.325225] PCI: If a device doesn't work, try pci=routeirq. If
it helps, post a report
[ 18.328448] pnp:
Re: Linux v2.6.22-rc3
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 controller raises IRQ before it's ready after SETXFER and a device which does similar thing. This patch makes libata always execute SETXFER via polling. As this only happens during EH, performance impact is nil. Setting ATA_TFLAG_POLLING is also moved from issue hot path to ata_dev_set_xfermode() - the only place where SETXFER can be issued. Note that ATA_TFLAG_POLLING applies only to drivers which implement SFF TF interface and use libata HSM. More advanced controllers ignore the flag. This doesn't matter for this fix as SFF TF controllers are the problematic ones. Not only kills two birds with a single store, but will avoid having to re-solve the problem at sometime in the future. That's good software! -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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? git bisect told me that this is the first bad commit: commit d4b2bab4f26345ea1803feb23ea92fbe3f6b77bc Author: Tejun Heo <[EMAIL PROTECTED]> Date: Fri Feb 2 16:50:52 2007 +0900 libata: add deadline support to prereset and reset methods I suspected my unstable timing source and booted with acpi=off. Now the printk timestamps are in sequence but the bug is still there. The drive worked flawlessly with the old ide-cd. So what's the difference between libata and ide-cd? Is there a kernel parameter to completely disable probing the cdrom? Thanks, 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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 just the LITE-ON CD-ROM drives (ie that patch fixes a bug for me on a PIIX system I have access to, with a TDK drive). 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? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
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 go away. SYSMAP System.map SYSMAP .tmp_System.map MODPOST vmlinux WARNING: arch/i386/kernel/built-in.o(.text+0xa677): Section mismatch: reference to .init.text: (between 'init_intel_cacheinfo' and 'cache_shared_cpu_map_setup') WARNING: arch/i386/kernel/built-in.o(.text+0xb8c0): Section mismatch: reference to .init.text: (between 'mtrr_bp_init' and 'mtrr_ap_init') WARNING: arch/i386/kernel/built-in.o(.text+0xba79): Section mismatch: reference to .init.text: (between 'mtrr_bp_init' and 'mtrr_ap_init') WARNING: arch/i386/kernel/built-in.o(.text+0xba7e): Section mismatch: reference to .init.text: (between 'mtrr_bp_init' and 'mtrr_ap_init') WARNING: arch/i386/kernel/built-in.o(.text+0xc4a0): Section mismatch: reference to .init.text: (between 'get_mtrr_state' and 'mtrr_wrmsr') WARNING: kernel/built-in.o(.text+0x17437): Section mismatch: reference to .init.text: (between 'kthreadd' and 'init_waitqueue_head') AS arch/i386/boot/setup.o LD arch/i386/boot/setup OBJCOPY arch/i386/boot/compressed/vmlinux.bin Thanks, Jeff. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
