anyboot image with block size 1024 doesn't boot from CD

[mmadia]

This r1a3-rc-hrev41789 + the changesets for stripping debug information in common/bin & common/lib (hrev41812, hrev41820) + editing build_haiku_image to use a blocksize of 1024K (instead of 2048).

The resulting anyboot image will fail to boot on my hardware. To note, the image generated with 2048 blocksize will boot properly

According to [the attached] syslog the block size is correctly determined as 2048, which seems to point to an IOCache or DMAResource issue. -- ingo

[mmadia]

hrev41789-anyboot-on-CD

[mmadia]

with the addition of changeset hrev41833 -- see attachment:changes-for-syslog-2.diff​ for complete changes.

[mmadia]

From attachment:minicom-r1a3-rc-anyboot-syslog-2​ , which adds changeset:41833

Mounted boot partition: /dev/disk/atapi/2/master/0
scsi_cd: ioctl(op = 15)
scsi_cd: ioctl(op = 15)
atapi 2-0 error: device indicates transfer error after dma
check_sense: Medium error
scsi_cd: ioctl(op = 15)
atapi 2-0 error: device indicates transfer error after dma
check_sense: Medium error
scsi_cd: ioctl(op = 15)
atapi 2-0 error: device indicates transfer error after dma
check_sense: Medium error
scsi_cd: ioctl(op = 15)
atapi 2-0 error: device indicates transfer error after dma
check_sense: Medium error
IOCache::_TransferRequestLine(): Failed to read into cache (offset: 675282944, length: 1048576), trying uncached read (offset: 675312640, length: 1024)
scsi_cd: ioctl(op = 15)
atapi 2-0 error: device indicates transfer error after dma

I'm now build a new anyboot image with the following addition, as Ingo suggested in the haiku-development ML.

Index: ../haiku/src/add-ons/kernel/drivers/disk/scsi/scsi_cd/scsi_cd.cpp
===================================================================
--- ../haiku/src/add-ons/kernel/drivers/disk/scsi/scsi_cd/scsi_cd.cpp	(revision 41789)
+++ ../haiku/src/add-ons/kernel/drivers/disk/scsi/scsi_cd/scsi_cd.cpp	(working copy)
@@ -998,15 +998,15 @@
 		// fragmentation, which makes large contiguous allocations more likely
 		// to fail.
- 		size_t freeMemory = vm_page_num_free_pages();
-		if (freeMemory > 180 * 1024 * 1024 / B_PAGE_SIZE) {
-			info->io_scheduler = new(std::nothrow) IOCache(info->dma_resource,
-				1024 * 1024);
-		} else {
+//		size_t freeMemory = vm_page_num_free_pages();
+//		if (freeMemory > 180 * 1024 * 1024 / B_PAGE_SIZE) {
+//			info->io_scheduler = new(std::nothrow) IOCache(info->dma_resource,
+//				1024 * 1024);
+//		} else {
 			dprintf("scsi_cd: Using IOSchedulerSimple instead of IOCache to "
 				"avoid memory allocation issues.\n");
 			info->io_scheduler = new(std::nothrow) IOSchedulerSimple(
 				info->dma_resource);
-		}
+//		}

 		if (info->io_scheduler == NULL)
 			panic("allocating IOScheduler failed.");

[mmadia]

syslog from the addition of the diff mentioned in comment:1

[mmadia]

Forcing the use of the IOSchedulerSimple still generated the following:

scsi_cd: ioctl(op = 15)
atapi 2-0 error: device indicates transfer error after dma
check_sense: Medium error
usb error hub 13: error updating port status
scsi_cd: ioctl(op = 15)