[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Early boot failures with kFreeBSD >= 10.0~svn248992



Hi,


I've been attempting to build newer kfreebsd-10 packages derived from
the package currently in experimental. I'm able to build working kernel
packages with orig tarballs up to and including r248991 with some
changes to the patches and an additional one (which I intend to submit
to the BTS later this week so the package can be updated).

My intent with this mail is to see if there's some more efficient way
of debugging the problem, or if anyone more experienced has some
suggestions as to what the cause may be. I fully intend to continue
diagnosis on my own and contribute my results back to Debian once I have
a working package. Any guidance or pointers you can provide will be
much appreciated.

Let me know if there's any detail I've inadvertently skimmed over that
may be relevant.


Building r248992 results in a successfully built binary package but a
non-booting kernel. When I say "non-booting", there is literally no
output from the kernel at all after GRUB loads it. I've been building
with the debugger enabled, and whatever is causing the problem happens
even before the GDB/KDB messages, so I don't even know if the kernel is
debuggable at this early stage.

r248992 is a fairly harmless-looking diff[0], and I've been
experimenting with adding parts of the diff to my r248991-based package
and seeing what happens. I have already rebuilt kfreebsd-kernel-headers
with the necessary #defines in sys/ata.h (from r250204, which is where
I'm trying to get to with the kernel itself), so outdated headers
shouldn't be an issue.

I've found that replacing the contents of scsi_ata_pass_16 with
"return;" in the r248992 diff fixes the problem, so it's something in
the contents of that function that breaks the boot. This seems very
strange, since the diff does not introduce any calls to that function,
so everything inside it should be entirely impotent. For convenience
and avoidance of doubt, I've attached a patch representing the change
I've narrowed the problem down to.

This build is being done on kfreebsd-amd64.


If it's relevant (which I doubt it is), I've made the following changes
to the packaging:

 * Adjust the version string for my organisation (append 'anchor1'),
   and fix debian/rules to correctly parse the version with non-numeric
   characters in the Debian part.
   + Additionally, I am appending 'anchor1', 'anchor2', etc. to the
     kernel ABI to facilitate easy rollback.
 * Don't prune the original source of non-free parts (commented out the
   prune.sh line in debian/rules). I've appended '+noprune' to the
   upstream part of the version string accordingly.
 * Refresh patches against new upstream source.
   + Also fix d/p/913_uudecode.diff, which is too heavy-handed with
     substituting -p with -o- and breaks a make target.
   + Add d/p/cc_version.diff to fix broken gcc version detection in
     newer build automation.
   + Remove d/p/916_NKPT_amd64.diff, which is no longer needed as
     upstream now sets nkpt dynamically.
 * Enable debugging with a patch to remove lines 20-41 of
   sys/conf/DEBIAN and replace them with "makeoptions DEBUG=-g".
 * Re-enable non-free firmware with
   s/WITHOUT_SOURCELESS/WITHOUT_SOURCELESS_HOST/ in debian/rules.

Again, everything above which isn't specific to my organisation I do
intend to contribute back to Debian later this week (I'm still
experimenting with changes right now).


Cheers,
Steven.

[0] http://svnweb.freebsd.org/base?view=revision&revision=248992
--- kfreebsd-10-10.0~svn248991+noprune/sys/cam/scsi/scsi_all.c	2013-05-07 12:10:03.000000000 +0000
+++ kfreebsd-10-10.0~svn248992+noprune/sys/cam/scsi/scsi_all.c	2013-04-02 00:11:35.000000000 +0000
@@ -5864,7 +5864,39 @@ scsi_ata_pass_16(struct ccb_scsiio *csio
 		 u_int8_t control, u_int8_t *data_ptr, u_int16_t dxfer_len,
 		 u_int8_t sense_len, u_int32_t timeout)
 {
-	return;
+	struct ata_pass_16 *ata_cmd;
+
+	ata_cmd = (struct ata_pass_16 *)&csio->cdb_io.cdb_bytes;
+	ata_cmd->opcode = ATA_PASS_16;
+	ata_cmd->protocol = protocol;
+	ata_cmd->flags = ata_flags;
+	ata_cmd->features_ext = features >> 8;
+	ata_cmd->features = features;
+	ata_cmd->sector_count_ext = sector_count >> 8;
+	ata_cmd->sector_count = sector_count;
+	ata_cmd->lba_low = lba;
+	ata_cmd->lba_mid = lba >> 8;
+	ata_cmd->lba_high = lba >> 16;
+	ata_cmd->device = ATA_DEV_LBA;
+	if (protocol & AP_EXTEND) {
+		ata_cmd->lba_low_ext = lba >> 24;
+		ata_cmd->lba_mid_ext = lba >> 32;
+		ata_cmd->lba_high_ext = lba >> 40;
+	} else
+		ata_cmd->device |= (lba >> 24) & 0x0f;
+	ata_cmd->command = command;
+	ata_cmd->control = control;
+
+	cam_fill_csio(csio,
+		      retries,
+		      cbfcnp,
+		      flags,
+		      tag_action,
+		      data_ptr,
+		      dxfer_len,
+		      sense_len,
+		      sizeof(*ata_cmd),
+		      timeout);
 }
 
 void

Attachment: signature.asc
Description: PGP signature


Reply to: