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 rev 1.93 due to an issue > with a NULL pointer dereference on some systems and no one bothered > to go back and fix it. I brought over the fix for this issue from > NetBSD. This needs testing on any IDE/SATA controllers.
FWIW, I tried this patch together with the workaround and a printf added to acer_do_reset on my Blade 150. I'm seeing that - acer_do_reset is beeing called - there are still read errors just after the resets: Jan 23 23:16:12 gilda /bsd: acer_do_reset Jan 23 23:16:13 gilda /bsd: wd0a: DMA error reading fsbn 14097936 of 14097936-14097967 (wd0 bn 14097936; cn 3455 tn 6 sn 6), retrying Jan 23 23:16:13 gilda /bsd: wd0: soft error (corrected) Jan 24 01:30:30 gilda /bsd: acer_do_reset Jan 24 01:30:31 gilda /bsd: wd0a: DMA error reading fsbn 10239004 of 10239004-10239035 (wd0 bn 10239004; cn 2509 tn 8 sn 244), retrying Jan 24 01:30:31 gilda /bsd: wd0: soft error (corrected) Jan 24 01:30:35 gilda /bsd: acer_do_reset Jan 24 01:30:37 gilda /bsd: wd0a: DMA error reading fsbn 10366820 of 10366820-10366851 (wd0 bn 10366820; cn 2540 tn 14 sn 50), retrying Jan 24 01:30:37 gilda /bsd: wd0: soft error (corrected) As far as I'm concerned, I'd stick to UDMA2 for this stupid controller rather than wasting more time on this. -- Matthieu Herrb
