Hello,

> let's check nothing gets distorted. But it seems it gets so, check the
> bottom of the message.
Apparently nothing got distorted - the flags all end up where they belong. 

> > - the kernel doesn't see the 2nd bandit.
> maybe nothing is in there ? I remember quite clearly that when I had to
> get the string location of the video board to write in the Nvram I saw
> both bandits.
Maybe, but it should find the 2nd bandit, tell us, and then probe for devices on the attached PCI bus.

> Hey, the output is very nice. The kernel seems to IGNORE the flags and
> negotiate anyway
Exactly.

> probe(mesh0:0:1:0): max sync rate 10.00Mb/s
This message appears when mesh gets a MSG_EXT_SDTR message, apparently the answer to a sync negotiation request. This leaves the question who sent it - mesh_identify() didn't, I added a printf() where it would request sync negotiation, it didn't appear in the dmesg output.
Question to the audience: could it be that the IBM firmware tries to set up synchronous transfers on its own, when asked to identify itself? This would explain it since the driver (almost) certainly didn't request it. It doesn't seem too likely though - I had an IBM drive in my S900 for a while ( a 4.5GB DCAS ) - no problems.
On the other hand - the mesh driver obviously has some sort of support for synchronous transfers - what exactly is wrong with it? Is there any good mesh documentation anywhere? ( I'll poke around on apple.com later but maybe someone has a direct pointer ).
What do you think is easier - getting synchronous mode to work or adding a quick hack to reject the message above and always use asynchronous transfers? ( say... options MESH_NO_SYNC_EVER ) Well, obviously the hack is easier, but fixing mesh would be the better option - so, how hard would it be?

have fun
Michael