Re: sata pci cards in ultra 60 or blade 1000 (Update)

[Robert Johannes]

Hi all,
I have upgraded the Os version on the blade 1000 to FreeBSD 8.0-BETA2.

I am at a cross-road.  I have Two sata controllers that are almost working.

I just recently acquired a SUPERMICRO AOC-SAT2-MV8 64-bit PCI-X133MHz SATA
Controller.  This controller had the same behaviour as the Sil 3512 as
explained in the attached email below from Jul 22, on ___FreeBSD 7.2___ Stable.
Since the upgrade to 8.0-BETA2, I actually get the SuperMicro to see the
attached Hitachi Disk Drive.  The problem is that it doesn't complete the
booting!  It hangs just after printing the details to the SCSI boot/root disk,
see SNIPPET.

BOOT-SNIPPET (truncated):
-------------
gem0: <Sun ERI 10/100 Ethernet> mem 0x100000-0x11ffff at device 5.1 on pci0
miibus0: <MII bus> on gem0
ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
gem0: 2kB RX FIFO, 2kB TX FIFO
gem0: Ethernet address: 00:03:ba:02:b3:db
gem0: [ITHREAD]
pci0: <serial bus, FireWire> at device 5.2 (no driver attached)
pci0: <serial bus, USB> at device 5.3 (no driver attached)
sym0: <875> port 0x300-0x3ff mem 0x124000-0x1240ff,0x126000-0x126fff at device
6.0 on pci0
sym0: No NVRAM, ID 7, Fast-20, SE, parity checking
sym0: [ITHREAD]
sym1: <875> port 0x400-0x4ff mem 0x128000-0x1280ff,0x12a000-0x12afff at device
6.1 on pci0
sym1: No NVRAM, ID 7, Fast-20, SE, parity checking
sym1: [ITHREAD]
pcib1: <Sun Host-PCI bridge> mem
0x40004600000-0x40004617fff,0x40004410000-0x4000441004f,0x7ffec000000
pcib1: Schizo, version 4, IGN 0x8, bus A, 66MHz
Timecounter "pcib1" frequency 150000000 Hz quality 100
pcib1: DVMA map: 0xc0000000 to 0xffffffff
pcib1: [FILTER]
pci1: <OFW PCI bus> on pcib1
pci1: <mass storage, SCSI> at device 4.0 (no driver attached)
atapci0: <Marvell 88SX6081 SATA300 controller> port 0x400-0x4ff mem
0x200000-0x2fffff,0x400000-0x7fff1
atapci0: [ITHREAD]
ata2: <ATA channel 0> on atapci0
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci0
ata3: [ITHREAD]
ata4: <ATA channel 2> on atapci0
ata4: [ITHREAD]
ata5: <ATA channel 3> on atapci0
ata5: [ITHREAD]
ata6: <ATA channel 4> on atapci0
ata6: [ITHREAD]
ata7: <ATA channel 5> on atapci0
ata7: [ITHREAD]
ata8: <ATA channel 6> on atapci0
ata8: [ITHREAD]
ata9: <ATA channel 7> on atapci0
ata9: [ITHREAD]
nexus0: <upa> mem
0x40004480000-0x4000448001f,0x40004706000-0x4000470600f,0x40004708000-0x4000470800f)
schppm0: <Schizo power management> mem 0x40004410050-0x40004410057 on nexus0
nexus0: <syscons> type unknown (no driver attached)
Timecounter "tick" frequency 750000000 Hz quality 1000
Timecounters tick every 1.000 msec
ipfw2 initialized, divert enabled, nat loadable, rule-based forwarding enabled,
default to deny, loggd
ad0: 953869MB <Hitachi HDT721010SLA360 ST6OA31B> at ata7-master SATA300
da0 at sym1 bus 0 target 0 lun 0
da0: <FUJITSU MAS3367NP 5B08> Fixed Direct Access SCSI-3 device
da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit)
da0: Command Queueing enabled
da0: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C)

-------------------------
END-SNIPPET.

Note that ad0, the Hitachi sata disk was never seen in FreeBSD 7.2 stable. Now
it is.  But, we don't go past that last line above in the snippet during boot.
A normal boot, without the Hitachi disk should show these additional lines,
denoted by +++:

da0 at sym1 bus 0 target 0 lun 0
da0: <FUJITSU MAS3367NP 5B08> Fixed Direct Access SCSI-3 device
da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit)
da0: Command Queueing enabled
da0: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C)
+++GEOM: da0: adding VTOC8 information.
+++Trying to mount root from ufs:/dev/da0a
+++No suitable dump device was found.
+++Entropy harvesting: interrupts ethernet point_to_point kickstart.
+++/dev/da0a: FILE SYSTEM CLEAN; SKIPPING CHECKS
+++/dev/da0a: clean, 8098831 free (4663 frags, 1011771 blocks, 0.1%
fragmentation)
+++/dev/da0d: FILE SYSTEM CLEAN; SKIPPING CHECKS
+++/dev/da0d: clean, 7243043 free (3547 frags, 904937 blocks, 0.0%
fragmentation)
+++gem0: link state changed to UP
+++Starting Network: lo0 gem0.
+++add net default: gateway 192.168.x.x
+++Flushed all rules.
+++
+++..................

So, can any body help get this to boot to normal os, and then maybe with
addition tweaks, I can the whole thing working.

The other part of the cross-roads is the Sil 3512 development since my last
email from Jul 22, but I would rather concentrate on the SuperMicro controller:
But, if any body is curious, I now have the Sil 3512 show disks, and I can put
partitions on the disk, and mount it.  It seems if I put light activity on the
disk, It works for a while; light activity being moving files (tar or cp) to
the disk on the Sil 3512 at a rate slower than 5 or 6 MB/s.  If that rate
increases to past 6 or 7 MB/s, then I get a hard lock.  The ata driver detaches
the disk on the Sil 3512, and the only way to regain control is to do a hard
reset/reboot.

Any way, if any body has clues and suggestions on how I should proceed, I would
be quite listening.

Thanks,

robert


> On Wed, 22 Jul 2009, R J wrote:

> Hi all,
> I have both an ultra 60 and a Sun blade 1000.  I have freebsd 7.2 running on
> both seemingly without issue, outside of sata pci.
>
> I have had a promise SATA300 TX4, 66MHZ (4 port version) in the ultra 60 and
> rebuild the kernel to contain the ata driver.  When the system boots, it sees
> the card just fine, but it doesn't see any drives attached to it. I had two
> disks attached (one 40gig fujitsu, and one is a 1TB hitachi), but none of
> them were seen.  I tried powering the drives with a different power supply,
> but they would not be seen by the promise controller.  The drives work fine
> in a pc with linux.
>
> I switched out the promise card, and put a silicon image Sil 3512 in the
> ultra 60, and the two drives were seen.  I was able to lay ufs file system on
> them, and even copied files around, but the system was not stable. I.e, I
> would copy files to the sata hard drives for a few minutes before it would
> hang and remain that way till I did a hard reset.
>
> I then took the Sil 3512 out of the ultra60 and put it in the Sun blade 1000,
> and attached the drives, and, just like the promise card, the sil card is
> seen by freebsd, but the drives are not.  Remember, the drives are seen with
> the same card in the ultra60.  I currently don't have the promise card with
> me to test with the blade, but I would imagine the same thing will happen.
>
> Has any body had success with sata pci cards in any of the ultrasparc pci
> systems?  If so, what cards/chipsets/workarounds?
>
> Other than the 66mhz v 33mhz(with respective 3.3/5 volt) and 32 v 64 bit, is
> there any other thing quirky about the sparc pci busses that would cause this
> sort of behaviour?
>
> Any help appreciated.
>
> Robert
>

_______________________________________________
freebsd-sparc64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@..."

[Marius Strobl]

On Sat, Sep 05, 2009 at 05:50:17PM -0500, R J wrote:

> Hi all,
> I have upgraded the Os version on the blade 1000 to FreeBSD 8.0-BETA2.
>
> I am at a cross-road.  I have Two sata controllers that are almost working.
>
> I just recently acquired a SUPERMICRO AOC-SAT2-MV8 64-bit PCI-X133MHz SATA
> Controller.  This controller had the same behaviour as the Sil 3512 as
> explained in the attached email below from Jul 22, on ___FreeBSD 7.2___
> Stable. Since the upgrade to 8.0-BETA2, I actually get the SuperMicro to
> see the attached Hitachi Disk Drive.  The problem is that it doesn't
> complete the booting!  It hangs just after printing the details to the SCSI
> boot/root disk, see SNIPPET.

<...>

>
> So, can any body help get this to boot to normal os, and then maybe with
> addition tweaks, I can the whole thing working.

At a quick glance, atamarvell(4) is at least missing DMA
synchronisation of the work area and isn't fully endian
clean. You could try whether you get any further with
the following patch:
http://people.freebsd.org/~marius/ata-marvell.c.diff
But again, the fail-safe way to get SATA disks working
on sparc64 would be to use a controller driven by mpt(4)
rather than ata(4) as the latter really has a lot of
problems.

>
> The other part of the cross-roads is the Sil 3512 development since my last
> email from Jul 22, but I would rather concentrate on the SuperMicro
> controller: But, if any body is curious, I now have the Sil 3512 show
> disks, and I can put partitions on the disk, and mount it.  It seems if I
> put light activity on the disk, It works for a while; light activity being
> moving files (tar or cp) to the disk on the Sil 3512 at a rate slower than
> 5 or 6 MB/s.  If that rate increases to past 6 or 7 MB/s, then I get a hard
> lock.  The ata driver detaches the disk on the Sil 3512, and the only way
> to regain control is to do a hard reset/reboot.

You should talk to mav@... about problems with
siis(4).

Marius

_______________________________________________
freebsd-sparc64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@..."

[Robert Johannes]

Marius,

I would like to say that thanks for fixing the ata-marvell driver for the
SuperMicro Sata card on sparc64, atleast the blade 1000.  Your patch has
enabled the card to detect the disk drive and complete booting.  Not only
that, I was able to go all the way and create a new partition on the disk,
newfs it, and mount it.  I was able to copy 1.6gigs of data onto the
partition, and was able to copy data from the partition to another
directory within the same partition at a tune of about 40MB/s.

Before that patch, the system was not able to complete booting.

Out of curiosity, ofcourse, what does the patch do?  Does it basically
disable 64-bit and dma for the driver on sparc64?  This is a PCI-X 133mhz
card.  It would be a dream to get half the band-width as it is in a 66mhz
pci slot.

Thanks,  Robert.

NOTE:

Here's a brief output from stock iostat: note the numbers for ad0.

        tty             ad0              da0            pass0
cpu
  tin  tout  KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in
id
    0    39 31.99 1361 42.52   0.00   0  0.00   0.00   0  0.00   0  0 36  3
61
    0    39 31.99 1372 42.86   0.00   0  0.00   0.00   0  0.00   0  0 38  3
59
    0    39 31.98 1366 42.64   0.00   0  0.00   0.00   0  0.00   0  0 38  3
58
    0    39 31.99 1386 43.29   0.00   0  0.00   0.00   0  0.00   0  0 38  4
58
    0    39 31.99 1403 43.84   0.00   0  0.00   0.00   0  0.00   0  0 38  3
59
    0    39 31.98 1343 41.94   0.00   0  0.00   0.00   0  0.00   0  0 37  3
60
    0    39 31.99 1400 43.73   0.00   0  0.00   0.00   0  0.00   0  0 39  3
58
    0    39 31.99 1359 42.46   0.00   0  0.00   0.00   0  0.00   0  0 38  3
60
    0    39 31.98 1336 41.72   0.00   0  0.00   0.00   0  0.00   0  0 38  3
59
    0    39 31.99 1378 43.05   0.00   0  0.00   0.00   0  0.00   0  0 38  2
60
    0    39 31.99 1369 42.76   0.00   0  0.00   0.00   0  0.00   0  0 39  3
58
    0    39 31.83 1286 39.96  12.50   2  0.02   0.00   0  0.00   0  0 40  3
57
    0    39 31.88 1310 40.77   0.00   0  0.00   0.00   0  0.00   0  0 38  2
59
    0    39 31.95 1262 39.36   0.00   0  0.00   0.00   0  0.00   0  0 45  2
52



On Sun, 6 Sep 2009, Marius Strobl wrote:

> On Sat, Sep 05, 2009 at 05:50:17PM -0500, R J wrote:
>> Hi all,
>> I have upgraded the Os version on the blade 1000 to FreeBSD 8.0-BETA2.
>>
>> I am at a cross-road.  I have Two sata controllers that are almost working.
>>
>> I just recently acquired a SUPERMICRO AOC-SAT2-MV8 64-bit PCI-X133MHz SATA
>> Controller.  This controller had the same behaviour as the Sil 3512 as
>> explained in the attached email below from Jul 22, on ___FreeBSD 7.2___
>> Stable. Since the upgrade to 8.0-BETA2, I actually get the SuperMicro to
>> see the attached Hitachi Disk Drive.  The problem is that it doesn't
>> complete the booting!  It hangs just after printing the details to the SCSI
>> boot/root disk, see SNIPPET.
>
> <...>
>
>>
>> So, can any body help get this to boot to normal os, and then maybe with
>> addition tweaks, I can the whole thing working.
>
> At a quick glance, atamarvell(4) is at least missing DMA
> synchronisation of the work area and isn't fully endian
> clean. You could try whether you get any further with
> the following patch:
> http://people.freebsd.org/~marius/ata-marvell.c.diff
> But again, the fail-safe way to get SATA disks working
> on sparc64 would be to use a controller driven by mpt(4)
> rather than ata(4) as the latter really has a lot of
> problems.
>
>>
>> The other part of the cross-roads is the Sil 3512 development since my last
>> email from Jul 22, but I would rather concentrate on the SuperMicro
>> controller: But, if any body is curious, I now have the Sil 3512 show
>> disks, and I can put partitions on the disk, and mount it.  It seems if I
>> put light activity on the disk, It works for a while; light activity being
>> moving files (tar or cp) to the disk on the Sil 3512 at a rate slower than
>> 5 or 6 MB/s.  If that rate increases to past 6 or 7 MB/s, then I get a hard
>> lock.  The ata driver detaches the disk on the Sil 3512, and the only way
>> to regain control is to do a hard reset/reboot.
>
> You should talk to mav@... about problems with
> siis(4).
>
> Marius
>
> reason=bad sender (\.de)
>
>

_______________________________________________
freebsd-sparc64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@..."

[Marius Strobl]

On Tue, Sep 08, 2009 at 07:30:53PM -0500, R J wrote:

> Marius,
>
> I would like to say that thanks for fixing the ata-marvell driver for the
> SuperMicro Sata card on sparc64, atleast the blade 1000.  Your patch has
> enabled the card to detect the disk drive and complete booting.  Not only
> that, I was able to go all the way and create a new partition on the disk,
> newfs it, and mount it.  I was able to copy 1.6gigs of data onto the
> partition, and was able to copy data from the partition to another
> directory within the same partition at a tune of about 40MB/s.
>
> Before that patch, the system was not able to complete booting.
>
> Out of curiosity, ofcourse, what does the patch do?  Does it basically
> disable 64-bit and dma for the driver on sparc64?

It does no such things, it just fixes some sloppy programming
(see my last email for a description of the problems) which
caused the driver to only have a chance of working on x86 but
AFAICT not on any of the other architectures supported by
FreeBSD.

> This is a PCI-X 133mhz
> card.  It would be a dream to get half the band-width as it is in a 66mhz
> pci slot.
>
> Thanks,  Robert.
>
> NOTE:
>
> Here's a brief output from stock iostat: note the numbers for ad0.
>

I admit that I have no experience with "benchmarking" disk
I/O with iostat(8), however checking with my machines
suggests that 40MB/s actually is an excellent result for
copying data from a disk to itself, I don't get anywhere
near that rate, not even on x86 with SATA300 gear.

Marius

_______________________________________________
freebsd-sparc64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@..."

[Robert Johannes]

Hi Marius,
I've been using the patched driver and have moved more than 500 gigs of
data on the disk drive attached to the ata-marvell controller.

Can you incorporate your patch into the 8.0 BETA and 7.X stable?

It seems a very stable, well-performing driver.  It has worked flawlessly
during the moves of enormous data backup and forth between the built in
fibre-channel drives and the ata-marvell attached Hitachi drive.

I wish I could say the same thing regarding the Sil3512.  I still haven't
been able to go any where with that.

Thanks,

Robert


On Wed, 9 Sep 2009, Marius Strobl wrote:

> On Tue, Sep 08, 2009 at 07:30:53PM -0500, R J wrote:
>> Marius,
>>
>> I would like to say that thanks for fixing the ata-marvell driver for the
>> SuperMicro Sata card on sparc64, atleast the blade 1000.  Your patch has
>> enabled the card to detect the disk drive and complete booting.  Not only
>> that, I was able to go all the way and create a new partition on the disk,
>> newfs it, and mount it.  I was able to copy 1.6gigs of data onto the
>> partition, and was able to copy data from the partition to another
>> directory within the same partition at a tune of about 40MB/s.
>>
>> Before that patch, the system was not able to complete booting.
>>
>> Out of curiosity, ofcourse, what does the patch do?  Does it basically
>> disable 64-bit and dma for the driver on sparc64?
>
> It does no such things, it just fixes some sloppy programming
> (see my last email for a description of the problems) which
> caused the driver to only have a chance of working on x86 but
> AFAICT not on any of the other architectures supported by
> FreeBSD.
>
>> This is a PCI-X 133mhz
>> card.  It would be a dream to get half the band-width as it is in a 66mhz
>> pci slot.
>>
>> Thanks,  Robert.
>>
>> NOTE:
>>
>> Here's a brief output from stock iostat: note the numbers for ad0.
>>
>
> I admit that I have no experience with "benchmarking" disk
> I/O with iostat(8), however checking with my machines
> suggests that 40MB/s actually is an excellent result for
> copying data from a disk to itself, I don't get anywhere
> near that rate, not even on x86 with SATA300 gear.
>
> Marius
>
> reason=bad sender (\.de)
>
>

_______________________________________________
freebsd-sparc64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@..."

[Marius Strobl]

On Wed, Sep 16, 2009 at 03:28:25PM -0500, R J wrote:
> Hi Marius,
> I've been using the patched driver and have moved more than 500 gigs of
> data on the disk drive attached to the ata-marvell controller.
>
> Can you incorporate your patch into the 8.0 BETA and 7.X stable?
>
> It seems a very stable, well-performing driver.  It has worked flawlessly
> during the moves of enormous data backup and forth between the built in
> fibre-channel drives and the ata-marvell attached Hitachi drive.

I've updated the patch at
http://people.freebsd.org/~marius/ata-marvell.c.diff
slighlty based on feedback I got during review. Could
you please give the new version (which has an MD5 hash
of a56305fef5edb1d1510373b7e063aaab) a sanity check?
Some basic transfer should be sufficient to verify
it still works. If no new problem arises I'll commit
the patch to head, stable/8 and stable/7.

>
> I wish I could say the same thing regarding the Sil3512.  I still haven't
> been able to go any where with that.

AFAICT the "old" ata-siliconimage(4) suffers from the
same bugs as ata-marvell(4) does, i.e. isn't endian
clean and misses DMA synchronisation besides 64-bit
DMA being broken, but isn't as straight forward to
fix as ata-marvell(4) is. The new siis(4) doesn't
have these bugs though, so I'd expect it to work fine.
Have you talked to mav@... regarding siis(4)?

Marius
 
_______________________________________________
freebsd-sparc64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@..."

[Robert Johannes]

Just finished copying around a terabyte of data through a couple of disks
attached to ata-marvell with the new patch without issue.

So, it looks good to me.

I haven't gotten in touch with mav@... yet regarding the siis
driver.  I will as soon as I am done with the ata-marvell testing.

Robert


On Fri, 18 Sep 2009, Marius Strobl wrote:

> On Wed, Sep 16, 2009 at 03:28:25PM -0500, R J wrote:
>> Hi Marius,
>> I've been using the patched driver and have moved more than 500 gigs of
>> data on the disk drive attached to the ata-marvell controller.
>>
>> Can you incorporate your patch into the 8.0 BETA and 7.X stable?
>>
>> It seems a very stable, well-performing driver.  It has worked flawlessly
>> during the moves of enormous data backup and forth between the built in
>> fibre-channel drives and the ata-marvell attached Hitachi drive.
>
> I've updated the patch at
> http://people.freebsd.org/~marius/ata-marvell.c.diff
> slighlty based on feedback I got during review. Could
> you please give the new version (which has an MD5 hash
> of a56305fef5edb1d1510373b7e063aaab) a sanity check?
> Some basic transfer should be sufficient to verify
> it still works. If no new problem arises I'll commit
> the patch to head, stable/8 and stable/7.
>
>>
>> I wish I could say the same thing regarding the Sil3512.  I still haven't
>> been able to go any where with that.
>
> AFAICT the "old" ata-siliconimage(4) suffers from the
> same bugs as ata-marvell(4) does, i.e. isn't endian
> clean and misses DMA synchronisation besides 64-bit
> DMA being broken, but isn't as straight forward to
> fix as ata-marvell(4) is. The new siis(4) doesn't
> have these bugs though, so I'd expect it to work fine.
> Have you talked to mav@... regarding siis(4)?
>
> Marius
>
> reason=bad sender (\.de)
>
>

_______________________________________________
freebsd-sparc64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@..."

[Marius Strobl]

On Sat, Sep 19, 2009 at 09:38:20PM -0500, R J wrote:
> Just finished copying around a terabyte of data through a couple of disks
> attached to ata-marvell with the new patch without issue.
>
> So, it looks good to me.

Thanks, I've commited it to head and will try to get it into
stable/8 in time for RC2 as well as stable/7.

Marius

_______________________________________________
freebsd-sparc64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@..."

[Robert Johannes]

Hi Marius,
Did you ever get a chance to commit this patch to stable/8 and stable/7 ?

Robert

On Tue, 22 Sep 2009, Marius Strobl wrote:

> On Sat, Sep 19, 2009 at 09:38:20PM -0500, R J wrote:
>> Just finished copying around a terabyte of data through a couple of disks
>> attached to ata-marvell with the new patch without issue.
>>
>> So, it looks good to me.
>
> Thanks, I've commited it to head and will try to get it into
> stable/8 in time for RC2 as well as stable/7.
>
> Marius
>
> reason=bad sender (\.de)
>
>

_______________________________________________
freebsd-sparc64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@..."

[Marius Strobl]

On Thu, Oct 01, 2009 at 01:46:11PM -0500, R J wrote:
> Hi Marius,
> Did you ever get a chance to commit this patch to stable/8 and stable/7 ?

Yes, it was committed as r197488 and r197489 respectively.

Marius

_______________________________________________
freebsd-sparc64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@..."