On 14 January 2011 09:11, Mark Kettenis <mark.kette...@xs4all.nl> wrote: >> Date: Fri, 14 Jan 2011 09:00:09 +0100 >> From: Matthieu Herrb <matthieu.he...@laas.fr> >> >> 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 chipset is found in some sparc64 systems such as the Blade 100 and >> > Netra X1. >> > >> > I don't have any such systems but I went digging for this being curious >> > why the nasty hack was added to the kernel configs to disable UltraDMA >> > to workaround this bug and thus penalizing other IDE/SATA controllers >> > that could be in the same system. If you have one of the mentioned >> > systems please test this. >> > >> >> My Blade 150 which has this controller seems to survive a make build >> with this. > > 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. > >
Even so, can't we force udma 2 for that chipset only ? considering the fix in pciide isn't enough. Thing is I ran into this problem with a sili 3114 (pciide) in an ultra 5, had to manually change the wd flags to get past UDMA2.
