Hello,

After this information about sync negotiation and HD and some memories
about some jumpers I checked more thoroughly.

I opened the case and looked for the jumper... 

I have an Ultrastar XP drive, at the time a quite high-end drive. (So
crippling its sync transfers is a bad idea anyway). The specifications
are here:

http://www.hitachigst.com/hdd/support/dfhs/dfhstek.htm
note the quite good transfer rate it should have :)

pin 15-16 should set master or slave sync. I assumed that the host
interface is master ! so I always left the jumper out and this seemed to
work fine on mac and linux.

(jumer 10-11 is enabled, so it auto-starts. thus the message "drive is
offline" is unjustified. And, anywaym OF already loaded the kernel from
that drive...

Now I tried to put it in, thus enabling master sync (? I hope, it is
often difficult to understand what is on and  off..)

I still get:
sd0 at scsibus1 target 0 lun 0: <QUANTUM, FIREBALL SE4.3S, PJ0A> disk
fixed
sd0: 4110 MB, 7637 cyl, 4 head, 275 sec, 512 bytes/sect x 8418816
sectors
probe(mesh0:0:1:0): max sync rate 10.00Mb/s
sd1 at scsibus1 target 1 lun 0: <IBM OEM, DFHSS4F, 4141> disk fixed
sd1: drive offline


now, this is unreasonable. Apart that disabling sync is only a quick fix
:) Having sync transfers would be best.


ah, to whom was concerned about the two PCI bridges. OF didn't see it !
dev / ls showed only one pci. I cleaned pram, reset the OF parameters
and now I see it both from OF as from the kernel. But at the next
reboot... it seems to be gone again. I really suspect that OF disables
unused PCI things ?

I hope to have more news on this sync problem :)

-Riccardo