ac100 team mailing list archive

[Michael Hope <michael.hope@xxxxxxxxxx>]

On Wed, Jun 8, 2011 at 8:31 PM, Marc Dietich <marvin24@xxxxxx> wrote:
> Hello Michael,
>
>> On Tue, Jun 7, 2011 at 9:00 PM, Oliver Grawert <ogra@xxxxxxxxxx> wrote:
>> > hi,
>> >
>> > Am Dienstag, den 07.06.2011, 09:12 +1200 schrieb Michael Hope:
>> >> On Fri, Jun 3, 2011 at 2:30 AM, Oliver Grawert <ogra@xxxxxxxxxx> wrote:
>> >>
>> >> The installer works fine but I'm afraid the installation is unusable
>> >> on my AC100.  I have it set to auto-logon and it always gets to the
>> >> Unity desktop and takes some initial input, but then two times out of
>> >> three it locks up and won't respond to the keyboard or mouse.  When it
>> >> does keep going, the mouse often loses sync and jumps all over the
>> >> place when you try to move it.  Switching to a VT and back sometimes
>> >> clears this.
>> >>
>> >> I grabbed the image on Friday.  I'll look further - it seems mildly
>> >> more reliable if I switch to a VT early, wait for the desktop to
>> >> finish loading, then switch back.
>> >
>> > try to get online and upgrade the linux-ac100 package, it will pull in a
>> > new kernel that works around the blocked input devices ..
>>
>> I tried to do a dist-upgrade but it keeps hanging on installing
>> gnome-user-guide.  I grabbed just the kernel and did a flash-kernel to
>> load it up and the same probelm happens.  The dmesg shows:
>>
>> Jun  8 09:52:53 vela kernel: [  344.640630] nvec nvec.0: new
>> transaction during send trying to retransmit!
>> Jun  8 09:53:03 vela kernel: [  354.919043] nvec nvec.0: new
>> transaction during send trying to retransmit!
>> Jun  8 09:53:14 vela kernel: [  365.290305] nvec nvec.0: new
>> transaction during send trying to retransmit!
>
> I'm slowing running out of ideas what's the root cause of these problems. You
> may try to compile your own kernel using the latest HEAD which includes some
> rewrite of the interrupt code, but I fear the real problem is somewhere else.
>
>> Jun  8 09:53:17 vela kernel: [  369.166625] INFO: task dpkg:1712
>> blocked for more than 120 seconds.
>> Jun  8 09:53:17 vela kernel: [  369.174255] "echo 0 >
>> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> Jun  8 09:53:17 vela kernel: [  369.174293] dpkg          D 4042ba64
>>   0  1712   1491 0x00000000
>> Jun  8 09:53:17 vela kernel: [  369.174342] Backtrace:
>> Jun  8 09:53:17 vela kernel: [  369.174444] [<4042ba64>]
>> (schedule+0x5ac/0x6ac) from [<401dedf4>]
>> (jbd2_log_wait_commit+0xac/0x104)
>> Jun  8 09:53:17 vela kernel: [  369.174542] [<401dedf4>]
>> (jbd2_log_wait_commit+0xac/0x104) from [<40142e58>]
>> (vfs_fsync_range+0x58/0x7c)
>> Jun  8 09:53:17 vela kernel: [  369.174617] [<40142e58>]
>> (vfs_fsync_range+0x58/0x7c) from [<40142f14>] (vfs_fsync+0x20/0x28)
>> Jun  8 09:53:17 vela kernel: [  369.174685] [<40142f14>]
>> (vfs_fsync+0x20/0x28) from [<40142f3c>] (do_fsync+0x20/0x34)
>> Jun  8 09:53:17 vela kernel: [  369.174784] [<40142f3c>]
>> (do_fsync+0x20/0x34) from [<4003b2c0>] (ret_fast_syscall+0x0/0x30)
>>
>> so the filesystem is getting stuck perhaps due to the MMC driver getting
>> stuck.
>
> This looks strange. We saw stucked mmc/usb in the past, but those were gone
> after the removal of the agressive battery polling. I also see no hints which
> could verify a problem with the power supply.
>
> Thinking about it, I remember I also got those messages while installing some
> large packages (during dist-upgrade). Is it possible that such a message could
> be produces by very slow media (e.g. slow mmc)? In this case, the system should
> be able to recover after some more time.

I worked around it by apt-get removing gnome-user-docs.  The
dist-upgrade succeeded after that.

The machine feels better at the moment.  It still looses the trackpad
often, but pressing the trackpad on/off button or changing to a VT and
back often clears it.  Natty is much prettier and easier to read than
Maverick.

>> The Wifi power saving also seems to be very aggressive.  A SSH session
>> into the AC100 is very laggy, but running a 'sudo ping -i 0.05
>> other-host' to keep the Wifi on works around it.
>
> yup, this is an upstream problem. You can try of "iwconfig power off" helps
> here, but I know this is not a real solution.

Yeah, that's much better.  I had a random hack with things that I
don't understand and 'iwconfig wlan0 power timeout 2' als lets the
Wifi spin down but keeps SSH interactive.