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. Re: Openmoko Bug #1904: om2008.8 wifi don't get always an
ipv4 ip (Openmoko Public Trac)
2. Re: Openmoko Bug #1904: om2008.8 wifi don't get always an
ipv4 ip (Openmoko Public Trac)
3. Openmoko Bug #1997: Qtopia - clear dialed number menu item
(Openmoko Public Trac)
4. Re: Openmoko Bug #1998: "Unable to mount root fs on
unknown-block(179, 2)" after hard shutdown (Openmoko Public Trac)
5. Openmoko Bug #1998: "Unable to mount root fs on
unknown-block(179, 2)" after hard shutdown (Openmoko Public Trac)
6. Re: Openmoko Bug #1998: "Unable to mount root fs on
unknown-block(179, 2)" after hard shutdown (Openmoko Public Trac)
7. Openmoko Bug #1999: python-etk-git patches patched upstream
(Openmoko Public Trac)
--- Begin Message ---
#1904: om2008.8 wifi don't get always an ipv4 ip
------------------------+---------------------------------------------------
Reporter: dolfje | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version:
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
------------------------+---------------------------------------------------
Comment(by elfo):
Same problem here with different 2008.8 and qtopia images.
There's a 70-85% package loss even if you set the network configuration
statically.
Facts:
WEP + ASCII key + [2008.8-updates (september) | FDOM 20080913 | Qtopia
4.3.3] + ifconfig (not dhcp).
Tested with FR 10 cm away from router, 1 meter away and 3 meters away. No
significant difference so signal strength apparently being the cause.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1904#comment:8>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1904: om2008.8 wifi don't get always an ipv4 ip
------------------------+---------------------------------------------------
Reporter: dolfje | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version:
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
------------------------+---------------------------------------------------
Comment(by elfo):
Sorry...
> Tested with FR 10 cm away from router, 1 meter away and 3 meters away.
No significant difference so signal strength apparently _NOT_ being the
cause.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1904#comment:9>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1997: Qtopia - clear dialed number menu item
-------------------------+--------------------------------------------------
Reporter: Treviño | Owner: zecke
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: Qtopia | Version:
Severity: normal | Keywords: HasPatch
Blockedby: | Reproducible:
Blocking: |
-------------------------+--------------------------------------------------
I've made a small patch (attached) to add a menu item to the qtopia dialer
that allows to delete the dialed number at all.
If the number written in the textfield is quite long, tapping the "Delete"
button more times is annoying (and sometimes it causes also to close
accidentally the dialer window). That's why I've done this and I find it
useful.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1997>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1998: "Unable to mount root fs on unknown-block(179,2)" after hard shutdown
------------------------+---------------------------------------------------
Reporter: denver | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone: Om2008.8
Component: unknown | Version: Om2008.8
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
------------------------+---------------------------------------------------
Comment(by denver):
To clarify, I am using the 20080903 kernel, the latest at the time of this
writing, which is available at:
http://downloads.openmoko.org/releases/Om2008.8-update/Om2008.8-gta02-20080903.uImage.bin
The output of "uname -a" is:
{{{
Linux om-gta02 2.6.24 #1 PREEMPT Wed Sep 3 19:01:18 CST 2008 armv4tl
unknown
}}}
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1998#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1998: "Unable to mount root fs on unknown-block(179,2)" after hard shutdown
---------------------+------------------------------------------------------
Reporter: denver | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone: Om2008.8
Component: unknown | Version: Om2008.8
Severity: normal | Keywords:
Blockedby: | Reproducible:
Blocking: |
---------------------+------------------------------------------------------
Upon restarting after a hard shutdown (removing the battery while device
is on), the kernel fails to mount the root filesystem on the microSD card
while booting to the microSD card. The following message is printed to
the top of the screen at boot time and the system halts:
{{{
[ 8.075000] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(179,2)
}}}
After removing the battery for approximately one minute, re-inserting it,
and turning on the unit, it halts at the same point, but provides more
information:
{{{
[ 3.......] Bluetooth: ...
[ 3.900000] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[ 3.980000] pcf50633 0-0073: setting system clock to 2008-09-13
22:37:24 UTC (1221345444)
[ 3.985000] Waiting 5sec before mounting root device...
[ 4.125000] CRCFAIL 0x1a3f
[ 4.530000] CRCFAIL 0x1a3f
[ 4.545000] CRCFAIL 0x1a3f
[ 4.595000] sdio_wlan 00:01: driver attached
[ 4.600000] sdio_wlan 00:01: SDIO device, IDs SD_0001 (active)
[ 5.650000] BMI Get Target Info: Exit (ver: 0x20000059 type: 0x1)
[ 5.720000] SDIO_INT_CTRL enable IRQ
[ 5.730000] AR6000 Reg Code = 0x40000060
[ 9.005000] EXT2-fs: mmcblk0p2: couldn't mount because of unsupported
optional features (4).
[ 9.015000] List of all partitions:
[ 9.020000] 1f00 2048 mtdblock0 (driver?)
[ 9.025000] 1f01 256 mtdblock1 (driver?)
[ 9.030000] 1f02 256 mtdblock2 (driver?)
[ 9.040000] 1f03 8192 mtdblock3 (driver?)
[ 9.050000] 1f04 640 mtdblock4 (driver?)
[ 9.060000] 1f05 256 mtdblock5 (driver?)
[ 9.065000] 1f06 252544 mtdblock6 (driver?)
[ 9.070000] b300 498176 mmcblk0 driver: mmcblk
[ 9.080000] b301 7836 mmcblk0p1
[ 9.085000] b302 490336 mmcblk0p2
[ 9.090000] No filesystem could mount root, tried: ext2
[ 9.100000] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(179,2)
}}}
The problem can be corrected by using a microSD card reader on another
computer to mount the ext2 partition. After unmounting the partition and
inserting it into the FreeRunner, the operating system boots without
issue.
To help diagnose the issue, I copied the contents of the microSD card (dd
if=/dev/sdb) before and after mounting it with the microSD card reader.
The following is a diff between the hexdumps of the two images:
{{{
--- before_mount.hex 2008-09-13 14:40:15.000000000 -0400
+++ after_mount.hex 2008-09-13 14:41:13.000000000 -0400
@@ -496087,13 +496087,13 @@
007a8000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
*
007a8400 00 e0 01 00 60 7b 07 00 c4 5f 00 00 43 a4 04 00
|....`{..._..C...|
007a8410 6b 70 01 00 01 00 00 00 00 00 00 00 00 00 00 00
|kp..............|
-007a8420 00 20 00 00 00 20 00 00 00 08 00 00 c4 2f cc 48 |. ...
......./.H|
-007a8430 c4 2f cc 48 0f 00 19 00 53 ef 00 00 01 00 00 00
|./.H....S.......|
+007a8420 00 20 00 00 00 20 00 00 00 08 00 00 7d 07 cc 48 |. ...
......}..H|
+007a8430 91 07 cc 48 10 00 19 00 53 ef 00 00 01 00 00 00
|...H....S.......|
007a8440 17 87 c5 48 00 4e ed 00 00 00 00 00 01 00 00 00
|...H.N..........|
007a8450 00 00 00 00 0b 00 00 00 80 00 00 00 3c 00 00 00
|............<...|
-007a8460 06 00 00 00 01 00 00 00 83 0e 12 ae d4 47 43 a7
|.............GC.|
+007a8460 02 00 00 00 01 00 00 00 83 0e 12 ae d4 47 43 a7
|.............GC.|
007a8470 84 73 d1 23 03 52 96 f5 00 00 00 00 00 00 00 00
|.s.#.R..........|
007a8480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
*
007a84c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
|................|
}}}
The partition table is as follows (output of "echo p | fdisk
/dev/mmcblk0"):
{{{
Disk /dev/mmcblk0: 510 MB, 510132224 bytes
8 heads, 7 sectors/track, 17792 cylinders
Units = cylinders of 56 * 512 = 28672 bytes
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 1 280 7836+ 83 Linux
/dev/mmcblk0p2 281 17792 490336 83 Linux
}}}
This shows that 007a8000, the first line of the above diff, is at the
start of mmcblk0p2 (280*28672 = 7a8000). Unfortunately, I don't
understand the ext2/3 filesystem headers so I'm not sure what this diff
means. It should prove useful to someone that knows a bit more about it,
though.
I can provide additional information about the before_mount and
after_mount images if you need them.
Presumably the issue is with the Openmoko kernel. It is unable to mount
the partition even though another Linux kernel can mount it (the one on
the computer with the attached microSD reader). The differences in the
ext2/3 filesystem header appear to be causing the problem. Either the
filesystem header is being left in an invalid state on a hard shutdown or
the kernel is unable to read the valid filesystem header that is present
after a hard shutdown. In any case, the kernel should be able to correct
the issue at boot time and proceed.
This issue can be reproduced by modifying the filesystem header as
described in the above diff. It can also be reproduced by doing a hard
shutdown on an Om2008.8 system booted from the 512MB microSD card shipped
with the FreeRunner, although it only occurs sometimes.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1998>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1998: "Unable to mount root fs on unknown-block(179,2)" after hard shutdown
------------------------+---------------------------------------------------
Reporter: denver | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone: Om2008.8
Component: unknown | Version: Om2008.8
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
------------------------+---------------------------------------------------
Comment(by denver):
To clarify, I am using the 20080903 kernel, the latest at the time of this
writing, which is available at:
http://downloads.openmoko.org/releases/Om2008.8-update/Om2008.8-gta02-20080903.uImage.bin
The output of "uname -a" is:
{{{
Linux om-gta02 2.6.24 #1 PREEMPT Wed Sep 3 19:01:18 CST 2008 armv4tl
unknown
}}}
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1998#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1999: python-etk-git patches patched upstream
---------------------+------------------------------------------------------
Reporter: ptitjes | Owner: julian_chu
Type: defect | Status: new
Priority: normal | Milestone:
Component: Distro | Version:
Severity: normal | Keywords:
Blockedby: | Reproducible: always
Blocking: |
---------------------+------------------------------------------------------
Patches for the python-etk-git package already have been patched upstream.
This makes its build fail.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1999>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
