Os 3.1.4 - List of bug fixes and changes by component

[chris]

So... was the long-existing (possibly never worked) GadTools image menu (IM_ITEM) bug fixed?

http://forum.hyperion-entertainment.biz/viewtopic.php?f=26&t=94

Although that's an OS4 thread I'm pretty sure I tested it on OS3 and it didn't work there either. It would be nice to see this fixed in 3.1.4 especially as the fixes used in OS4 should be available.

[kolla]

Shell v46.10 is rather broken, as FailAt no longer works, as reported on the mostly dysfunctional official support forum:
http://forum.hyperion-entertainment.biz/viewtopic.php?f=15&t=4156&p=46099#p46099

I am tempted to think this is not even a bug, but a "feature" to make sure "most users" systems boot, regardless of FailAt levels in Startup-Sequence ...

[kolla]

From FAQ...

* I read something about a setting called "Max Transfer", which is a
  value which I need to manually adjust according to my system. How do I
  set it up?

We decided to make things simpler for you, with AmigaOS 3.1.4 you
don't need to touch this setting for the built-in scsi.device. No
guarantees for third-party firmware, of course.

Still, I apparently need to set it for built-in scsi.device.

[guest11527]

No, does not. The scsi.device knows itself how many sectors it can transmit in one go.

[utri007]

No, does not. The scsi.device knows itself how many sectors it can transmit in one go.

Thanks. Kolla's FUD was availlabe only 24 minits. He seems to have hurry to be importan, so he can't check facts.

[kolla]

Yeah yeah whatever, as long as code is eventually fixed, what do I care about accusations and name calling. Maybe the problem is that I (unlike the development team?) have actual Amiga hardware to perform tests and real life installations on.

When can users expect bugfixes for 3.1.4, and how? Through Hyperion? Through Aminet? What is the functional support channel for OS 3.1.4? Here? a1k? Certainly not Hyperion's forum, though specified in the FAQ.

[kolla]

The scsi.device knows itself how many sectors it can transmit in one go.

So the scsi.device 45.7 that comes with the A600 kickstart has a certain maxtransfer value hardcoded, and does under no circumstances use values configured by HDToolBox?

[guest11527]

Shell v46.10 is rather broken.

It is not "rather broken". It is simply a bug. Such things happen. There is another bug with pipes which we did not spot.

[guest11527]

So the scsi.device 45.7 that comes with the A600 kickstart has a certain maxtransfer value hardcoded, and does under no circumstances use values configured by HDToolBox?

No, Kolla. You cannot, possibly, by any means, transmit more than 255 sectors in a row by the PIO IDE protocol. It is the protocol that has this value "hardcoded". Previous versions of the scsi.device falsely assumed that the limit was 256 blocks, not 255 blocks. This was, actually, true in some previous versions of the protocol which used the sector count 0 to indicate 256 sectors, but that is no longer true as the IDE protocol changed "under the feed of the scsi.device". The scsi.device was not adapted for this protocol change. If the scsi.device (in its IDE implementation) receives the request to transmit more than 255 blocks in a row, it *has* to break them up, but this transfer split happens transparent to its user, and it has to happen exactly this way.

There are similar limitations for SCSI in the number of sectors that can be read at once, but they are not quite as draconian as in the IDE protocol.

It is neither the scsi.device that looks at MaxTransfer. It is the file system, typically the FFS, to implement that. Previous versions of CrossDos and CDFS also simply ignored this value (as part of more defects), and I do not know for other file systems whether they handle this correct, but the FFS does.

[kolla]

It is neither the scsi.device that looks at MaxTransfer. It is the file system, typically the FFS, to implement that. Previous versions of CrossDos and CDFS also simply ignored this value (as part of more defects), and I do not know for other file systems whether they handle this correct, but the FFS does.

Right - FFS in general, or FFS v45? The quote from the FAQ pretty much says "built-in" scsi.device solves _all_ maxtransfer issues, regardless.
Is it correct? Only for the "real" A600 and A1200 Gayle controller? Should it perhaps say that it may depend on hardware and filesystem? Are there situations with scsi.device v45 where MaxTransfer values should be adjusted?

[kolla]

It is not "rather broken". It is simply a bug. Such things happen. There is another bug with pipes which we did not spot.

Arguing about semantics doesn't fix anything, if you have systems relying on correct failat handling, then the result is "broken".
Since the pipes in v46 shell is largely new, different and incompatible with previous pipe handling, I have not even looked at it beyond simple interactive use.

The question is though... will bugs be fixed and do one rely on Hyperion for distribution of fixes? Will you post updates on aminet?

Or will people have to wait for Gulliwhatshisname to release unofficial boingbags again? :p

[guest11527]

Since the pipes in v46 shell is largely new, different and incompatible with previous pipe handling, I have not even looked at it beyond simple interactive use.

No, nothing is different. They work exactly alike existing pipe commands. Except that such commands had to second-guess the shell-syntax, which was certainly not an easy attempt, and - in fact - failed in multiple cases.

The question is though... will bugs be fixed and do one rely on Hyperion for distribution of fixes? Will you post updates on aminet?

It is fixed. When and how the fix will be available I do not know since it is not my decision.

Or will people have to wait for Gulliwhatshisname to release unofficial boingbags again? :p

How should I know that? This is not my decision.

You just complain, just like you ever only complained, without actually ever doing anything productive. I just wonder why I ever answer your posts...

[NinjaCyborg]

Please ignore him Thomas. I only joined this board a month ago and already I can tell he's a moron.

Please continue to post your insider's knowhow. As an OS internals geek I crave your insights.

[guest11527]

Right - FFS in general, or FFS v45?

Any file system is obliged to implement MaxTransfer, a workaround that unfortunately became necessary due to many broken devices. FFS has it since day 1, that is, since it became available as part of v34. In fact, MaxTransfer was introduced with FFS as it was found that this workaround (along with Mask and BuffMemType) became necessary as the FFS was the first file system that implemented "burst transfers" bypassing any file system buffer.

The quote from the FAQ pretty much says "built-in" scsi.device solves _all_ maxtransfer issues, regardless.
Is it correct?

Yes, this is correct.

Should it perhaps say that it may depend on hardware and filesystem?

No, it should not. As this is not related to the file system. The *file system* implements MaxTransfer. But the new scsi.device does not require MaxTransfer. It knows itself how many blocks it can transfer in a row, and it knows itself how to break up the transfer in case a single PATA command is not sufficient for that.

MaxTransfer is just a workaround that became available with FFS to work around issues when devices *do not know* how much data they can transfer in one go, or are not sufficiently smart enough to break up transfers themselves. The scsi.device was always designed well enough to break up transfers, just that the point at which the transfer was broken up was computed incorrectly, due to a change in the specs that happened after the scsi.device was released.

Whether all PATA devices (or, as PATA is a dying species) all PATA-to-something adapters implement the block count correctly in their implementation is a question I cannot answer.

[Pgovotsos]

@Thomas so is it even necessary to have the maxtransfer field available? If it's not necessary for the user to change it shouldn't the field to edit it just be removed?

We've been trained over the years to diddle with maxtransfer for various devices. If it is handled automatically now, if a user doesn't read the documentation before using (I know, I know, but that's another discussion), wouldn't having it available for them to diddle with just cause problems?

I guess the questions that need answering to make it clear follow. Are there ANY circumstances with 3.1.4 that maxtransfer should be edited? Is it the case that whatever is entered is ignored since it is handled automatically now by Kickstart / devices?

[Gulliver]

@Thomas so is it even necessary to have the maxtransfer field available? If it's not necessary for the user to change it shouldn't the field to edit it just be removed?

We've been trained over the years to diddle with maxtransfer for various devices. If it is handled automatically now, if a user doesn't read the documentation before using (I know, I know, but that's another discussion), wouldn't having it available for them to diddle with just cause problems?

I guess the questions that need answering to make it clear follow. Are there ANY circumstances with 3.1.4 that maxtransfer should be edited? Is it the case that whatever is entered is ignored since it is handled automatically now by Kickstart / devices?

MaxTransfer is not an issue on scsi.device. Many third party scsi devices do need it.