Messages in this thread | | | Date | Mon, 03 Jun 2002 12:11:29 -0600 | From | kwijibo@zianet ... | Subject | Re: Serverworks OSB4 in impossible state. |
| |
I had this same problem and I posted to the list a couple of weeks ago but it never got any response. The only thing I have on the IDE is a CDROM, rest is SCSI. I could mount the CD drive with no problem but once I tried to read any data from it I would get the 'impossible state' error. I can reproduce this at any time, I don't know how the Serverworks people can't. Just have them go buy a Dell PowerEdge 1650 and use the CDROM. This was with 2.4.18. I found a work around for it however. I just turned off DMA and it worked fine again. I guess it is turned on by default. DMA turned off on a hard drive could suck though, not sure what you could do.
Steven
Alan Cox wrote:
>On Mon, 2002-06-03 at 18:40, Steven Timm wrote: > > >>Serverworks OSB4 in impossible state. >>Disable UDMA or if you are using Seagate then try switching disk types >>on this controller. Please report this event to osb4-bug@ide.cabal.tm >>OSB4: continuing might cause disk corruption. >> >>This is the only one of 60 machines thus configured that has >>had the error thus far. >> >>Two points: >>1) The E-mail address in that kernel debug message doesn't exist. >>E-mail bounces back from it. >> >> > >Oops I'll go fix that small detail. It should have been forwarded to me. > > > >>2) What is causing the hang and are there any hopes to >>fix it in software this time? Last year when I came to the kernel >>list with problems very similar, the consensus was that this >>is actually broken hardware in the OSB4 chipset...but obviously >>it is possible for at least some kernels to run quasi-normally >>on this hardware... what changed between 2.4.9 and 2.4.18 so >>it doesn't anymore? >> >> > >The code traps out when it sees the I/O complete and it turns out that >the DMA engine flags say the engine is still running. In this state we >kill the box because we know the next I/O will be written 4 bytes skewed >with the last 4 bytes of the previous I/O apparently repeated at the >start. > >I took it up with the Serverworks guys at the time, but they were not >able to duplicate the problem and provide advice. Since we could verify >this across an entire rendering farm it was clearly not a weird one off >bug. It also doesn't appear to be a Linux bug (but maybe one day I'll be >proved wrong). > >If you drop the drives to MWDMA2 you'll see only slightly lower >performance and solid behaviour > >Alan > >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > > > >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |