Send buglog mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openmoko.org/mailman/listinfo/buglog
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of buglog digest..."
Today's Topics:
1. [Bug 212] Charging seems completely broken
([EMAIL PROTECTED])
2. [Bug 212] Charging seems completely broken
([EMAIL PROTECTED])
3. [Bug 212] Charging seems completely broken
([EMAIL PROTECTED])
4. [Bug 212] Charging seems completely broken
([EMAIL PROTECTED])
5. [Bug 212] Charging seems completely broken
([EMAIL PROTECTED])
6. [Bug 212] Charging seems completely broken
([EMAIL PROTECTED])
7. [Bug 212] Charging seems completely broken
([EMAIL PROTECTED])
8. [Bug 245] Neo crashes when writing large amounts of data to
SD ([EMAIL PROTECTED])
9. [Bug 245] Neo crashes when writing large amounts of data to
SD ([EMAIL PROTECTED])
10. [Bug 245] Neo crashes when writing large amounts of data to
SD ([EMAIL PROTECTED])
11. [Bug 245] Neo crashes when writing large amounts of data to
SD ([EMAIL PROTECTED])
12. [Bug 245] Neo crashes when writing large amounts of data to
SD ([EMAIL PROTECTED])
13. [Bug 245] Neo crashes when writing large amounts of data to
SD ([EMAIL PROTECTED])
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=212
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
------- Additional Comments From [EMAIL PROTECTED] 2007-03-10 19:32 -------
I think what might happen here is that we get into some loop where
1) the PMU decides that the battery voltage is high enough to boot
2) it switches on the CPU, which in turn switches on various peripherals, most
notably high-power peripherals such as backlight
3) due to the high current draw, the battery voltage decreases below the
threshold of the PMU
4) the PMU powers the device off
5) due to no more current draw [or 100mA charger], the battery voltage increases
again to a level above the threshold
6) GOTO 1
So the big question is how to prevent this from happening.
a) we could set a higher Vlowbat (minimum battery voltage) threshold. This
sucks because we would shut down the phone even before the battery is empty.
b) we could put some heuristics into u-boot to find out if many reboots are
happening in too short a timeframe. If we can detect this, we still need a way
to prevent it happening again and again. We need to find out for what reason
the PMU decides to power up in the first place.
In order to debug this, I would recommend (Werner?) a patch to u-boot which
dumps the 'power up reason' and interrupt as well as battery voltage monitor
registers to the serial port. This means once we get into the loop, we should
get those registers on the serial console and can deduct what's happening
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=212
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
------- Additional Comments From [EMAIL PROTECTED] 2007-03-10 19:32 -------
I think what might happen here is that we get into some loop where
1) the PMU decides that the battery voltage is high enough to boot
2) it switches on the CPU, which in turn switches on various peripherals, most
notably high-power peripherals such as backlight
3) due to the high current draw, the battery voltage decreases below the
threshold of the PMU
4) the PMU powers the device off
5) due to no more current draw [or 100mA charger], the battery voltage increases
again to a level above the threshold
6) GOTO 1
So the big question is how to prevent this from happening.
a) we could set a higher Vlowbat (minimum battery voltage) threshold. This
sucks because we would shut down the phone even before the battery is empty.
b) we could put some heuristics into u-boot to find out if many reboots are
happening in too short a timeframe. If we can detect this, we still need a way
to prevent it happening again and again. We need to find out for what reason
the PMU decides to power up in the first place.
In order to debug this, I would recommend (Werner?) a patch to u-boot which
dumps the 'power up reason' and interrupt as well as battery voltage monitor
registers to the serial port. This means once we get into the loop, we should
get those registers on the serial console and can deduct what's happening
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=212
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
------- Additional Comments From [EMAIL PROTECTED] 2007-03-10 19:32 -------
I think what might happen here is that we get into some loop where
1) the PMU decides that the battery voltage is high enough to boot
2) it switches on the CPU, which in turn switches on various peripherals, most
notably high-power peripherals such as backlight
3) due to the high current draw, the battery voltage decreases below the
threshold of the PMU
4) the PMU powers the device off
5) due to no more current draw [or 100mA charger], the battery voltage increases
again to a level above the threshold
6) GOTO 1
So the big question is how to prevent this from happening.
a) we could set a higher Vlowbat (minimum battery voltage) threshold. This
sucks because we would shut down the phone even before the battery is empty.
b) we could put some heuristics into u-boot to find out if many reboots are
happening in too short a timeframe. If we can detect this, we still need a way
to prevent it happening again and again. We need to find out for what reason
the PMU decides to power up in the first place.
In order to debug this, I would recommend (Werner?) a patch to u-boot which
dumps the 'power up reason' and interrupt as well as battery voltage monitor
registers to the serial port. This means once we get into the loop, we should
get those registers on the serial console and can deduct what's happening
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are on the CC list for the bug, or are watching someone who is.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=212
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
------- Additional Comments From [EMAIL PROTECTED] 2007-03-10 19:32 -------
I think what might happen here is that we get into some loop where
1) the PMU decides that the battery voltage is high enough to boot
2) it switches on the CPU, which in turn switches on various peripherals, most
notably high-power peripherals such as backlight
3) due to the high current draw, the battery voltage decreases below the
threshold of the PMU
4) the PMU powers the device off
5) due to no more current draw [or 100mA charger], the battery voltage increases
again to a level above the threshold
6) GOTO 1
So the big question is how to prevent this from happening.
a) we could set a higher Vlowbat (minimum battery voltage) threshold. This
sucks because we would shut down the phone even before the battery is empty.
b) we could put some heuristics into u-boot to find out if many reboots are
happening in too short a timeframe. If we can detect this, we still need a way
to prevent it happening again and again. We need to find out for what reason
the PMU decides to power up in the first place.
In order to debug this, I would recommend (Werner?) a patch to u-boot which
dumps the 'power up reason' and interrupt as well as battery voltage monitor
registers to the serial port. This means once we get into the loop, we should
get those registers on the serial console and can deduct what's happening
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=212
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
------- Additional Comments From [EMAIL PROTECTED] 2007-03-10 19:32 -------
I think what might happen here is that we get into some loop where
1) the PMU decides that the battery voltage is high enough to boot
2) it switches on the CPU, which in turn switches on various peripherals, most
notably high-power peripherals such as backlight
3) due to the high current draw, the battery voltage decreases below the
threshold of the PMU
4) the PMU powers the device off
5) due to no more current draw [or 100mA charger], the battery voltage increases
again to a level above the threshold
6) GOTO 1
So the big question is how to prevent this from happening.
a) we could set a higher Vlowbat (minimum battery voltage) threshold. This
sucks because we would shut down the phone even before the battery is empty.
b) we could put some heuristics into u-boot to find out if many reboots are
happening in too short a timeframe. If we can detect this, we still need a way
to prevent it happening again and again. We need to find out for what reason
the PMU decides to power up in the first place.
In order to debug this, I would recommend (Werner?) a patch to u-boot which
dumps the 'power up reason' and interrupt as well as battery voltage monitor
registers to the serial port. This means once we get into the loop, we should
get those registers on the serial console and can deduct what's happening
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=212
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
------- Additional Comments From [EMAIL PROTECTED] 2007-03-10 19:32 -------
I think what might happen here is that we get into some loop where
1) the PMU decides that the battery voltage is high enough to boot
2) it switches on the CPU, which in turn switches on various peripherals, most
notably high-power peripherals such as backlight
3) due to the high current draw, the battery voltage decreases below the
threshold of the PMU
4) the PMU powers the device off
5) due to no more current draw [or 100mA charger], the battery voltage increases
again to a level above the threshold
6) GOTO 1
So the big question is how to prevent this from happening.
a) we could set a higher Vlowbat (minimum battery voltage) threshold. This
sucks because we would shut down the phone even before the battery is empty.
b) we could put some heuristics into u-boot to find out if many reboots are
happening in too short a timeframe. If we can detect this, we still need a way
to prevent it happening again and again. We need to find out for what reason
the PMU decides to power up in the first place.
In order to debug this, I would recommend (Werner?) a patch to u-boot which
dumps the 'power up reason' and interrupt as well as battery voltage monitor
registers to the serial port. This means once we get into the loop, we should
get those registers on the serial console and can deduct what's happening
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=212
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
------- Additional Comments From [EMAIL PROTECTED] 2007-03-10 19:32 -------
I think what might happen here is that we get into some loop where
1) the PMU decides that the battery voltage is high enough to boot
2) it switches on the CPU, which in turn switches on various peripherals, most
notably high-power peripherals such as backlight
3) due to the high current draw, the battery voltage decreases below the
threshold of the PMU
4) the PMU powers the device off
5) due to no more current draw [or 100mA charger], the battery voltage increases
again to a level above the threshold
6) GOTO 1
So the big question is how to prevent this from happening.
a) we could set a higher Vlowbat (minimum battery voltage) threshold. This
sucks because we would shut down the phone even before the battery is empty.
b) we could put some heuristics into u-boot to find out if many reboots are
happening in too short a timeframe. If we can detect this, we still need a way
to prevent it happening again and again. We need to find out for what reason
the PMU decides to power up in the first place.
In order to debug this, I would recommend (Werner?) a patch to u-boot which
dumps the 'power up reason' and interrupt as well as battery voltage monitor
registers to the serial port. This means once we get into the loop, we should
get those registers on the serial console and can deduct what's happening
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=245
------- Additional Comments From [EMAIL PROTECTED] 2007-03-10 19:48 -------
Created an attachment (id=27)
-->
(http://bugzilla.openmoko.org/cgi-bin/bugzilla/attachment.cgi?id=27&action=view)
Panic when reading from mtd with 2.6.20.2
I flashed uImage-2.6-moko8-r1_0_1288_0-fic-gta01.bin and
openmoko-devel-image-fic-gta01-20070310172058.rootfs.jffs2 from
http://buildhost.openmoko.org/tmp/deploy/images.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=245
------- Additional Comments From [EMAIL PROTECTED] 2007-03-10 19:48 -------
Created an attachment (id=27)
-->
(http://bugzilla.openmoko.org/cgi-bin/bugzilla/attachment.cgi?id=27&action=view)
Panic when reading from mtd with 2.6.20.2
I flashed uImage-2.6-moko8-r1_0_1288_0-fic-gta01.bin and
openmoko-devel-image-fic-gta01-20070310172058.rootfs.jffs2 from
http://buildhost.openmoko.org/tmp/deploy/images.
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=245
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #27 mime|application/octet-stream |text/plain
type| |
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=245
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #27 mime|application/octet-stream |text/plain
type| |
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=245
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=245
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
