Re: Remaining SATA (and other) issues TAKE 2

Le Sunday 11 November 2007, Søren Schmidt a écrit :
> Hi All
>
> Alexander found the bug causing the data to be offset wrongly in my last
> patch, this new one should fix that so we dont get disappearing nodes
> etc, sorry about that :)
>
> Please apply to clean releng_7 sources.
>
> Let me know how it turns out.
>
> -Søren

Hello Søren,

I'm glad to report initial good results from the TAKE 2 patch :
on a machine with an older "Promise PDC40518 SATA150" controller, I have 
installed a kernel built from a patched, recent RELENG_7 source tree 
(userland is from BETA1 iso image).

the kernel boots correctly and finds the connected disks :
ad6: 238475MB <Seagate ST3250823AS 3.03> at ata3-master SATA150
ad8: 238475MB <Seagate ST3250823AS 3.03> at ata4-master SATA150
ad10: 238475MB <Seagate ST3250823AS 3.03> at ata5-master SATA150
# mount -r -a
# mount
/dev/ad10s3a on / (ufs, local, read-only)
devfs on /dev (devfs, local)
/dev/ad10s3e on /tmp (ufs, local, read-only)
/dev/ad10s3d on /var (ufs, local, read-only)
/dev/ad10s3f on /usr (ufs, local, read-only)
# uname -a
FreeBSD  7.0-BETA2 FreeBSD 7.0-BETA2 #3: Sun Nov 11 14:24:35 UTC 2007     
XXX_at_YYY:/usr/obj/usr/src/sys/GENERIC  i386

a simple dd completes correctly :

# dd if=/dev/ad10s3e of=/dev/null bs=1M
512+0 records in
512+0 records out
536870912 bytes transferred in 7.685747 secs (69852794 bytes/sec)
# find /usr -name "*tes*"
/usr/bin/ztest
/usr/include/machine/privatespace.h
....
# dump -0cf - /usr | wc -c
  DUMP: Date of this level 0 dump: Sun Nov 11 17:08:35 2007
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/ad10s3f (/usr) to standard output
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 120690 tape blocks.
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: DUMP: 121428 tape blocks
  DUMP: finished in 23 seconds, throughput 5279 KBytes/sec
  DUMP: DUMP IS DONE
 124334080

	Thanks

	TfH