On Sun, Jan 23, 2011 at 04:27:15PM -0500, Brad wrote:
>
> Ok with a bit more digging I think I found out why the workaround
> is not functioning correctly. I found in rev 1.90 of wdc.c jsg@
> added the infrastructure to allow for the reset callback but
> then part of it was reverted by miod@ in re
On Wed, Jan 12, 2011 at 08:32:12PM -0500, Brad wrote:
> The following diff is ported from NetBSD (the workaround originated from
> OpenSolaris) to workaround the issue of data corruption with the ALI M5229
> IDE chipset when using UltraDMA. Same workaround is also used by
> FreeBSD/Linux.
> This c
On Thursday 20 January 2011 20:22:52 Ted Unangst wrote:
> I know miod suggested the ifdef, but is there any benefit? Is there
> any reason to believe whatever this bug is doesn't affect the same
> silicon on i386? (Or that the same rev is different silicon?) On the
> flipside, besides being a li
On Thu, Jan 20, 2011 at 7:57 PM, Brad wrote:
> Here is the alternate workaround for the time being.
> +#ifdef __sparc64__
> + else if (rev == 0xC3)
> + sc->sc_wdcdev.UDMA_cap = 2;
> +#endif
I know miod suggested the ifdef, but is there any bene
On Wed, Jan 12, 2011 at 08:32:12PM -0500, Brad wrote:
> The following diff is ported from NetBSD (the workaround originated from
> OpenSolaris) to workaround the issue of data corruption with the ALI M5229
> IDE chipset when using UltraDMA. Same workaround is also used by
> FreeBSD/Linux.
> This c
On Sunday 16 January 2011 16:44:47 Mark Kettenis wrote:
> > Date: Sun, 16 Jan 2011 18:18:19 +0100
> > From: Matthieu Herrb
> >
> > I redid a make build with just that. It finished ok without errors.
> >
> > *but* I noticed about a dozen of error like this one during the build,
> > concerning rando
> Earlier in this thread somebody suggested to restrict the pciide
> downgrade to Ultra-DMA mode 2 to just the broken Acer Labs controller.
> That is actually really easy to do. The big question is whether we
> want to do this just on sparc64 (and add an ugly #ifdef __sparc64__ in
> otherwise MI c
> Date: Sun, 16 Jan 2011 18:18:19 +0100
> From: Matthieu Herrb
>
> I redid a make build with just that. It finished ok without errors.
>
> *but* I noticed about a dozen of error like this one during the build,
> concerning random block numbers:
>
> wd0a: DMA error reading fsbn 12543712 of 125
On Sat, Jan 15, 2011 at 12:17:54PM +0100, Mark Kettenis wrote:
> > Date: Fri, 14 Jan 2011 18:56:07 +0100
> > From: Alexander Schrijver
> >
> > > The big question of course is whether it will survive a make build
> > > with the change that removes the restriction of only using Ultra-DMA
> > > up t
> Date: Fri, 14 Jan 2011 18:56:07 +0100
> From: Alexander Schrijver
>
> > The big question of course is whether it will survive a make build
> > with the change that removes the restriction of only using Ultra-DMA
> > up to mode 2, but without the fixes in pciide.c.
> >
> > Beware, that might ac
> The big question of course is whether it will survive a make build
> with the change that removes the restriction of only using Ultra-DMA
> up to mode 2, but without the fixes in pciide.c.
>
> Beware, that might actually eat your filesystem.
>
I'm doing this right now. I'm running a make build
On 14 January 2011 09:11, Mark Kettenis wrote:
>> Date: Fri, 14 Jan 2011 09:00:09 +0100
>> From: Matthieu Herrb
>>
>> On Wed, Jan 12, 2011 at 08:32:12PM -0500, Brad wrote:
>> > The following diff is ported from NetBSD (the workaround originated from
>> > OpenSolaris) to workaround the issue of da
> Date: Fri, 14 Jan 2011 09:00:09 +0100
> From: Matthieu Herrb
>
> On Wed, Jan 12, 2011 at 08:32:12PM -0500, Brad wrote:
> > The following diff is ported from NetBSD (the workaround originated from
> > OpenSolaris) to workaround the issue of data corruption with the ALI M5229
> > IDE chipset when
On Wed, Jan 12, 2011 at 08:32:12PM -0500, Brad wrote:
> The following diff is ported from NetBSD (the workaround originated from
> OpenSolaris) to workaround the issue of data corruption with the ALI M5229
> IDE chipset when using UltraDMA. Same workaround is also used by
> FreeBSD/Linux.
> This c
The reset callback to wdc was added for this, but it didn't help
some systems with the problem so the pciide bits never went in.
If someone has a system that is known to need the workaround
this can certaintly be looked into again though.
On Wed, Jan 12, 2011 at 08:32:12PM -0500, Brad wrote:
> Th
On Thu, Jan 13, 2011 at 09:02:26AM +0100, Jasper Lievisse Adriaanse wrote:
> On Wed, Jan 12, 2011 at 08:32:12PM -0500, Brad wrote:
> > The following diff is ported from NetBSD (the workaround originated from
> > OpenSolaris) to workaround the issue of data corruption with the ALI M5229
> > IDE chip
On Wed, Jan 12, 2011 at 08:32:12PM -0500, Brad wrote:
> The following diff is ported from NetBSD (the workaround originated from
> OpenSolaris) to workaround the issue of data corruption with the ALI M5229
> IDE chipset when using UltraDMA. Same workaround is also used by
> FreeBSD/Linux.
> This c
The following diff is ported from NetBSD (the workaround originated from
OpenSolaris) to workaround the issue of data corruption with the ALI M5229
IDE chipset when using UltraDMA. Same workaround is also used by FreeBSD/Linux.
This chipset is found in some sparc64 systems such as the Blade 100 and
18 matches
Mail list logo
