Am Don, 2002-08-22 um 09.52 schrieb Gonzalo Servat:
> Do you have any suggestions on how I can work around this problem? It's
> been driving me nuts all day! (I bet it's driven people nuts for
> weeks...). Do you think your patch (as posted on
> http://linux-kernel.skylab.org/20020609/msg00935.html) may help my
> situation? If so, what kernel does it apply to? I looked up
> serverworks.c in a 2.4.19-rc3 tree to see if the patch would apply
> cleanly but it won't because line 547 is different to yours.
It should be fairly easy to adapt the patch, all you need is modify
the line
if(inb(dma_base+0x02)&1)
in svwks_dmaproc() to the more complex condition test in the patch.
Alan, I understood you to wanted apply this patch - what happened to it,
do you want me to resubmit it?
Martin
--
Martin Wilck Phone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1 mailto:[email protected]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
The problem is we need a special DMA engine for this broken puppy.
I am trying to remember the rule for forming the dma-table, and it is not
nice. The 4 byte issues is a direct result of building the SG which is
not compatable to the hardware.
508 + 4 is okay but 510 + 2 is not.
Now I have to remember why :-/
IIRC, we have to have 4 byte boundaries on the list.
This is where I need some extra help and doing something like the trm290
but for all of OSB4 because parsing out the broken engine bases on asic
revisions is darn near impossible.
Big Problem -- Big Hammer.
Tough if it tanks some of the performance, but it is better than the
deadlocks we are getting now.
Yeah I expect to take heat for this one from ServerWorks and it may cost
me later, but nobody else has got the guts to press the issue for the
correct solution.
Then again if we solve this correctly I have "ends justify means"
argument.
Cheers,
On 22 Aug 2002, Martin Wilck wrote:
> Am Don, 2002-08-22 um 09.52 schrieb Gonzalo Servat:
>
> > Do you have any suggestions on how I can work around this problem? It's
> > been driving me nuts all day! (I bet it's driven people nuts for
> > weeks...). Do you think your patch (as posted on
> > http://linux-kernel.skylab.org/20020609/msg00935.html) may help my
> > situation? If so, what kernel does it apply to? I looked up
> > serverworks.c in a 2.4.19-rc3 tree to see if the patch would apply
> > cleanly but it won't because line 547 is different to yours.
>
> It should be fairly easy to adapt the patch, all you need is modify
> the line
> if(inb(dma_base+0x02)&1)
>
> in svwks_dmaproc() to the more complex condition test in the patch.
>
> Alan, I understood you to wanted apply this patch - what happened to it,
> do you want me to resubmit it?
>
> Martin
>
> --
> Martin Wilck Phone: +49 5251 8 15113
> Fujitsu Siemens Computers Fax: +49 5251 8 20409
> Heinz-Nixdorf-Ring 1 mailto:[email protected]
> D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
>
>
>
>
>
> -
> 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/
>
Andre Hedrick
LAD Storage Consulting Group
Am Don, 2002-08-22 um 10.51 schrieb Andre Hedrick:
> The problem is we need a special DMA engine for this broken puppy.
You certainly have much more insight into the problem than I.
I wonder if (something like) the simple patch I submitted before can
be a temporary solution nevertheless. Please correct me if one of the
following statements is wrong:
1) The "4 byte shift" issue does not affect the CSB5 series.
2) The tested condition inb(dma_base+0x02)&1 is valid if the
device doing the DMA reported an error status. Only if the
device reports success is there an indication of the "4 byte shift".
3) The "4 byte shift" problem matters not for read-only devices like
CD-ROMS; at least it is no reason to stall the computer if it occurs
because data corruption is not an issue.
If these assertions are true, the patch I sent will at least prevent
people's machines from stalling unnecessarily. Even if one ore more are
false, the remaining correct condition test(s) will narrow the set
of machines that are stalled unnecessarily.
> 508 + 4 is okay but 510 + 2 is not.
>
> Now I have to remember why :-/
You sure have to go for the right solution.
But if my patch was applied, ServerWorks chip sets would cause less
grief to people until you have figured it out.
> Yeah I expect to take heat for this one from ServerWorks and it may cost
> me later, but nobody else has got the guts to press the issue for the
> correct solution.
Let me know if we can help. I have no personal contacts to ServerWorks,
but we are a large customer of them and may be able to exert some
additional pressure. The current situation (IDE DMA must be disabled)
is hardly acceptable for us anyway.
Martin
--
Martin Wilck Phone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1 mailto:[email protected]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
> > Yeah I expect to take heat for this one from ServerWorks and it may cost
> > me later, but nobody else has got the guts to press the issue for the
> > correct solution.
>
> Let me know if we can help. I have no personal contacts to ServerWorks,
> but we are a large customer of them and may be able to exert some
> additional pressure. The current situation (IDE DMA must be disabled)
> is hardly acceptable for us anyway.
AFAIK 2.4.18 as well as 2.4.19-preEARLY seemed to work flawlessly w/ OSB4
even in DMA modes. How's the code there then? Is it dangerous to use?
T.
It took sometime figure this out with the ASIC architect.
Since there is not an easy way to determine which of the extremely early
SB's had the issue, it is suggested to hit it with a hammer on the DMA
table building.
On Thu, 22 Aug 2002, Tomas Szepe wrote:
> > > Yeah I expect to take heat for this one from ServerWorks and it may cost
> > > me later, but nobody else has got the guts to press the issue for the
> > > correct solution.
> >
> > Let me know if we can help. I have no personal contacts to ServerWorks,
> > but we are a large customer of them and may be able to exert some
> > additional pressure. The current situation (IDE DMA must be disabled)
> > is hardly acceptable for us anyway.
>
> AFAIK 2.4.18 as well as 2.4.19-preEARLY seemed to work flawlessly w/ OSB4
> even in DMA modes. How's the code there then? Is it dangerous to use?
>
> T.
>
Andre Hedrick
LAD Storage Consulting Group
On Thu, 2002-08-22 at 13:02, Martin Wilck wrote:
> 1) The "4 byte shift" issue does not affect the CSB5 series.
True (not a rule the -ac tree knows about right now) but one that the
next tree will subject to time constraints.
> 2) The tested condition inb(dma_base+0x02)&1 is valid if the
> device doing the DMA reported an error status. Only if the
> device reports success is there an indication of the "4 byte shift".
True
> 3) The "4 byte shift" problem matters not for read-only devices like
> CD-ROMS; at least it is no reason to stall the computer if it occurs
> because data corruption is not an issue.
True (-ac knows about this)
On Thu, 2002-08-22 at 17:45, Tomas Szepe wrote:
> AFAIK 2.4.18 as well as 2.4.19-preEARLY seemed to work flawlessly w/ OSB4
> even in DMA modes. How's the code there then? Is it dangerous to use?
Most of them work all the time (most OSB4, all CSB5. all CSB6)
All of them work all the time with most drives
Some of them do horrible things in UDMA with some drives (timing
patterns I guess)
All of the OSB4 do MWDMA fine.
> > AFAIK 2.4.18 as well as 2.4.19-preEARLY seemed to work flawlessly w/ OSB4
> > even in DMA modes. How's the code there then? Is it dangerous to use?
>
> Most of them work all the time (most OSB4, all CSB5. all CSB6)
> All of them work all the time with most drives
> Some of them do horrible things in UDMA with some drives (timing
> patterns I guess)
>
> All of the OSB4 do MWDMA fine.
Oh it's not such a big problem then. If it tells you/Andre anything,
the controller I've run into trouble with seems to be (output from
2.4.19-pre2):
00:0f.1 IDE interface: Relience Computer: Unknown device 0211 (prog-if 8a [Master SecP PriP])
Flags: bus master, medium devsel, latency 64
I/O ports at 1880 [size=16]
00: 66 11 11 02 45 01 00 02 00 8a 01 01 00 40 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 81 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ServerWorks OSB4: IDE controller on PCI bus 00 dev 79
ServerWorks OSB4: chipset revision 0
(This is what they put into the HP NetServer E800, which is otherwise a nice
machine -- With these we can get up to 8 NICs to work w/o IRQ sharing. Ideal
for building routers, except if we were to put SCSI drives everywhere, we'd
have nothing to eat soon enough.)
So far we've been ok as 2.4.19-pre2 indeed appears to work just fine in UDMA2.
T.
Am Don, 2002-08-22 um 19.58 schrieb Alan Cox:
> > 2) The tested condition inb(dma_base+0x02)&1 is valid if the
> > device doing the DMA reported an error status. Only if the
> > device reports success is there an indication of the "4 byte shift".
>
> True
This condition is easy to test, right? My patch tested for
OK_STAT (GET_STAT(), DRIVE_READY, BAD_STAT)
Why not put that in the code?
Martin
--
Martin Wilck Phone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1 mailto:[email protected]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy