hal: Branch 'hal-0_5_8-branch' - 4 commits

[David Zeuthen]

 hald-runner/main.c  |    2 +-
 hald/hald_dbus.c    |    2 +-
 hald/linux/acpi.c   |   11 +++++++++++
 partutil/partutil.c |    6 ++++--
 4 files changed, 17 insertions(+), 4 deletions(-)

New commits:
diff-tree d6b69ff7e8f8510a833e71401b18c949c1f51074 (from 9c14f1e9ed9e4336e0110535a7d1c746d3bd2ba2)
Author: David Zeuthen <davidz at redhat.com>
Date:   Wed Oct 4 16:10:40 2006 -0400

    don't add non-existing partition entries for MS-DOS disk labels
    
    I think the issue is that the users who run into this have broken
    partition extended tables, e.g. we error out in the function
    part_table_probe_msdos_extended() and thus return NULL for the
    extended partition table. We then stuff a NULL pointer into the
    entries list and that's causing the crash on freeing the partition
    table or looking through entries. This patch should fix at least the
    crashes.
    (cherry picked from 51b841cd59a73fc093535ddd9e512d3036ebbbc4 commit)

diff --git a/partutil/partutil.c b/partutil/partutil.c
index 6ede13f..36078c0 100644
--- a/partutil/partutil.c
+++ b/partutil/partutil.c
@@ -585,7 +585,9 @@ part_table_parse_msdos (int fd, guint64 
 
 		//HAL_INFO (("pe = %p", pe));
 
-		p->entries = g_slist_append (p->entries, pe);
+		if (pe != NULL) {
+			p->entries = g_slist_append (p->entries, pe);
+		}
 	}
 
 out:
diff-tree 9c14f1e9ed9e4336e0110535a7d1c746d3bd2ba2 (from eb98f579209dfed31ceaafacc9893362d1ea211c)
Author: Doug Chapman <dchapman at redhat.com>
Date:   Fri Oct 27 13:31:24 2006 -0400

    fix unaligned messages (RH Bug #210079)
    (cherry picked from 8ffd9707244b28a14d3756ddec8f73b0401dd1c0 commit)

diff --git a/hald-runner/main.c b/hald-runner/main.c
index fbb7a63..3c94103 100644
--- a/hald-runner/main.c
+++ b/hald-runner/main.c
@@ -111,7 +111,7 @@ handle_start(DBusConnection *con, DBusMe
 	DBusMessage *reply;
 	DBusMessageIter iter;
 	run_request *r;
-	GPid pid;
+	GPid pid __attribute__ ((aligned));
 
 	r = new_run_request();
 	g_assert(dbus_message_iter_init(msg, &iter));
diff --git a/partutil/partutil.c b/partutil/partutil.c
index 5da36d5..6ede13f 100644
--- a/partutil/partutil.c
+++ b/partutil/partutil.c
@@ -491,7 +491,7 @@ static PartitionTable *
 part_table_parse_msdos (int fd, guint64 offset, guint64 size, gboolean *found_gpt)
 {
 	int n;
-	const guint8 mbr[512];
+	const guint8 mbr[512] __attribute__ ((aligned));
 	PartitionTable *p;
 
 	//HAL_INFO (("Entering MS-DOS parser"));
diff-tree eb98f579209dfed31ceaafacc9893362d1ea211c (from e40fe849334ba6c59eb928528d965215baa3e0c6)
Author: Richard Hughes <hughsie at hughsie-laptop.(none)>
Date:   Wed Nov 1 13:13:39 2006 +0000

    ignore the special ACPI 'Ones' value for rate
    
    As discovered in : http://bugzilla.gnome.org/show_bug.cgi?id=348201
    ACPI gives out the special 'Ones' value for rate when it's unable to
    calculate the true rate.
    We should set the rate zero, and wait for the BIOS to stabilise for the
    few BIOS's that give 0xffff as the very first entry after an AC state
    change.
    This patch has been tested to work by Pierre Ossman.
    (cherry picked from 72cef4fedb8ab245a09826f428bb429d8c7e0371 commit)

diff --git a/hald/linux/acpi.c b/hald/linux/acpi.c
index eae5c51..56b058e 100644
--- a/hald/linux/acpi.c
+++ b/hald/linux/acpi.c
@@ -132,6 +132,17 @@ battery_refresh_poll (HalDevice *d)
 					"battery.reporting.rate");
 
 	/*
+	 * ACPI gives out the special 'Ones' value for rate when it's unable
+	 * to calculate the true rate. We should set the rate zero, and wait
+	 * for the BIOS to stabilise.
+	 *
+	 * full details here: http://bugzilla.gnome.org/show_bug.cgi?id=348201
+	 */
+	if (reporting_rate == 0xffff) {
+		reporting_rate = 0;
+	}
+
+	/*
 	 * We are converting the unknown units into mWh because of ACPI's nature
 	 * of not having a standard "energy" unit.
 	 *
diff-tree e40fe849334ba6c59eb928528d965215baa3e0c6 (from 7c240196eae1cce8bf511dffaa7019e08383d1fb)
Author: John (J5) Palmieri <johnp at redhat.com>
Date:   Mon Nov 6 11:48:55 2006 -0500

    use g_slist_remove_link instead of g_slist_remove
    
    Data would be freed and then g_slist_remove would be called on the
    link which would leave the link in the list, any subsequent iteration
    over the list would cause us to access freed memory.
    (cherry picked from a56a15b90177734c70a8b03d961a7bcabdea2af8 commit)

diff --git a/hald/hald_dbus.c b/hald/hald_dbus.c
index 7a51bfb..ebb7873 100644
--- a/hald/hald_dbus.c
+++ b/hald/hald_dbus.c
@@ -3977,7 +3977,7 @@ local_server_message_handler (DBusConnec
 				g_free (hih->introspection_xml);
 				g_free (hih->udi);
 				g_free (hih);
-				helper_interface_handlers = g_slist_remove (helper_interface_handlers, i);
+				helper_interface_handlers = g_slist_remove_link (helper_interface_handlers, i);
 			}
 		}