Re: [Testing] 13.1.0 release candidate 2 (build 21) released
Filled as https://dev.laptop.org/ticket/12433 Gonzalo On Wed, Jan 2, 2013 at 5:49 PM, John Watlington wrote: > > Serial connector show a lot of: > > [ 660.846067] mmcblk0: error -110 sending status command, retrying > > [ 660.846068] mmcblk0: error -110 sending status command, retrying > > [ 660.846098] mmcblk0: error -110 sending status command, aborting > > [ 660.846128] end_request: I/O error, dev mmcblk0, sector 3614152 > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Testing] 13.1.0 release candidate 2 (build 21) released
On Jan 2, 2013, at 10:16 AM, Gonzalo Odiard wrote: > > This build now enables XO-4 idle suspend by default. This is still a > work in progress, there are still various instabilities which may make > this build feel more unstable than previous ones. You can disable > automatic power management in sugar's Settings panel to restore > previous behaviour. > > > These are the instabilities I have found in a few hours using it: > > * The xo shutdown showing a big 01 (or OI) in the screen. > Serial connector show a lot of: > [ 660.846067] mmcblk0: error -110 sending status command, retrying > [ 660.846068] mmcblk0: error -110 sending status command, retrying > [ 660.846098] mmcblk0: error -110 sending status command, aborting > [ 660.846128] end_request: I/O error, dev mmcblk0, sector 3614152 Are these two separate tickets ? wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 13.1.0 release candidate 2 (build 21) released
On Wed, Jan 2, 2013 at 5:06 PM, Paul Fox wrote: > gonzalo wrote: > > > [semi-]reliable suspend/resume on C1/C2 requires new as-yet-unreleased > > > EC code. i've not yet had a B1 work well. > > > > > > Is the wifi interface broken known too or need a ticket filled about > that? > > it's always better to file a ticket than not. > > Done https://dev.laptop.org/ticket/12432 > which wifi failure are you referring to? it's hard to keep track. ;-) > > Hmm :) > paul > =- > paul fox, p...@laptop.org > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 13.1.0 release candidate 2 (build 21) released
jerry wrote: > On Wed, 2013-01-02 at 14:56 -0500, Paul Fox wrote: > > jerry wrote: > > > On Sun, 2012-12-30 at 12:42 +, Daniel Drake wrote: > > > > Hi, > > > > > > > > We're pleased to announce the next release candidate of our new 13.1.0 > > > > software release. > > > < snip > > > > > This build now enables XO-4 idle suspend by default. This is still a > > > > work in progress, there are still various instabilities which may make > > > > this build feel more unstable than previous ones. You can disable > > > > automatic power management in sugar's Settings panel to restore > > > > previous behaviour. > > > > > > > > > > Once my XO-4s (B1 & C2) enters idle suspend they can not be awakened > > > with any external method I've tried. No response to touch-screen, > > > touch-pad, keyboard, or power-button to trigger a event in powerd. I've > > > > [semi-]reliable suspend/resume on C1/C2 requires new as-yet-unreleased > > EC code. i've not yet had a B1 work well. > > > > Is that cl4-7_0_3_06.img? Would it be helpful to test this code? no. it'll be the next one. stay tuned. paul > > > > also, as you've found, rtcalarm-based resume should be okay, but i > > don't think anything else will wake the system reliably. > > > > Yea that looks to be working well. > > > > set the dim/blank to be 60/120 to speed up testing whether rtcalarm > > > works. What I found interesting is once suspended then using the > > > keyboard to awaken if you wait for rtcalarm to wake the XO the event > > > will be shown as 'keypress' while tracing powerd. > > > > yes, a kernel issue was causing most wakeups to be ascribed to > > "keypress". should be fixed in the next build. > > > > Good to know, thanks. > > Jerry > =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 13.1.0 release candidate 2 (build 21) released
On Wed, 2013-01-02 at 14:56 -0500, Paul Fox wrote: > jerry wrote: > > On Sun, 2012-12-30 at 12:42 +, Daniel Drake wrote: > > > Hi, > > > > > > We're pleased to announce the next release candidate of our new 13.1.0 > > > software release. > > < snip > > > > This build now enables XO-4 idle suspend by default. This is still a > > > work in progress, there are still various instabilities which may make > > > this build feel more unstable than previous ones. You can disable > > > automatic power management in sugar's Settings panel to restore > > > previous behaviour. > > > > > > > Once my XO-4s (B1 & C2) enters idle suspend they can not be awakened > > with any external method I've tried. No response to touch-screen, > > touch-pad, keyboard, or power-button to trigger a event in powerd. I've > > [semi-]reliable suspend/resume on C1/C2 requires new as-yet-unreleased > EC code. i've not yet had a B1 work well. > Is that cl4-7_0_3_06.img? Would it be helpful to test this code? > also, as you've found, rtcalarm-based resume should be okay, but i > don't think anything else will wake the system reliably. > Yea that looks to be working well. > > set the dim/blank to be 60/120 to speed up testing whether rtcalarm > > works. What I found interesting is once suspended then using the > > keyboard to awaken if you wait for rtcalarm to wake the XO the event > > will be shown as 'keypress' while tracing powerd. > > yes, a kernel issue was causing most wakeups to be ascribed to > "keypress". should be fixed in the next build. > Good to know, thanks. Jerry ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 13.1.0 release candidate 2 (build 21) released
gonzalo wrote: > > [semi-]reliable suspend/resume on C1/C2 requires new as-yet-unreleased > > EC code. i've not yet had a B1 work well. > > > Is the wifi interface broken known too or need a ticket filled about that? it's always better to file a ticket than not. which wifi failure are you referring to? it's hard to keep track. ;-) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 13.1.0 release candidate 2 (build 21) released
> [semi-]reliable suspend/resume on C1/C2 requires new as-yet-unreleased > EC code. i've not yet had a B1 work well. Is the wifi interface broken known too or need a ticket filled about that? Gonzalo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 13.1.0 release candidate 2 (build 21) released
jerry wrote: > On Sun, 2012-12-30 at 12:42 +, Daniel Drake wrote: > > Hi, > > > > We're pleased to announce the next release candidate of our new 13.1.0 > > software release. > < snip > > > This build now enables XO-4 idle suspend by default. This is still a > > work in progress, there are still various instabilities which may make > > this build feel more unstable than previous ones. You can disable > > automatic power management in sugar's Settings panel to restore > > previous behaviour. > > > > Once my XO-4s (B1 & C2) enters idle suspend they can not be awakened > with any external method I've tried. No response to touch-screen, > touch-pad, keyboard, or power-button to trigger a event in powerd. I've [semi-]reliable suspend/resume on C1/C2 requires new as-yet-unreleased EC code. i've not yet had a B1 work well. also, as you've found, rtcalarm-based resume should be okay, but i don't think anything else will wake the system reliably. > set the dim/blank to be 60/120 to speed up testing whether rtcalarm > works. What I found interesting is once suspended then using the > keyboard to awaken if you wait for rtcalarm to wake the XO the event > will be shown as 'keypress' while tracing powerd. yes, a kernel issue was causing most wakeups to be ascribed to "keypress". should be fixed in the next build. paul > > Jerry > > > > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 13.1.0 release candidate 2 (build 21) released
On Sun, 2012-12-30 at 12:42 +, Daniel Drake wrote: > Hi, > > We're pleased to announce the next release candidate of our new 13.1.0 > software release. < snip > > This build now enables XO-4 idle suspend by default. This is still a > work in progress, there are still various instabilities which may make > this build feel more unstable than previous ones. You can disable > automatic power management in sugar's Settings panel to restore > previous behaviour. > Once my XO-4s (B1 & C2) enters idle suspend they can not be awakened with any external method I've tried. No response to touch-screen, touch-pad, keyboard, or power-button to trigger a event in powerd. I've set the dim/blank to be 60/120 to speed up testing whether rtcalarm works. What I found interesting is once suspended then using the keyboard to awaken if you wait for rtcalarm to wake the XO the event will be shown as 'keypress' while tracing powerd. Jerry ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [TRANSIENT] Peer XOs NOT shown in Neighborhood view when Power Management is enabled
On Wed, Jan 2, 2013 at 10:21 AM, Paul Fox wrote: > samuel wrote: > > On Tue, Jan 1, 2013 at 7:34 PM, Jerry Vonau wrote: > > > > > On Wed, 2012-12-19 at 09:48 -0500, Martin Langhoff wrote: > > > > On Wed, Dec 19, 2012 at 5:14 AM, Jerry Vonau > wrote: > > > > > Think I found the problem, in powerd we're setting WOL based on > this > > > > > string: > > > > > > > > > > if grep -qi ": :14B2" /proc/net/tcp > > > > > > > > > > but that string is not present in /proc/net/tcp so WOL is not set > > > > > according to ethtool, but that string can be found in > /proc/net/tcp6 > > > > > > > > > > avahi is bound to tcp6 when viewed with 'netstat -nat' > > > > > > > > > > This is reproducible in 12.1.0 and 13.1.0 > > > > > > > > Arghhh. Ouch. > > > > > > > > Does it behave better with: > > > > > > > > if grep -qi ": :14B2" /proc/net/tcp* > > > > > > > This does not work because IPv6 addresses are longer (and therefore have > > more octets). > > > > The variant I came up with (if we want to support both v4 and v6 > listeners) > > is > > > > if grep -qiE ": +:14B2" /proc/net/tcp? > > > > Simply removing the ": " check on its own might be sufficient for our > > purposes but could falsely return true in a few cases. > > > > If IPv4 backward compatibility on the listener check is not a concern, > then > > you should just match on the longer string of zeros:14B6 in > /proc/net/tcp6 > > and not check both files for speed. > > why would ipv4 backward compatibility not be a concern? > The ::0 (0.0.0.0 in IPv4 netstat speak) listener for telepathy-salut is bound on the IPv6 socket, but still handles IPv4 requests. So just /proc/net/tcp6 can be looked at in 13.1.0/Fedora 18 as we ship it. But if there is an option to tell telepathy-salut to bind to 0.0.0.0 instead of ::0 and force the listener to use IPv4 binding, then both /proc/net/tcp and /proc/net/tcp6 have to be checked if we wanted to be backward-compatible, or just paranoid in case something we don't know or don't expect can tell telepathy-salut to do that. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [TRANSIENT] Peer XOs NOT shown in Neighborhood view when Power Management is enabled
samuel wrote: > On Tue, Jan 1, 2013 at 7:34 PM, Jerry Vonau wrote: > > > On Wed, 2012-12-19 at 09:48 -0500, Martin Langhoff wrote: > > > On Wed, Dec 19, 2012 at 5:14 AM, Jerry Vonau wrote: > > > > Think I found the problem, in powerd we're setting WOL based on this > > > > string: > > > > > > > > if grep -qi ": :14B2" /proc/net/tcp > > > > > > > > but that string is not present in /proc/net/tcp so WOL is not set > > > > according to ethtool, but that string can be found in /proc/net/tcp6 > > > > > > > > avahi is bound to tcp6 when viewed with 'netstat -nat' > > > > > > > > This is reproducible in 12.1.0 and 13.1.0 > > > > > > Arghhh. Ouch. > > > > > > Does it behave better with: > > > > > > if grep -qi ": :14B2" /proc/net/tcp* > > > > This does not work because IPv6 addresses are longer (and therefore have > more octets). > > The variant I came up with (if we want to support both v4 and v6 listeners) > is > > if grep -qiE ": +:14B2" /proc/net/tcp? > > Simply removing the ": " check on its own might be sufficient for our > purposes but could falsely return true in a few cases. > > If IPv4 backward compatibility on the listener check is not a concern, then > you should just match on the longer string of zeros:14B6 in /proc/net/tcp6 > and not check both files for speed. why would ipv4 backward compatibility not be a concern? paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 13.1.0 release candidate 2 (build 21) released
> This build now enables XO-4 idle suspend by default. This is still a > work in progress, there are still various instabilities which may make > this build feel more unstable than previous ones. You can disable > automatic power management in sugar's Settings panel to restore > previous behaviour. > > These are the instabilities I have found in a few hours using it: * The xo shutdown showing a big 01 (or OI) in the screen. Serial connector show a lot of: [ 660.846067] mmcblk0: error -110 sending status command, retrying [ 660.846068] mmcblk0: error -110 sending status command, retrying [ 660.846098] mmcblk0: error -110 sending status command, aborting [ 660.846128] end_request: I/O error, dev mmcblk0, sector 3614152 * After restart, when tried to do "/sbin/ifconfig" the command does not finish, (as olpc or root) and can't be killed. * In the serial port I see a continue of errors like: [ 164.830574] WARNING: at drivers/misc/olpc-ec-1-75.c:220 olpc_ec_1_75_strobe_ack+0x40/0x6c() [ 164.830574] Modules linked in: fuse xt_tcpudp mousedev iptable_filter ip_tables x_tables btmrvl_sdio btmrvl mwifiex_sdio mwifiex bluetooth uinput joydev psmouse mmp_camera videobuf2_dma_sg videobuf2_vmalloc videobuf2_memops videobuf2_core zforce syscopyarea sysfillrect sysimgblt fb_sys_fops sisusbvga siv120d [last unloaded: udlfb] [ 164.838850] [] (unwind_backtrace+0x0/0x128) from [] (dump_stack+0x20/0x24) [ 164.867963] [] (dump_stack+0x20/0x24) from [] (warn_slowpath_common+0x5c/0x74) [ 164.885407] [] (warn_slowpath_common+0x5c/0x74) from [] (warn_slowpath_null+0x2c/0x34) [ 164.885407] [] (warn_slowpath_null+0x2c/0x34) from [] (olpc_ec_1_75_strobe_ack+0x40/0x6c) [ 164.904827] [] (olpc_ec_1_75_strobe_ack+0x40/0x6c) from [] (olpc_ec_1_75_send_command+0x84/0x90) [ 164.904827] [] (olpc_ec_1_75_send_command+0x84/0x90) from [] (olpc_ec_1_75_ssp_handler+0x27c/0x510) [ 164.915269] [] (olpc_ec_1_75_ssp_handler+0x27c/0x510) from [] (handle_irq_event_percpu+0x98/0x2a4) [ 164.925979] [] (handle_irq_event_percpu+0x98/0x2a4) from [] (handle_irq_event+0x68/0x84) [ 164.936592] [] (handle_irq_event+0x68/0x84) from [] (handle_level_irq+0xec/0x124) [ 164.946343] [] (handle_level_irq+0xec/0x124) from [] (generic_handle_irq+0x30/0x40) [ 164.955493] [] (generic_handle_irq+0x30/0x40) from [] (handle_IRQ+0x70/0x94) [ 164.964824] [] (handle_IRQ+0x70/0x94) from [] (asm_do_IRQ+0x18/0x1c) [ 164.981570] [] (asm_do_IRQ+0x18/0x1c) from [] (__irq_usr+0x4c/0x80) [ 164.989508] Exception stack(0xec447fb0 to 0xec447ff8) [ 164.994516] 7fa0: b680f358 0038 [ 165.002626] 7fc0: 00022358 b6fe1a38 bed76244 bed76244 0006 b6fe1a38 b68083f8 [ 165.010739] 7fe0: 0010 bed761e8 b6fbfd5c b6fb9d04 60070010 [ 165.010739] ---[ end trace 2ddf9329036edcc8 ]--- [ 260.911774] [ cut here ] [ 260.921034] WARNING: at drivers/misc/olpc-ec-1-75.c:220 olpc_ec_1_75_strobe_ack+0x40/0x6c() [ 260.921034] Modules linked in: fuse xt_tcpudp mousedev iptable_filter ip_tables x_tables btmrvl_sdio btmrvl mwifiex_sdio mwifiex bluetooth uinput joydev psmouse mmp_camera videobuf2_dma_sg videobuf2_vmalloc videobuf2_memops videobuf2_core zforce syscopyarea sysfillrect sysimgblt fb_sys_fops sisusbvga siv120d [last unloaded: udlfb] [ 260.958424] [] (unwind_backtrace+0x0/0x128) from [] (dump_stack+0x20/0x24) [ 260.958424] [] (dump_stack+0x20/0x24) from [] (warn_slowpath_common+0x5c/0x74) [ 260.966976] [] (warn_slowpath_common+0x5c/0x74) from [] (warn_slowpath_null+0x2c/0x34) [ 260.985448] [] (warn_slowpath_null+0x2c/0x34) from [] (olpc_ec_1_75_strobe_ack+0x40/0x6c) [ 260.995288] [] (olpc_ec_1_75_strobe_ack+0x40/0x6c) from [] (olpc_ec_1_75_send_command+0x84/0x90) [ 260.995288] [] (olpc_ec_1_75_send_command+0x84/0x90) from [] (olpc_ec_1_75_ssp_handler+0x27c/0x510) [ 261.005729] [] (olpc_ec_1_75_ssp_handler+0x27c/0x510) from [] (handle_irq_event_percpu+0x98/0x2a4) [ 261.016440] [] (handle_irq_event_percpu+0x98/0x2a4) from [] (handle_irq_event+0x68/0x84) [ 261.027051] [] (handle_irq_event+0x68/0x84) from [] (handle_level_irq+0xec/0x124) [ 261.045954] [] (handle_level_irq+0xec/0x124) from [] (generic_handle_irq+0x30/0x40) [ 261.045954] [] (generic_handle_irq+0x30/0x40) from [] (handle_IRQ+0x70/0x94) [ 261.055282] [] (handle_IRQ+0x70/0x94) from [] (asm_do_IRQ+0x18/0x1c) [ 261.064002] [] (asm_do_IRQ+0x18/0x1c) from [] (__irq_svc+0x4c/0x94) [ 261.079969] Exception stack(0xec447ba0 to 0xec447be8) [ 261.084979] 7ba0: ec447be8 000a 0002 c06494c4 fe282104 ec447c94 [ 261.084979] 7bc0: c0649480 0038 3f9b6b3c ec447c24 ec447c28 ec447be8 c0029550 c0028f20 [ 261.101206] 7be0: 20070113 [ 261.101206] [] (__irq_svc+0x4c/0x94) from [] (__do_softirq+0x58/0x248) [ 261.112868] [] (__do_softirq+0x58/0x248) from [] (irq_exit+0x54/0xb8) [ 261.112868] [] (irq_exit+0x54/0xb8) from [] (handle_IRQ+0x74/0x94) [ 261.128840] [] (handle_IRQ+0x74/0x94
